RU2773429C1 - Automation system for the exchange of marking codes - Google Patents

Abstract

FIELD: distributed data processing systems.

SUBSTANCE: invention relates to the field of distributed data processing systems and can be used as a tool for interaction between participants in the circulation of goods, including international ones, and their counterparties, such as service providers for converting marking codes into identification tools and foreign production sites. The system consists of several network segments (servers) spaced geographically and connected by communication channels, each of which is made on the basis of a software and hardware complex.

EFFECT: ensuring automation of guaranteed delivery of marking codes from the turnover participant to the service provider in order to eliminate the risk of distortion of the marking code and related workflow, including receipts confirming the receipt of information and marking codes and reports on the use of marking codes, as well as monitoring the status of the marking code.

1 cl, 7 dwg

Description

Technical field

The proposed invention relates to the field of distributed data processing systems and can be used as a tool for interaction between participants in the circulation of goods, including international ones.

Prior Art

The problem of combating counterfeit products occupies a significant place in various areas of production and consumption. Both the manufacturer of the goods and the potential consumer are interested in creating significant obstacles for unscrupulous and criminal organizations to produce a fake product.

In this regard, the prior art presents a wide range of methods to counteract the release of counterfeit products, which differ in the technical means used and in the cost of implementation.

Thus, protection methods are known, which consist in the release of packaging (containers) of a product of a certain complex shape, the use of holographic elements, watermarks, the integration of a product production line with an authenticity determination system, and so on. These methods lack universality, since for different types of products they involve the use of various technical means and are quickly reproduced by attackers.

Known solutions based on the labeling of goods or documents with two-dimensional codes (QR-code, DataMatrix, etc.), which are universal in the sense of the possibility of their application for labeling manufactured products and subsequent traceability of the labeled product along the distribution chain

Thus, a solution is known (US 2018314869 A1, 11/01/2018) which is a method for verifying the authenticity of the marking, which includes shooting a genuine two-dimensional code print, generating a unique digital sequence describing the microroughness of printing a genuine two-dimensional code print, storing a unique digital sequence in the database , to check another two-dimensional print, a digital sequence is similarly formed, the indicated two digital sequences are compared and, if the digital sequences match, a conclusion is made about the authenticity of another two-dimensional code print, otherwise it is concluded that the other two-dimensional code print is not genuine .

However, this solution does not have a number of disadvantages and has not been widely used. Currently, the solutions that carry out labeling of goods are mostly based on the principle of issuing a labeling code, converting the labeling code into an identification tool - a two-dimensional code of the DataMatrix standard and subsequent traceability of the change in the status of the labeling code and the change of its owner through a centralized state information system.

The main problem of this approach, which is being solved within the framework of this application, is that state information systems do not automate business processes that lie outside the direct emission of the marking code and traceability of its status and change of ownership within the system. While for the participants in the circulation of products subject to mandatory labeling, a number of tasks appear that need to be solved independently, the main of which is the exchange of labeling codes with counterparties.

Thus, in connection with the introduction of mandatory digital labeling of goods in the EAEU countries, there is a demand for a number of new services from the participants in the circulation of goods in these countries subject to mandatory labeling. All services are associated with the main essence of the business processes of labeling goods - the labeling code and the main actions on them:

- receiving the marking code from the information system of the Marking Operator;

- delivery of marking codes to service providers who convert it into an identification tool, such as printing houses, logistics operators, customs warehouses, etc. location) and its status (state);

- delivery of the marking code to the production sites of participants in the circulation of products subject to mandatory marking;

- delivery of the marking code to contract production sites, production sites of product suppliers for importers participating in the circulation of products subject to mandatory labeling.

Therefore, the labeling code is a new entity that forces the participants in the circulation of products subject to mandatory labeling to establish new relationships with counterparties around the world, including their own production sites, warehouses, offices, etc. The participants in the circulation are forced to introduce new business processes necessary for work with the marking code and related processes of its emission and use in document management.

At the same time, national Labeling Operators do not provide the participants in the circulation of products subject to mandatory labeling with tools to automate these new processes. Marking operators provide software interfaces necessary for interaction with their infrastructure, integration and implementation of the required business processes is entirely the responsibility of the turnover participant.

A serious problem for participants in the circulation of products subject to mandatory labeling is the introduction of new business processes associated with the labeling code from their counterparties who do not want to incur additional infrastructure costs, which is necessary to ensure the delivery of labeling codes to their production sites and the accompanying document flow with the participant turnover of goods (by the importer).

Printing the marking code for manufactured products directly at the production site by direct application by the participant in the circulation of products subject to mandatory labeling, which receives codes from the national Labeling Operator, directly to its production process control system (APCS), is used quite rarely, since it requires re-equipment of production, implementation of integrations into complex systems, often of foreign production (with a long update release cycle) and is suitable for a very limited group of turnover participants.

Turnover participants need an intermediary solution that simplifies integration with the information systems of Marking Operators and their existing infrastructures, a cloud service that provides interaction with counterparties and marking service providers.

In most cases, labeling technology is used for labeling goods (printing the labeling code on the label in a typographical way, or on specialized equipment located in logistics or customs warehouses), or printing the labeling code on the packaging (container) of products in printing houses. Thus, labeling is “overgrown” with a whole layer of service providers and new business processes that ensure interaction with them, and this is only for services related to applying the labeling code to a label or package (container), and logistics, customs brokerage services are also needed. who have expertise in the processes of customs clearance of labeled products. In this regard, it is very important to note that a large volume of products subject to mandatory labeling is produced outside the EAEU countries, in particular in China. According to the current regulatory legal acts, products in countries where mandatory labeling has been introduced must arrive already labeled. Thus, the participants in the circulation of products subject to mandatory labeling, in this case, importers of products manufactured outside the EAEU countries, need to transfer large arrays of labeling codes to foreign production sites, control delivery (guaranteed delivery) and receive reports from production sites on the use of codes markings. For the sites themselves, which are not always interested in making major changes to their business processes and implementing new integrations into their systems, it is necessary to provide the most simple and convenient interfaces, in some cases not even software, but user interfaces, implemented in personal accounts of the cloud platform (online service, system).

In the conditions of rapid growth and implementation of labeling projects in various countries, a virtual environment, a communication network, a cloud platform (service) are needed to search for service providers, order services for converting labeling codes into identification tools and printing them on labels, containers, or packaging and exchange of marking codes with service providers and foreign production sites. At the same time, such an environment should provide increased reliability of the transmission of codes without distortion in order to comply with the requirements established in the regulatory legal acts, as well as the environment should provide control over the change of the owner of the marking code within the system, its current status and quality assessment (validation) of the identification tool into which the code is converted. markings. Without such an environment, the implementation of marking under the current conditions will be significantly difficult, and in some cases impossible, for the reason that the only alternative to the proposed solution is the transfer of marking codes from the participant in the turnover to the service provider, through standard means of information exchange, such as:

1. Email

2. File servers

3. Media

Since in this case we are talking about huge (billions of units) arrays of marking codes, their accounting, control of integrity, current location and status, using the above means and methods of transmission will be impossible. As a result, there will be losses, thefts, the use of marking codes for marking counterfeit goods. The most painful problem in this context is the distortion of the marking code, as it leads to the impossibility of its processing by means of technical vision in the distribution chain and, accordingly, the impossibility of traceability of the marked products. The consequence of this situation may be the discrediting of the labeling project and its recognition as unrealizable by the state authorities of the countries where mandatory labeling of products is being introduced. It should be additionally noted that in case of a distortion of the marking code, the products on which the identification tool will be applied (marking code in graphic form), it will be considered unmarked and there will be appropriate penalties for its circulation.

As an illustration of solutions related to national marking systems known from patent sources, one can indicate a hardware and software system designed to create a distributed system for ordering, issuing and controlling unique product marking codes, disclosed in patent document RU 2183349 C1, published on 10.06 .2002.

The known solution contains a central server and peripheral workstations (workstation) connected by data transmission channels. A functionally known tool ensures the acceptance of orders for the release (issue) of marking codes, the transfer of codes for printing and application to their products. Validation of codes during printing and their identification on the way of promotion of goods is carried out in the usual way for this field of technology.

At the same time, the well-known complex does not allow automating business processes that lie outside of such systems (systems that directly carry out marking), as well as solving the above-mentioned problem of distortion of marking codes during their transmission, the problem of the lack of transmission control and the status of the marking code and quality verification transformation into a means of identification, as well as the problem of integrating the marking system with the equipment of the turnover participant.

National labeling systems, such as the “Honest Sign” project in the Russian Federation, do not have links with other labeling systems in countries where mandatory labeling of goods is also being introduced. Each system is autonomous and serves a local market. Providers of services for converting (printing) the marking code are not members of state information systems serving marking, i.e. they do not have access to them (because they are not participants in the circulation of products subject to mandatory marking) and cannot receive marking codes directly from national Marking Operators .

At the same time, service providers, such as printing houses, serve counterparties not only from the countries of their immediate location, but also from foreign countries where mandatory labeling has also been introduced. Logistic warehouses, foreign production sites also work with importers from all EAEU countries. Thus, there is a clearly expressed business need for the existence of a single environment, a cloud platform (service) that will connect the participants in the circulation of marked products from different countries and allow them to exchange marking codes with service providers, while maintaining their integrity and ensuring guaranteed delivery of the marking code, control of the movement of the marking code (change of owner), its current status and expiration date.

The problem of the prior art also lies in the fact that the exchange of marking codes by e-mail and through any media, as noted above, for the most part leads to a violation of the integrity of the marking code, due to the presence of special and unreadable characters in its composition (for example, symbols of the Data Matrix in ISO/IEC 16022 ECC 200 is the only version that supports GS1 System data structures, including the special use of the FNC 1) function mark, which are mangled or stripped by programs that exchange or convert to various data exchange formats. As a result, the identification tool contains a distorted marking code that does not comply with the regulatory legal acts of the country that issued the marking code and the product on which such an identification tool is applied is considered unmarked in accordance with the current legislation, and a fine is imposed for the circulation of such products.

Another problem of the state of the art is the need to provide an accompanying document flow for service providers with participants in the circulation of products subject to mandatory labeling in order to exchange information about the change in the status of the labeling code with national Labeling Operators. According to the current requirements of national Labeling Operators, a participant in the circulation of products subject to mandatory labeling is obliged to report to the national Labeling Operator on changes in the status of the labeling code by sending relevant reports to state information systems. The implementation of such reporting is a serious problem if it is solved through multiple integration of accounting systems of service providers and participants in the circulation of products subject to mandatory labeling. This approach generates data loss and inconsistency in the states of the marking code in different systems for the participants in such a process.

Turnover participants need easier integration with the services of Marking Operators, through an intermediary system, which will take over part of the processing of information and simplification of business processes. Operator programming interfaces are quite complex to integrate, as a rule there are more than one, own interfaces for dedicated components. Also, Labeling Operators do not provide client-oriented services that simplify the implementation of labeling at production sites. For transnational participants in the turnover (companies doing business in more than one country where mandatory product labeling has been introduced), such integrations are extremely costly, especially if they use third-party information systems for their automation. Simultaneous integration of one information system that controls production processes in several countries with several Marking Operators requires a global redesign of management systems. Turnover participants have to reengineer business processes of production management.

Thus, there is a need to solve the problem of exchanging marking codes, documents and information between participants in national marking systems and service providers, especially international ones, through a centralized solution, a cloud platform (service) and the need to simplify integration processes with the infrastructures of Marking Operators for turnover participants, so or through providing them with a cloud platform (service), as a single window system, one entry point to all national Marking Operators.

The proposed invention is aimed at overcoming these shortcomings of the prior art and allows achieving the main technical results, which consist in ensuring the automation of guaranteed delivery of marking codes from the turnover participant to the service provider and to the production sites of counterparties, in order to eliminate the risk of distortion of the marking code and related workflow, including receipts , confirming the receipt of information and marking codes and reports on the use of marking codes in accordance with the requirements of national Marking Operators, as well as to simplify the integration of production sites of turnover participants, especially transnational ones, with the infrastructures of national Labeling Operators.

Disclosure of invention

To achieve these technical results, a distributed system is proposed, consisting of a number of functional components connected through network interaction. This is a natural model that implements the real-world connections between service providers and consumers (counterparties), creating an ecosystem that is maximally adapted to business tasks, allowing service providers to quickly find each other and customers and establish reliable connections, and turnaround participants to get a ready-made cloud solution , integrated with Labeling Operators of all countries where mandatory labeling of products is introduced.

The proposed invention is characterized by the following essential features: a system for the exchange of marking codes (delivery of marking codes) and related workflow, consisting of one segment or several geographically separated and connected by communication channels through the central server of the system or directly with each other, network segments, each of which is made on based on a hardware-software complex containing a server segment of the system, including: a subsystem of personal accounts, made with the possibility of registering participants with their division by types of participants into at least: Printing house, Logistics warehouse, Contract site, Goods circulation participant, Foreign manufacturer, Manufacturer Software or hardware, Customs broker, Content provider, Transport, Consulting; a security subsystem, including an authorization/authentication module, a system user management module that implements the functionality of managing the profiles of system participants, and an audit module (logging system actions and events); a subsystem of catalogs, including a module of the catalog of service providers, a module of the catalog of participants in the turnover, a module of the register of relations between participants in the turnover and service providers; a subsystem for the exchange of marking codes, including a document flow module, a module for controlling the rules of circulation and the use of marking codes, a register of identification codes; a network member rating subsystem, including a network member rating calculation module; a finance subsystem, including a billing module; an interaction subsystem that includes an API module (programming interface). The internal logic of the client part, as well as its functional architecture, is not disclosed in the framework of this invention, since ready-made solutions existing on the market, such as ERP systems, or automated production process control systems, can act as clients. The marking code exchange system provides / provides client systems with a program interface (API) for interaction, thereby defining the rules for information exchange with it (protocol). Integration with the System and implementation of information exchange rules defined by the programming interface data structures is the task of developers of client solutions, as well as the choice of a technological stack and a set of functional components of a client solution.

The following section of the description provides detailed information that discloses the invention, indicating the means and methods for its implementation and confirming the possibility of achieving the above, as well as other technical results following for a specialist from the description.

Brief description of the figures of the drawings

The essence of the invention is illustrated by drawings, where:

in fig. 1.1 shows a variant of the system topology with a central server;

in fig. 1.2 - a variant of the topology of the "ring" system;

in fig. 2 is a diagram of the functional architecture of the system;

in fig. 3 - scheme of functional interaction;

in fig. 4 - block diagram of the algorithm for sending an application for the emission of CM;

in fig. 5 - block diagram of the algorithm for obtaining CM;

in fig. 6 is a block diagram of the CM printing algorithm.

Implementation of the invention

The description below presents the invention in its preferred embodiment, which is not intended to limit the scope of protection. For a specialist it will be clear that the elements of the system presented in illustrative versions, indicated by the concepts used in the description, can also be partially or completely replaced by identical or intersecting concepts that characterize the means that allow performing the corresponding functions.

The examples described are merely possible embodiments of the invention. Unless explicitly stated otherwise, components and functions may not be used in all variants, may be used in various combinations and may be separated, and, in addition, the sequence of actions (stages) may vary, their various combinations may be used, and some stages can be separated. In the following description, in order to provide a clear understanding of the discussed embodiments of the present invention, various specific details are indicated. However, the person skilled in the art will be clear that the invention can be carried out without some of these specific details.

Further, it is advisable to present some definitions used in the characterization and description of the operation of the proposed invention.

APCS - Automated process control system. The main software that manages production lines or printing processes for project participants.

DB - Database.

IS - Information system.

GIS - State Information System of the national Marking Operator in countries with mandatory marking.

KM - Marking code. The marking code is an alphanumeric sequence in electronic form, formed according to the rules defined in the relevant legal acts. The labeling code is issued (issued) by authorized national Operators, whose powers are determined by state authorities in countries where mandatory labeling of goods is being introduced.

PAK - Hardware and Software Complex.

UOT - Participant in the circulation of goods.

ERP (Enterprise Resource Planning) is a software package that implements a strategy for integrating production and operations.

Service providers - Printing houses, contract manufacturing sites, logistics warehouses, bonded warehouses. Third parties that are not participants in labeling systems or the circulation of labeled products. They provide services for converting CM into SI and other related services to participants in the circulation of goods subject to mandatory labeling.

Means of Identification (MI) - A marking code in a machine-readable form, presented in the form of a bar code, generated in accordance with the requirements stipulated by the requirements of the regulatory legal acts of countries where mandatory marking has been introduced, for application to consumer packaging, or to a label or sticker.

Converting a marking code into an identification tool - The process of encoding an alphanumeric representation of a marking code into a graphic identification tool (sign) in accordance with the requirements of GOST R ISO / IEC 16022-2008 "Automatic identification. Bar coding. Data Matrix symbology specification". In the coding process, the symbolism of the ECC 200 version and the sign of data compliance with the standard format of application identifiers (Al) GS1, in accordance with section 11.1 of the above GOST, must be used.

Verification of the conversion of the marking code into an identification tool - Evaluation of the quality of the application of the identification tool for compliance with its structure to the requirements of the regulatory legal acts, as well as the quality of printing in accordance with GOST R ISO / IEC 15415-2012 and the correctness of the conversion of the marking code into an identification tool in the DataMatrix format in accordance with requirements of GOST R ISO/IEC 16022-2008, ECC version 200 symbols, with a sign of data compliance with the standard identifier format (Al) GS1.

National Labeling Operator - A state or commercial organization (usually operating on the PPP model) that develops, develops and maintains a national product labeling system in countries where mandatory product labeling has been introduced.

In a generalized form, the infrastructure of the proposed system is shown in Fig. 1.1 and fig. 1.2. As shown in this illustrative embodiment, the infrastructure of the system can be implemented in several different topologies. Listed in Figs. 1.1 and fig. 1.2 options are recommended and typical, but not the only and final, the system, among other things, may consist of one server.

The functional components of the server (segment) of the system are described below, each network segment contains the same or adapted to the goals and objectives of the segment, a set of functional components. It should be noted that each segment of the system includes the “Interaction” subsystem, consisting of modules that provide communication between the segment and other segments, systems of national Marking Operators and client solutions of turnover participants and service providers.

It should be noted that this structure can be easily scaled both in the direction of territorial increase and narrowing. For example, system segments can be located in regions of the same country, or also in any other countries participating in the mandatory product labeling program.

Hereinafter, for the sake of brevity, the description does not directly provide the corresponding functional or informational links between the modules. At the same time, these connections are characterized by indicating the functions of each of the modules and are described in the processes of interaction between the modules, and the reflection of the connections in the explanatory drawings fully reveals the essence of the proposed invention.

Thus, within the framework of this application, the term "module" refers to a part of the system that performs well-defined functions. The specific internal execution of the module does not matter for the possibility of functioning of the system as a whole, since the specialist, based on general knowledge, can choose a structurally complete tool that performs certain functions and replace it with another that performs the same functions. For example, structurally, the module can be a programmable logic integrated circuit (FPGA), the logic of which can be set by programming using a programmer and a debugging environment (IDE) based on the algorithms or block diagrams (Fig. 4-6) of operation presented in application materials. Also, a module can be, for example, a read-only memory device with a program code placed on it, the execution of which by the computer processor leads to the implementation of the functions prescribed by the code. In suitable embodiments, the implementation of the module may be a means for controlling electronic devices (for example, a print controller).

The following are particular cases of possible embodiments of the modules included in the proposed system.

As a non-limiting example, the authentication/authorization module may be a trusted boot hardware module using the security model that is preferred in one case or another. The security model may be, for example, a discretionary access model, a mandatory access control model, distributed system models (synchronous and asynchronous), an access rights transformation model, a hierarchical model, a secure specification model, an information flow model, as well as other models known from the prior art. , presented, for example, in the source [1] (V.A. Konyavsky, Management of information security based on the information security facility of the NSD "Akkord", M.: Radio and communication, 1999), which is part of the description to the extent that reveals more detailed information about the possibility of implementing certain features.

In the claimed solution, as in the noted prior art [1], the authentication/authorization module should require users to identify themselves when requesting access, and should also authenticate the subject identifier - perform authentication. The module must have the necessary data for identification and authentication and must prevent access to protected resources by an unidentified user or a user whose identity was not confirmed during authentication. The module must be able to reliably associate the received identification results with all actions of a given user. ([1], p. 70). Within the framework of this application, the authentication/authorization module may, according to the specified prior art, include a touch-memory interface, non-volatile memory, a random number generator, a ROM BIOS. In addition, a communication interface with a computer should be organized ([1], p. 100). The structure and choice of hardware, as well as their relationships to implement the authentication/authorization module can be easily determined by a person skilled in the art based on the prior art (see, for example, [1], pp. 100-130). For example, the authentication/authorization module can be based on the "Akkord 4++" controller and corresponding buses and interfaces ([1], p. 107). Also, the procedure for performing authentication/authorization will be clear to a specialist, since this seems obvious from the prior art (see, for example, [1], pp. 132-137) and its specific type is not included in the scope of legal protection of the proposed solution.

At the same time, it should be noted that hereinafter, in each of the modules included in the system, the operation of which requires selective / limited / trusted access to system resources (for example, the right to access certain operations), access control means should be understood as the means by which the resources of the data processing system are provided only to an authorized subject in accordance with the established access rights (see [2] GOST ISO / TS 22600-3-2013, clause 3.1).

For example, the operation logic of the user management module of the system can be specified taking into account the tools and algorithms known from [2].

In particular, the access control decision function (ADF) is a specialized function that applies the access control policy rules to the required action to make an access decision. Policy (policy) refers to a set of legal, methodological, organizational, functional and technical obligations or prohibitions on the exchange of information and joint activities.

The access control enforcement function (AEF) is a specialized function that provides a requester with access to a required resource in accordance with the decision made by the access decision function.

Access control information is any information used for access control purposes, including context.

Accountability is a property that provides unambiguous tracking of the own actions of any logical object.

A claimant is an organization or person requesting that a controller perform or provide a sensitive service in accordance with the privileges specified in its attribute certificate or in the subject directory attribute extension of its public key certificate.

For example, when using web services, a web services policy specification (WS-policy) is a flexible and extensible grammar in XML language and is intended to describe the capabilities, requirements and general characteristics of objects of systems based on the application of web services in the form of policy information. web service specific to a particular subject area. It defines a set of policy alternatives, each of which is a set of policy declarations, such as authentication scheme, transport protocol choice, privacy policy, Quality of Service (QoS) characteristics, and so on. For policy compatibility, settings about the data dictionary and semantics can be used. The WS-Policy Attachment (Web Services Policy Attachment) specification describes how to associate policies with the subjects they apply to using WSDL descriptions.

In a particular case, Web Services Policy Language (WSPL) may be used, which is a limited subset of the OASIS XACML standard that provides policy mapping. Merged policies can be expressed using detailed attributes such as time of day, price, or network characteristics.

At the technological level, trust management can include:

- protocols by which the consumer of the service interacts with its provider. For example, SOAP (simple object access protocol) messaging may be required over HTTPS;

- unique identification of all persons of interest; these include individuals who have the roles of consumers, contractors, or employees;

- providing shared access to information required by the internal structures of the enterprise and external partners.

For example, a login policy can be defined to automatically create user accounts (an LDAP directory or database with account ID joe for Joe Smith) in an enterprise store (account ID joesmith for Joe Smith) and an object identity service system (account application layer ID joe1234 all for the same user Joe Smith).

This policy can be extended beyond the boundaries of the enterprise, for example, a user account is also created in the register of external consumers of the service (with the identifier homejoe for Joe Smith). This enrollment policy can include multiple workflows, such as obtaining permissions to manage users.

An integral part of these registration policies are the identity and password policies. Identity policies describe how the different attributes of different accounts are created based on the user's identity information and corporate security rules.

In this example, the identity policy might be to create an account name that consists of the first letter of the user's first name and the letters of the user's last name (for example, jsmith for Joey Smith). The identity policy can extend to other attributes, such as e-mail addresses.

Password policies can be used to control how passwords are created and managed. For example, a policy might specify a minimum password length, require the use of letters and special characters, and an expiration date that forces users to change their passwords every three months. Compliance with these requirements enhances the security of the system, since the weakness of passwords creates known risks.

The audit module in the proposed invention is preferably used to collect, store and analyze logs (logs) of the system, for example, in order to track (prevent or investigate) security incidents (for example, the same as in [3] Journal "Information Security", # 1 , 2013, p. 47) in accordance with PCI DSS.

The process of logging (journaling) is an automatic recording of events occurring within a certain process. Logging allows you to evaluate the state of the process and log errors. The main advantage of using logging is to provide the ability to control the process of executing the business logic of both a separate process and the system as a whole. Direct consumers of data provided by the logging system can be: developers and software maintenance service; system administrators and information system analytics security administrators.

The logging process can be logically divided into several stages: registration of events and transfer of information about them to the data warehouse; analysis and structuring of the received data and their recording in the storage; storage data monitoring and logging process management.

Comparing each logically identified stage with its own level, we get a three-level system: 1) Client level; 2) Database level; 3) The level of administration (see, for example, [4] Journal "Modern Science: Actual Problems of Theory and Practice", Series: Natural and Technical Sciences No. 4 April 2019, p. 48, fig. 6).

Logs can be collected from all equipment within the scope - from server operating systems, from managed network equipment, from all data storage locations, as well as from all data access software. In the presence of virtualized components, it is possible to collect logs, including from hypervisors, in order to exclude the possibility of forgery at the virtualization management level. Logs can also be maintained by additional security systems: antivirus, intrusion detection system, integrity control system.

By type, logs can be divided into the following: system logs, that is, those that are associated with system events; server logs that record calls to the server and the errors that occurred during this; database logs that record queries to databases; mail logs related to incoming / outgoing letters and tracking errors due to which letters were not delivered; authorization logs; authentication logs; application logs installed on these operating systems.

In a particular implementation, the authentication / authorization module and the audit module can be combined based on Avocent hardware, which is a centralized Out-of-Band management system, including a redundant and scalable DSView 3 management system, a data center infrastructure resource accounting system (Asset Management ) AMIE, Out-of-Band control hardware, workstation interface remote removal (over IP or CAT5), local KVM switching for technology enterprises and data centers.

The catalog subsystem, which is described in more detail below in the description, includes a module for the catalog of system participants, as well as a module for registering links between system participants.

The basis for the implementation of these modules can be such concepts as an entity (thing), class (class), relationship (Relationship) in accordance with [5] - GOST R ISO 15926-2-2010 in relation to materialized physical objects. In particular, such objects may include physical sectors of a computer-readable storage device that stores data about system participants and system services (licenses) available to them, which facilitate the establishment of communication between participants and their places of business, thereby allowing them at the system level interaction with each other. By executing the instructions stored on the machine-readable medium, the server processor can determine and present data on the space-time relationships between the participants ([5], clause 4.7.3), which can then be used in the operation of the specified system modules, as shown below in the description.

When implementing the document management module, documentation is understood as the documentation of the document management system (DMS), which is the documents that need to be managed in an automated document system ([6] - GOSTR 7.0.101-2018 / ISO 30301:2011).

When participating in electronic document management, there is always a risk of unauthorized access to information exchange. Electronic signature (EDS) can be used to protect participants in electronic exchange in documents. EDS, as an attribute of an electronic document, is designed to protect it from forgery, obtained as a result of cryptographic transformation of information using the private key of an electronic digital signature and allowing to identify the owner of the signature key certificate, as well as to establish the absence of information distortion in the electronic document.

Cryptographic transformation should be understood as a type of information encryption that ensures its confidentiality, the possibility of unambiguous identification of the person - the sender of information and excluding the possibility of its unauthorized change; such encryption of information is carried out through the use of digital signature tools.

EDS tools should be understood as certified software / hardware tools that ensure the implementation of at least one of the following functions: creating an EDS in an electronic document using a private EDS key, confirming the authenticity of an EDS in an electronic document, creating EDS private and public keys.

The EDS private key is a unique sequence of characters known to the owner of the signature key certificate, intended for creating an EDS.

EDS public key is a unique sequence of characters corresponding to the private key, available to any user of the information system and designed to verify the authenticity of an electronic document and identify the person from whom the document originates; the EDS public key is issued in the form of a signature key certificate and transferred to other participants in the closed information exchange.

Signature key certificate - a document on paper or an electronic document with an EDS of an authorized person of the certification center, which includes an EDS public key; the certification center issues a document for the signature key certificate to the information system participant to confirm the authenticity of the digital signature and identify the owner of the signature key certificate.

Thus, in the proposed solution, the marking code exchange subsystem can be a set (cluster) of interconnected servers, one or more of which are allocated to perform document management functions using software and hardware, including a repository of signed documents, a repository of certificates, as well as hardware keys (tokens) used to generate and sign EDS documents. In this case, within the framework of this application, the marked dedicated servers should be taken into account as a means that performs the functions of a workflow module.

Taking into account the above information about the implementation of the marking code exchange subsystem as a cluster of servers, one or more of these servers can be assigned the function of a module for controlling the circulation rules and the use of marking codes.

In particular, the function of the module for controlling the rules of circulation and the use of marking codes can technically be implemented in the form of a BRMS (English Business Rule Management System - business rules management system) - an information system used to maintain, support and execute the company's business rules (see ., for example, [7] - OMG BMM Business Motivation Model v1.3, 05.2015)

Predetermined logical functions performed by the module for controlling the rules of circulation and use of marking codes, located on the physical sectors of the memory of a computer-readable storage medium, can be performed by the processor of the server included in the cluster of servers of the marking code exchange subsystem.

The API module is a standard interface designed for interaction between users and/or system software. Thus, this module is an integral part of the system for the possibility of interaction of its components in order to implement the purpose indicated in the generic concept.

The billing module in this application can also be viewed as a system that calculates the cost of services for each client and stores information about all tariffs and other cost characteristics that are used by operators for billing and settlement with other service providers. For example, the billing module may be an automated billing system (ACS).

In particular, the ACP Onyma Billing solution known from the prior art (Certificate of Conformity OS-3-ST-0677 dated 11/01/2019) can be considered as a means for implementing this module. This solution includes a Web control server, workstations for operators, an administrator, an analytical subsystem, a system core, an authorization and statistics collection center, and a Web registration and statistics server. The interaction of users with the ACP occurs through the equipment for providing services (user's computer, mobile terminal through a thin client).

The billing system Onyma Billing allows you to describe the physical and logical resources of the company, organize the effective management of these resources in close integration with the billing system and the authorization system. The system provides a full service cycle, and prepaid customers, exactly in accordance with the contract, will be automatically disabled by the system from receiving services as soon as they run out of funds.

In Onyma Billing, the system for collecting, downloading and primary billing of service consumption statistics takes place in authorization centers. They perform the main computing work and relieve the main core from which the system operators work and provide operators with an efficient work when serving users. The number of authorization centers is not limited, they can be placed in a geographically distributed network and serve all company branches with different types of services and tariffs on one core of the billing system.

The authorization and statistics collection center provides equipment management, authorization (RADIUS), pre-billing and primary billing, provision of services in the absence of communication with the core. The analytical subsystem provides a constructor for generating analytical reports, scheduled generation, uploading to a file of the required format (Excel, XML, CSV, PDF), sending reports by e-mail.

The integrating core of the ACP "Onyma" is the resource management system responsible for the description, management and configuration of all the resources available to the operator, both physical and logical: equipment, channel infrastructure, address space, price lists, customer base, etc. The system is capable of independently managing equipment by generating configuration files and sending control actions, as well as identifying external infrastructure changes by receiving appropriate XML notifications. Thus, the system at any time has full information about what resources are used by whom, which allows organizing effective management of the infrastructure as a whole and is a good basis for building CRM systems and monitoring systems (some functions of these systems are implemented directly in the Onyma ACP ). The core of the system supports a set of methods for working with data, which can be used by any of the systems working with it ([8] - "Billing", # 6, 2002, p. 10-12).

Taking into account the capabilities of the known system noted above, on the basis of a similar solution, a subsystem of the rating of network participants can be implemented, including a module for calculating the rating of a network participant (in particular, in the form of an independent set of servers united for joint operation). In this case, the core of the system (which can be considered a module for calculating the rating of a network participant) will receive information from the user through the interaction interface regarding the rating of participants. This information will be accumulated in the system, updated in a timely manner and provided to users as needed (for example, upon request).

The above examples do not limit the implementation of the listed modules. As mentioned earlier, the algorithm for the operation of a particular module can be programmed in a specialized FPGA, or placed on the physical sectors of a computer-readable storage medium. Thus, within the framework of this application, the concept of "module" should be interpreted in an inseparable connection between the hardware (or a set of interconnected tools) that performs certain functions and the algorithm of operation, placed on a physical storage medium.

The main asset and object in the proposed system is the marking code and services for its guaranteed delivery without distortion and verification of the quality of transformation into an identification tool. The system also provides for the exchange of documents and information within the accompanying workflow, such as: orders for the issuance of marking codes, reports on changes in the status of the marking code, receipts for the movement of the marking code, etc.

The marking code is an alphanumeric sequence containing special characters, some of which are FNC codes, in accordance with the GS1 specification, some are special characters included in the Base64 dictionary. This alphanumeric sequence requires very careful handling, otherwise it is distorted (there is a loss of special and unreadable characters) and the turnover participants get the problems described in the section above.

The marking code is a cryptographically protected asset, the handling of which is regulated by the threat models of national marking systems and related legal acts. Therefore, the proposed system provides a functional component that is responsible for compliance with these rules and information security requirements when handling marking codes, implemented in the module for controlling the rules of circulation and use of marking codes.

The marking code has a lifespan determined in the legal acts of the countries. It is necessary not only to deliver the marking code to the service provider, but also to check that he uses it before the expiration date. The expiration date determines the time that is released by the national Marking Operator of a particular country, the participant in the turnover from the moment the marking code is received from the national Operator until the marking code is converted into an identification tool and sent to the information system of the national Marking Operator that issued the marking code, the corresponding message (report on the use marking code). In the proposed invention, this feature is implemented in the module for controlling the rules of circulation and the use of marking codes.

Network participants are participants in the circulation of products subject to mandatory labeling in countries where such labeling is introduced as mandatory and who, in turn, are users of the relevant information systems (usually state-owned) that serve the participants in the circulation in countries.

Also, the participants are service providers that provide services for converting the marking code into an identification tool and / or printing an identification tool on a label, container or packaging (directly labeling), turnover participants.

The root services of the system are connected by transferring arrays of marking codes between system participants, data on marking codes and actions with / over marking codes and converting marking codes into identification means (accompanying document flow), generated by identification means validation mechanisms and sent to the information systems of national Marking Operators.

Proposed invention:

1. allows you to remove the distortion of the marking code, ensures guaranteed delivery of the marking code between system participants

2. provides services for supporting related workflow, such as: transfer of documents for aggregation of marking codes, transfer of documents on changing the status of the marking code, using the marking code, converting the marking code into an identification tool indicating the print quality class, etc.

3. traces the movement of the marking code from one system participant to another, provides this process with the appropriate receipts

4. provides traceability of changes in the status of the marking code within the system

5. Provides a single entry point to all services of Labeling Operators of countries where mandatory labeling of products is being introduced for participants in the turnover

6. Abstracts the turnover participant from the complexity of the programming interfaces of the Marking Operators, providing more convenient mechanisms for interacting with their infrastructures.

For example, as shown in FIG. 1.1, the central server of the system can ensure the delivery of the marking code (for example, from the segment of Kazakhstan to the segment of Kyrgyzstan) and ensure the delivery of reports and information from Kazakhstan to Kyrgyzstan, in accordance with the requirements of the national Marking Operator of Kyrgyzstan. Shown in FIG. 1.1 connections are illustrative, at the same time, within the framework of the proposed invention, the choice and establishment of connections is not limited to the specified and can be carried out depending on market requirements (two-way connections, multi-way connections, etc.), as well as the topology of the system network is not limited to the options illustrated in FIG. 1.1 and Fig. 1.2.

In general, the system allows you to provide the following functions:

1. Registration of participants;

2. Interaction with the national marking systems of the Operators of the countries;

3. Registration of orders for the emission of marking codes and their sending to the marking systems of the Operators of the countries;

4. Obtaining marking codes from the systems of national Operators of countries

5. Transfer of marking codes within the system, for example, to a service provider to ensure application or to the participant's own site;

6. Keeping records of sent codes;

7. Control of terms, including the life (shelf life) of the marking code;

8. Delivery of a report on the use of marking codes from the client of the service provider to the turnover participant that issued the marking code, or to the national system of the Marking Operator;

9. Control of the status of the marking code within the system;

In the preferred embodiment, the proposed invention represents parts interacting with each other - the server part (directly the system server, the system segment server) and the client parts of the participants of service providers and participants in the turnover.

It should be noted that the described solution does not directly process documents and execute orders for the issuance of marking codes, since they can only be processed by the national systems of Country Marking Operators. The system is an infrastructure that provides the processes and interactions between system participants and information systems of country marking operators necessary for the delivery of documents, guaranteed delivery of documents, control of the life cycle of the marking code within the system, including the expiration date of the marking code, accounting and indexing of documents passing through the system documents and marking codes. It should be noted that the receipt of marking codes and their exchange between system participants is also documented as a separate type of internal, system document (i.e. a document not sent to the information systems of Marking Operators)

The overall functional architecture of the system is shown in Fig. 2.

All documents passing through the system are processed according to a single algorithm, entering the "Interactions" subsystem and passing through the "Marking Code Exchange" subsystem, are registered and indexed, and sent through the "Interactions" subsystem to the national systems of Marking Operators, or to client systems turnover participants and service providers.

The process of processing an incoming document and the system modules involved in it, as well as the tasks performed by them, are described in more detail below.

To interact with the system, the user must pass authorization/authentication. To do this, it calls the corresponding method of the "API" module of the "Interaction" subsystem and sends a request for authorization/authentication. The API module, in turn, refers to the "Security" subsystem, with the task of checking the user's access rights. The "Authorization/Authentication" module of the "Security" subsystem refers to the "User management" module of the same subsystem. The "User management" module checks the presence of a user in the system, checks the data transmitted by the user against its database and accesses the "Catalogs" subsystem to check the user's access rights. The following modules of the "Catalogs" subsystem take part in checking the user's access rights:

1. Directory of system participants - the status of the participant is checked, that he is active, he has available services.

2. Register of connections between system participants - in case of sending a document to another system participant, it is checked that there is a connection between them duly registered in the registry and the participant has the right to send such a request to the system

The "Catalog of system participants" module is responsible for saving and selecting information about system participants and system services (licenses) available to them; it provides services for the user interface and for other system subsystems that provide functions: entering a new one, selecting data for an existing one, deleting, editing , necessary for saving and selecting from databases information on system participants. Separate module methods are designed to process and select information about the system services available to the participant (license) - this is a simple list that includes service identifiers available to the system participant, which can be added or removed using service methods, you can also get a complete list of services. The full list of services is also stored in the database of the "Catalog of system participants" module in the form of an editable list. Editing the list of system services is available only to the system administrator in his personal account.

The module performs format-logical control of requests for compliance with system data models and saves the received information to the database. A system member is an entity that represents a user account. One account can contain an unlimited number of users associated with it, for which the "User Management" module, security subsystems, and an unlimited number of different places of activity are responsible, such as: office, production site, printing house, warehouse, etc.

The "Register of connections between system participants" module implements the functionality of saving connections between participants. In a system where the basis is precisely the interaction between the participants in terms of the exchange of documents and marking codes, it is necessary, in order to prevent user errors, to have the functionality of explicitly establishing a connection between the participants and their places of business, thereby allowing them to interact with each other at the system level. with a friend. Communication is used as a filter in data exchange requests, thereby preventing system participants between which communication is not established from accidentally sending documents or marking codes to each other. The "Register of connections between system participants" module provides services for the user interface and other system modules that provide functions: entering a new one, selecting data on an existing connection, deleting, editing necessary to save a connection and select data about connections from the module databases. The module performs format-logical control of requests for compliance with system data models and saves the received information to the database.

In case of successful passing of authorization/authentication request checks in the "Catalogs" subsystem, the "User management" module returns a positive response to the module

“Authorization/Authentication”, which, in turn, generates a response to the user and sends a notification of successful authorization/authentication to the “Audit” module, which saves it to the database (system log). The result of processing a request for user authorization/authentication is a client token that gives the right to access the methods of the "API" module. The client application must store the received token in its database for later use.

The client token has an expiration date set in the system settings. Upon expiration, the client application must repeat the authorization/authentication procedure.

The "User Management" module consists of a database of system users (one member of the system, a user account, more than one user can register), the module provides services for the user interface and other system components for working with users: entering a new one, selecting data for an existing one, deleting , editing.

The "Authorization/Authentication" module is responsible for receiving a request for authorization/authentication, checking the structure of the request, generating a request to the "User Management" module, obtaining the result of user request checks and returning the result of authorization/authentication to the "Interaction" subsystem, "API" module, saving the result to the system log, by accessing the "Audit" module and saving the client token to its database, where it will be used during verification by other system modules. The "Authorization/Authentication" module is also responsible for issuing information about the client token (belonging to the user, expiration date) to other modules of the system.

The Audit module provides services for writing messages to the system log and fetching the system log from the database for reading. You cannot make changes to the system log or delete entries from it, therefore editing and deleting operations are not supported by the module. The “Audit” module, having received information for writing to the system log as an incoming message, formats them in accordance with the rules for filling in the system log, and records and returns as confirmation of a successful save operation the record identifier in the system log, which is used by other modules for reference on the events and receipts saved in the system log.

Also, in response to a call to the corresponding system log sampling method, with or without parameters (for example, filters specifying a sampling range, a unique record by its identifier or a component whose logs are needed), the “Audit” module returns system log records corresponding to the request made .

After successful authorization/authentication, the user of the system can send a document to it.

Sending a document begins with its transfer by the client application to the "API" module of the "Interaction" subsystem. All methods of the "API" module, except for authorization/authentication, require as a mandatory parameter the client token received by the client solution after successful authorization/authentication.

The "API" module, having received the document, performs format-logical control, for which it uses the validation rules that are part of the logic of its work and are the implementation of the protocol for interacting with client systems (rules are a description of a set of document fields, types of fields, a logical connection between fields, for example, if field A is filled, field C must be filled). In case of successful completion of the check, which is carried out synchronously (i.e. the connection with the client is not broken, it is held for the duration of the check), the API module assigns a unique identifier to the document and returns it to the client system, saves the received document to the database, enters it into the system log receipt of the successful acceptance of the document, through an appeal to the "Audit" module.

Also, the "API" module, in response to requests from client applications, provides the following, typical, but not final, set of operations:

1. Checking the status of the order for the emission of marking codes;

2. Selection of marking codes from the order;

3. Receipt / acceptance of a report on the use of the marking code;

4. Receipt / acceptance of a report on the cancellation of the marking code;

5. Receipt / acceptance of a report on the aggregation of the marking code;

6. Obtaining the composition of the document (list of identification codes or marking codes) by document identifier;

7. Unloading of incoming documents for the client of the system;

8. and others.

All requests are processed through a typical interaction with the relevant system modules and are processed according to a typical process, which is described in this section.

The API module, having saved the document to the database, passes a link to it to the Document Management module, which in turn selects it from the database, determines the type of document, and then, in accordance with the rules for processing a document of this type, the Document Management module performs its routing . Since each document is part of the life cycle of the marking code, i.e. affects its status in the system, the "Document Management" module sends a message about the life cycle event of the marking codes included in the document to the "Register of identification codes" module. Further, the "Document Management" module determines the recipient of the document, if it is another member of the system, then the document is saved to the system's document database indicating the recipient, if the document needs to be transferred to the information system of the Marking Operator, the "Document Management" module calls the module "Interaction with information systems of the Marking Operators ” and gives him a document to send. Next, the workflow module performs indexing of the document, i.e., the formation of the document metadata in accordance with the specified rules for this type of document and its entry into a specialized search database. Indexing significantly speeds up the search and selection of documents in large repositories, and also facilitates the accounting of documents passing through the system. All components of the system, when searching for documents according to specified criteria, turn to the services of the "Document Management" module that work with indexes. Directly in the document repository, in the database, documents have only one index - their identifier, by which documents are retrieved from the repository.

Next, the "Document Management" module creates receipts for successful indexing and successful routing of the document to the recipient and passes them to the "Audit" module for saving in the system log.

Further, the "Document Management" module makes a record in the history of the document, with a link to the receipt (its identifier in the system log)

The Document Management module provides the user interface, as well as other system modules, with interfaces for working with documents and the document indexer: saving, editing, deleting, searching by specified parameters in the document index, and methods for writing to the document history used in the life cycle by other system modules.

If the recipient of the document is a member of the system, this completes its life cycle, the document waits for the recipient to contact the API module to upload incoming documents, or through the user interface of the personal account.

If the recipient of the document is the information system of the Labeling Operator, then its further processing goes to the module "Interaction with the information systems of the Labeling Operators".

The module "Interaction with Information Systems of Marking Operators" is responsible for converting the source document of the system into a data format supported by a specific Marking Operator and sending the document to the information system of the Marking Operator. The module "Interaction with information systems of Marking Operators" generates a receipt for the successful sending of the document to the information system of the Operator and passes it to the "Audit" module for saving in the system log.

Further, the module "Interaction with information systems of the Marking Operators" through the appeal to the services of the Marking Operator checks the status of document processing and, having received the appropriate receipts, passes them to the "Audit" module for saving in the system log and the "Document Management" module for saving in the history of the document.

If a document sent to the information system of the Marking Operator involves the performance of certain actions by the information system of the Operator, the result of which will be a new document, for example, a completed order for the emission of marking codes, the module "Interaction with the information systems of Marking Operators", unloads this document from the information system of the operator, enters a record of the successful completion by the Marking Operator of the task of processing a document in the history of the original request document (for example, an order for the emission of marking codes), through an appeal to the appropriate service of the Document Management module designed to make entries in the history of the document.

The document received from the Marking Operator is transferred to the "Document Management" module for routing in accordance with the rules specified for this type of document.

Some, but not all, of the typical processes for working with documents in the system are presented for illustrative purposes in FIG. 4, 5, 6.

The Identification Code Register module is a database of identification codes and their life cycle events.

The identification code is a marking code, without a crypto part, i.e. without protection, which is used in a number of countries where the labeling of goods is being introduced and which is prohibited by the regulatory legal acts of these countries. The Identification Code is a unique item identifier, consisting of a trade item identifier (mainly used GTIN, from GS1) and a unique serial number assigned by the manufacturer or importer (marking code issuer)

Life cycle events are generated by the document flow and come to the registry from the "Document flow" module in the process of document routing. Event examples:

1. Emission - is generated by the document “marking codes order”, marking codes enter the system as part of the completed order for the issuance of marking codes from the information system of the Marking Operator.

2. Use - is generated by the documents "validation of marking code application", "application of marking code on finished products" and others.

3. Cancellation - generated by the documents "rejection of the marking code" or "cancellation of the marking code due to refusal of the order for the emission of marking codes".

4. And other documents, the composition of which varies depending on the country and product group.

An event is an entry in the marking code history that refers to the original document (document ID) in the document store and refers to an entry in the identification code registry (identification code). The event has a date, time, type (depends on the document type).

Also, the registry of identification codes contains records of violations in the life cycle, the rules for determining violations vary, but in the general case, a repetition of the same event from the same source is considered a violation. For example, re-applying a marking code to finished products is a gross violation.

The registry provides other components with services for writing data to it, the main supplier of data to the registry is the "Document Management" module, which sends lists of identification codes, the name of the event and the ID of the document that generated this event to the registry.

The registry provides the system user interface and other modules with services for obtaining entries from the registry, the list of events by identification code, the list of identification codes by document ID, and others. Editing data in the registry is prohibited, deleting data in the registry is prohibited.

The register stores information about the expiration date of marking codes, which is used in its work by the module "Control of the rules of circulation and use of marking codes".

Entries in the registry are divided into active and processed. Processed - these are identification codes whose life cycle has already been completed, for example, they have been canceled or applied to finished products. Further, the system does not track their life cycle and the module "Control of the rules of circulation and the use of marking codes" does not work with them.

The module "Control of the rules of circulation and use of marking codes" uses in its work the database of the register of identification codes to control the expiration date of marking codes. Module "Control of the rules of circulation and the use of marking codes".

Responsible for the cancellation of marking codes within the system, by closing the corresponding orders for issuing marking codes that store expired marking codes. A special process of checking the expiration date of the module "Control of the rules of circulation and use of marking codes", running according to the schedule, scans the active records of the register of identification codes, compares the current date with the expiration date. If the date has expired, the module sends a command to the "Document Management" module to close the "marking code order" document that contains this code.

Also, the module "Control of the rules of circulation and use of marking codes" is responsible for creating records of violations of the life cycle of marking codes. Analyzing the marking code life cycle events in the register of identification codes, in accordance with the specified rules (which differ for different types of documents, product groups and countries), the module "Control of the rules for the circulation and use of marking codes" creates entries in the table of violations of the register of identification codes and generates the corresponding receipts by sending them to the "Audit" module, identifiers of entries in the system log are assigned as attributes to entries in the table of violations.

The module "Control of the rules of circulation and use of marking codes" does not provide services to other components of the system or the user interface, it does not have its own database and is a set of service processes that run on a schedule.

The subsystem "Personal Accounts" provides users of the system with forms for viewing, editing and submitting documents. Each type of document has its own screen form, a "list" form-representation, a search form, with the ability to set parameters/search conditions.

Also, the "Personal Accounts" subsystem provides the ability to edit the participant's profile, user profiles, a description of the services provided by the participant, data on his places of business and other information.

In the subsystem "Personal accounts" there is a form for searching service providers, by their descriptive part, metadata, list of services and other parameters.

A number of system functions:

1. Registration of a member of the system.

2. Registration of the place of business.

3. Establishing links between participants and/or places of activity.

4. System administration functions.

5. Billing functions.

6. Functions for working with documents.

7. Functions of work with the register of identification codes.

Available only in the "Personal Accounts" subsystem and in the "API" module of the "Interaction" subsystem are not implemented.

The "Billing" module of the "Finance" subsystem is responsible for generating invoices based on user statistics. Statistics is the document flow and invoices are issued, for the most part, but not only, on the basis of the marking codes passed through the system, their number, according to documents where the recipient is this system participant.

The "Billing" module, accessing the services of the "Document management" module with the appropriate requests, receives lists of documents, accessing the "Register of identification codes" module by document identifiers in the events of the marking code life cycle, receives the number of marking codes in documents and generates invoices for services rendered by the system.

The Billing module also uses information about the connected services available to this network member when billing. Services are billed on a monthly basis. The Billing module receives the list of services by calling the service methods of the Catalog of Network Participants module.

The "Network Member Rating Calculation" module is designed to store information about the current rating of the network member and its places of business. The place of provision of the service is considered to be the place where the activities of the network participant are carried out. A network participant may have more than one place of business. Participants establish links within the system, with each other and between places of activity, using the functionality of the "Register of links between system participants" module. After the connection is established, the system participant has the opportunity in the "Personal Accounts" subsystem to set a rating, an assessment for another participant, or his place of business. The rating is a number from 0 to 4. The overall rating of the participant or its place of business is calculated by the system as an average.

The module "Calculating the rating of a network member" provides the subsystem with personal accounts and other modules of the system with methods for recording the rating value and selecting the current rating of the member and / or his place of business. It is also a service for selecting a general list of system participants and their places of business with an indication of the current rating.

Rating change events are registered as receipts, which are sent by the Network Member Rating Calculation module to the corresponding service of the Audit module.

The scheme of the functional interaction of the system components and external systems is shown in Fig. 3.

So, according to Fig. 3, the API module is associated with the document management module, the authorization/authentication module, the audit module; the workflow module is also associated with the interconnected billing module and the module of the register of identification codes, as well as with the audit module; the audit module is also associated with the module for controlling the rules of circulation and the use of marking codes, which is associated with the module of the registry of marking codes, and the audit module is associated with the authorization/authentication module; the authorization/authentication module is also connected to the user management module, which is connected to the system participant directory module, which, in turn, is connected to the interconnected network participant rating calculation module and the system participant link registry module; moreover, one of the system servers is configured to perform the function of a central server. These connections can be provided, for example, by information exchange of signals over communication lines or through software interfaces.

It should be noted that within the framework of this application, the concept of "server" is not limited to execution in the form of any dedicated computing device. This concept should be interpreted in a broad sense, since it can also include the association of several or a cluster of servers, one or more interacting virtual machines, and the like.

Typical business processes of the system are presented in the diagrams shown in Fig. 4, 5, 6.

In the processes shown in the corresponding diagrams, third-party applications are indicated:

1. Client application.

2. Autosign client.

These applications are third-party and standard for labeling processes in countries that have implemented mandatory product labeling. For illustrative purposes and for ease of understanding, they are indicated in the diagrams, as they play a role in the described business process, but are not part of the solution described in this application.

In FIG. Figure 4 shows an exemplary algorithm for the interaction of parts of the system when sending an application for the emission of marking codes at the initiative of the service provider.

The specified algorithm is as follows.

The service provider selects the participant in the circulation of goods with which he has established a connection [1].

The Service Provider determines the method of generating individual serial numbers, either independently or by the national Marking Operator. If the service provider generates an individual serial number independently, then in order to apply for the issue of marking codes, it is necessary to generate individual serial numbers for each product code in the required quantity [2].

The Service Provider generates and sends an application for the issue of marking codes to the Client Application [3].

The client application receives a request for issuing marking codes [4] and sends a request for issuing marking codes to the System Server [5].

The system server receives an application for the emission of marking codes and performs verification of the application, including verification of the data of the service provider, the participant in the circulation of goods and the existence of a connection between them [6].

If the verification of the data of the application for the emission of marking codes is unsuccessful, then the System Server sends a message to the Client application with information about the errors that have occurred [7] [8] and the process ends.

If the verification is successful, then the System Server sends a request for issuing marking codes to the Autosignature Client [9].

The participant in the circulation of goods through the Autosignature Client considers the application for the emission of marking codes and if the participant in the circulation of goods agrees on the application, the Client of the autosignature signs the application for the emission of EDS marking codes of the participant in the circulation of goods [10]. If the participant in the circulation of goods rejects the application, then it is rejected.

After considering the application for issuing marking codes, the Autosignature Client sends to the System Server the result of considering the application for issuing marking codes [11].

Upon receiving the result of processing the application for the emission of marking codes, the System Server performs a check, and if the application for the emission of marking codes was rejected by the participant in the circulation of goods, the System Server rejects the application [12]. The process ends.

If the application for the issue of marking codes has been agreed by the participant in the circulation of goods, then the System Server sends the application to the Information system of the national Marking Operator [13].

The information system of the national Marking Operator receives an application for the issue of marking codes and processes it [14]. The process ends.

As can be seen from the proposed algorithm, the interaction of the parts of the system makes it possible to automate the process of sending and processing an application. If there is a connection between geographically dispersed segments, it is possible to automate the process of exchanging marking codes in different countries.

In FIG. 5 shows an exemplary algorithm for obtaining CM.

The specified algorithm is as follows.

The distribution system server generates a request for the issued marking codes for the service provider [1] and sends it to the National Marking Operator Information System [2].

The information system of the national Marking Operator receives the request [3] and checks for the availability of issued marking codes for the service provider [4].

If the issued marking codes for the service provider are found, then the National Marking Operator's Information System generates a package of documents for the service provider [5].

The information system of the national Marking Operator generates and sends the result of processing the request for the issued marking codes for the service provider to the System Server [6].

The system server receives the result of processing the request to receive the emitted marking codes for the service provider [7], and if the emitted marking codes for the service provider have not been received, then the process ends.

If the emitted marking codes for the service provider are received, then the System Server sends the emitted marking codes to the Client application for transmission to the service provider's site [8].

The client application receives the emitted marking codes [9]. The process ends.

In FIG. 6 shows an exemplary algorithm for printing marking codes. The specified algorithm is as follows.

The Service Provider selects a printing device and sends a request to the Client Application containing the parameters for creating a task for printing marking codes [1]. The request parameters include the application ID, product code (GTIN), printer device ID, label template ID.

The client application receives a request to create a job for printing marking codes [2], generates a job for printing marking codes [3], and sends the result of generating a job for printing marking codes [4] to the service provider.

The service provider receives the result of generating a task for printing marking codes, which contains the result of the operation, the identifier of the print job, and the list of marking codes [5].

At the same time, the Client Application sends a task to print marking codes to the Printing Device (printer) specified in the request [6]. The printing device (printer) receives the job to print marking codes [7] and executes the job to print marking codes [8]. The verifier verifies the applied identification means using vision cameras [9].

The client application generates reports on the application of marking codes and aggregation of identification codes [10].

The client application sends reports on the application of marking codes and aggregation of identification codes to the Information System of the National Marking Operator [11].

The information system of the national Marking Operator receives reports on the application of marking codes and aggregation of identification codes [12], processes the received reports [13]. The process ends.

Thus, the risk of distortion of the marking code is eliminated and verification of the means of identification is carried out.

The transmitted reports change the status of the marking code in the information systems of the national Marking Operators and within the system. Marking code registers are stored in the information systems of national Marking Code Operators. The marking code has a status model corresponding to its life cycle. The marking code is created (issued) by the information system of the national Marking Operator. At various stages of the life cycle, the CM of a commodity item can be in different states (statuses), the main of which include the following: “Issued” - this code status means that the marking code was issued to participants in the circulation to identify products; “In circulation” - this status of the code means that the marked products are in circulation; "Retired" - this status of the code means that the marked products and, accordingly, the marking code are out of circulation.

The system, by transmitting messages to the information systems of national Marking Operators, thereby changes the status of the marking code in the registers of marking codes of these systems. All events related to the life cycle of the marking code within the system are acknowledged (accompanied by electronic receipts protected by the EDS of the system). The main entity controlled by the system is the marking code. The processes associated with its delivery to service providers are described above, which convert it into an identifier.

The system implements the processes of tracking the movement and changing the status of the marking code, based on the submission of information (documents), in real-time processes, which is more convenient for integrators and allows for seamless integration into real business processes integration mechanisms. Based on the incoming information, the system generates the primary documentation required by the national Labeling Operators and sends it in the required order to the state information systems of the national Labeling Operators. Thus, the system provides automation of business processes, the implementation of which is not available in state information systems and implements a layer between them and the ERP systems of network participants, ensuring the correct and timely submission of information to the state information systems of national marking operators.

The marking code is converted into a means of identification by the service provider. Next, the identification tool is applied to the finished product to be traced. The marking code is issued by the state information systems of the national Marking Operators and at this moment it has a "owner", i.e. participant in the circulation of products subject to mandatory labeling, who ordered the issue of this labeling code from the national Labeling Operator. The fact of application of the means of identification to the finished product is fixed by a special report on the use of the marking code, generated by the client application based on data received from technical vision. This report is sent through the system to the information system of the national Marking Operator, this operation records the fact of applying the marking code. Thus, the information transmitted by the system to the information systems of national Marking Operators directly affects the history of the marking code and its life cycle in them.

Thus, the above description shows that when implementing the invention, due to the presence and provision of the possibility of interaction according to certain algorithms of parts of the proposed system, with the information systems of national marking operators and accounting systems (client solutions) of system participants, automation of guaranteed delivery of marking codes from of the turnover participant to the service provider with the elimination of the risk of distortion of the marking code, the accompanying document flow and control of the change in the status of the marking code are provided, as well as the possibility of system scalability and its seamless integration into existing real business processes. It should be noted that the implementation of the purpose of the invention with the achievement of the technical result is ensured not so much due to the presence of modules with their prescribed functions, but due to the proposed distributed architecture and the interconnections of the system components as it is presented in the form of a set of essential features of the formula and is described in more detail above in description.

Table 1 below shows an exemplary marking code life cycle status model that can be implemented within the proposed system.

Claims (1)

A system for exchanging marking codes and related workflow, consisting of several network segments spaced apart geographically and connected by communication channels, each of which is based on a software and hardware complex containing a system server, including: a subsystem of personal accounts, made with the possibility of registering participants with their division into types of participants for at least: Printing house, Logistics warehouse, Contract site, Goods turnover participant, Foreign manufacturer, Software or equipment manufacturer, Customs broker, Content provider, Transport, Consulting; a security subsystem, including an authorization/authentication module, a system user management module that implements the functionality of managing the profiles of system participants, and an audit module; directory subsystem, including a module of the catalog of system participants, a module of the registry of links between system participants; a subsystem for the exchange of marking codes, including a document management module, a module for controlling the rules of circulation and the use of marking codes, a register of identification codes; a network member rating subsystem, including a network member rating calculation module; a finance subsystem, including a billing module; an interaction subsystem, including an API module designed to connect client solutions of service providers and information systems and / or other client solutions of participants in the circulation of products subject to mandatory labeling, software interfaces for connecting system segments with each other and a module for interacting with information systems of Labeling Operators; at the same time, the interaction subsystem is configured to work with the client part of the service provider or turnover participant, which is made in the form of "thick" or "thin" clients; wherein the API module is associated with the workflow module, the authorization/authentication module, the audit module; the workflow module is also associated with the interconnected billing module and the module of the register of identification codes, as well as with the audit module; the audit module is also associated with the module for controlling the rules of circulation and the use of marking codes, which is associated with the module of the registry of marking codes, and the audit module is associated with the authorization/authentication module; the authorization/authentication module is also connected to the user management module, which is connected to the system participant directory module, which, in turn, is connected to the interconnected network participant rating calculation module and the system participant link registry module; moreover, one of the system servers is configured to perform the function of a central server.

Images