WO2020226531A2 - Способ удаленной верификации документов - Google Patents

Способ удаленной верификации документов Download PDF

Info

Publication number
WO2020226531A2
WO2020226531A2 PCT/RU2020/000097 RU2020000097W WO2020226531A2 WO 2020226531 A2 WO2020226531 A2 WO 2020226531A2 RU 2020000097 W RU2020000097 W RU 2020000097W WO 2020226531 A2 WO2020226531 A2 WO 2020226531A2
Authority
WO
WIPO (PCT)
Prior art keywords
document
counterparties
cloud
hash
parties
Prior art date
Application number
PCT/RU2020/000097
Other languages
English (en)
French (fr)
Other versions
WO2020226531A3 (ru
Inventor
Григорий Рачикович АРЗУМАНЯН
Original Assignee
Григорий Рачикович АРЗУМАНЯН
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Григорий Рачикович АРЗУМАНЯН filed Critical Григорий Рачикович АРЗУМАНЯН
Publication of WO2020226531A2 publication Critical patent/WO2020226531A2/ru
Publication of WO2020226531A3 publication Critical patent/WO2020226531A3/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/98—Detection or correction of errors, e.g. by rescanning the pattern or by human intervention; Evaluation of the quality of the acquired patterns
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof

Definitions

  • the invention relates to cloud services and can be used for
  • the technical problem of the prototype is that information is stored only on the cloud server, and when someone wants to add data to the cloud, he is forced to double-check the data added earlier.
  • the meaning of verifying edited documents is that the cloud service itself tracks the editing of documents, and other users trust it. But if desired, administrators of the cloud service resource can interfere with the process of editing user documents and read their confidential information, make edits to it. Therefore, there is no guarantee that a document created by users will be verified absolutely accurately and only by them without the intervention of a third party in the face of a cloud service.
  • the objective of the invention is to eliminate these disadvantages.
  • the technical result of the invention is the possibility of absolutely accurate remote verification of a document without the need to constantly check it for amendments by one of the parties, and without the possibility of reading or
  • the technical result is the possibility of remote notarial verification of documents, both with the presence of the parties at the notary, and without this presence.
  • the technical result is the possibility of remote conferencing in courts without the need for one of the parties to the trial to be present in the courtroom of their region.
  • the technical result is the possibility of remote interrogation of a witness or suspect, including at the international level.
  • the technical result is the possibility of verifying the documents for the goods, when the entire chain from the initial manufacturer to the final point of sale of the goods becomes public, which makes the sales market transparent for consumer control and taxation.
  • the claimed method of remote verification of documents characterized by the fact that the counterparties create a document proposed for certification by the parties, the counterparties exchange with each other an identical copy of the document in electronic form, sign their copy of the document with an electronic signature, place the signed copy in cloud storage using an application through which counterparties can upload these documents to the network, read documents, change the status of access to documents, characterized in that each of the counterparties and other users of the cloud network, using the cloud site interface and a special application working with it, create an account in the form of a unique identifier (ID), for which a private key is formed in the form of a sequence of randomly selected characters; the electronic signature of each of the counterparties is a public key, which is formed from a private key in such a way that if a message with a document from a counterparty is signed with a private key, then when the message is decoded, a public key can be obtained, and in addition to keys, information is stored in the cloud in the form of files on documents where
  • ID unique identifier
  • a verifier before gaining access to network documents, and persons holding a verification license are appointed as a verifier; the first of the miners, whose application has generated a hash for the verified document, places it in the cloud storage, and other miners use their applications to check the validity of the verification of the actions of the previous miner, and if one of the miners makes an error related to the presence of illiquid data, the applications of other miners correct the error automatically; in the event that all counterparties performed the function of signing a document with the same hash of the document, the document is considered signed by all parties - verified, about which through
  • the application is notified to each of the parties, and the hash of the document is generated available for download through the site server for all contractors at any time.
  • At least one of the verifiers is a notary, and in In the process of notarial verification of documents, a notary is able to identify the status of other notaries or other verifiers in the cloud network, while counterparties receive the status of a verified document from the notary without viewing it as the fact that the verified parties signed a certain document.
  • counterparties additionally give access to a copy of a document to a notary or several notaries, where each of the notaries checks the document for its compliance with the legal requirements, and if the document complies
  • the notary overlays the signature of the counterparties already formed by the signature of the notary.
  • a conference call of a court session is carried out, where at least one of the parties is present at the notary and the notary verifies the status of the party and confirms or denies the identity of the person as a representative of one of the parties to this judicial process.
  • At least one of the verifiers is an interrogating investigator or a police officer who interrogates a witness or an accused remotely in the presence of another verifier.
  • data on the product is placed in the cloud storage as information on the verified document, and each subsequent point of sale or processing of this product is verified by generating an additional hash in relation to who the product was transferred to along the chain of supply from the initial manufacturer to the final point of retail sale of the product.
  • the claimed method is practically implemented as follows.
  • the cloud network forms a special application for all network users, each of whom downloads this application to his mobile device or computer and installs there.
  • a private key is generated - a sequence of characters, generated randomly when creating a unique user account (ID).
  • a private key is generated public key.
  • the peculiarity of forming a private key is that if a message from a unique user is signed with a private key, then when this message is decoded, you can get a public key.
  • information is stored in the cloud environment so that it cannot be deleted and edited, in contrast to the well-known cloud resources, where storage is on cloud servers and when someone wants to add data to the cloud, he is forced to double-check the data added earlier and at the same time forced to trust the cloud.
  • Miners are random people, they check the signature of the document, check the correspondence of the sent data, pull out the message itself and the public keys and
  • Each next random miner who next gets access to the key checks the entry left by the previous miner.
  • Miner any member of the network, carrying out work on checking documents in the network, for which he receives a reward from the system for each correct
  • the application begins to spread among all miners in a random way, where the system seeks to transfer the application to the largest number of currently available online miners.
  • Miners begin to pick a hash and the first of them, for whom the system identifies the fact of picking a hash, the hash function forms a unique sequence of characters with a unique signature.
  • Each subsequent miner checks the already formed hash of the previous one.
  • the more miners try to create a hash the more difficult it is to find a hash and the longer it takes.
  • the fewer miners the easier it is to generate a hash.
  • the system optimizes the number of people willing to carry out the miner's work for a certain amount of remuneration.
  • the verifying miner sends illiquid data to the trash one step below, if the miner made a mistake and sent the correct data one step below, others miners will also see the error of this miner and return the data to the correct place.
  • a verifier a person who has a license and can verify miners and other network participants who want to verify their identity through a verifier.
  • notarization of documents there are two or more parties who need to certify the contract with a notary, send it to the cloud, check the hash, and then can send it to the notary, who certifies the fact that the parties signed a certain document. If it is necessary to form a document, in respect of which its compliance with the legislation has been verified, the notary is given access to the document on an equal basis with other parties, the notary reads it, and if the document complies with the legislation, the notary overlays his signature on top of the already formed signature.
  • the claimed method also allows you to conduct court sessions without the need for one of the parties to the trial to be present in the courtroom of your region.
  • a suspect including at the international level, which is realized by the participation as verifiers of either a notary or police officers in the building of the police department with video recording. Then the identity of the suspect or witness is verified by a notary or the police, and the investigator in another region interrogates, also in the presence of his own verifier of the same status.
  • the claimed method also allows verification of goods. Let's say the product is sent to a processing point, and before that it receives a hash and the data about the product goes into the blockchain. Each subsequent point of sale or processing of this product is verified in the system and generates an additional hash in relation to the person to whom the product was transferred. This is how information is added and the entire chain from the initial manufacturer to the final point of sale is visible, which makes the sales market transparent for consumer control and taxation.
  • a cloud service can be a software package built on the basis of the Ethereum Blockchain implementation in the Go language with the classic Proof of Work (PoW) or Proof of Authority (PoA) approach, but supplemented with new functionality.
  • PoW Proof of Work
  • PoA Proof of Authority
  • the declared cloud service will support Ethereum Blockchain smart contracts and ERC-20 tokens and will be backward compatible with the Ethereum Blockchain (API elements and Ethereum Blockchain protocols will be available).
  • the main problems that the new functionality is designed to solve are: instant confirmation of transactions, guaranteeing transactions, verification of accounts and data in the cloud network, ratings of network participants.
  • the main software elements of such a cloud service can be:
  • Fgeth node - implementation of the blockchain itself in the Go language including, among other things, mining software, a wallet for working through the command line.
  • FoodScan web service which will provide both additional visual information about the operation of the cloud service, as well as API methods for obtaining this information.
  • the software developed to work with the cloud service will be open source.
  • Miners are nodes in the network that conduct transactions, form and verify blocks in the cloud network chain based on PoW (Proof of Work) or PoA (Proof of Authority) consensus.
  • Verifiers are cloud service accounts entered into the registry, which can enter information into the cloud service, the accuracy of which they are ready to legally guarantee.
  • Optional members of the cloud network Guarantors - nodes in the network that act as providers of user transactions and provide additional
  • Each account (user) has the ability to send structured messages in transactions to other accounts.
  • Typical examples of such structuring are textual descriptions or account numbers.
  • a mechanism for attaching private information to transactions can also be implemented, when the information itself is not stored in the cloud itself, but on some private resource, which can only be accessed by the sender and recipient in our wallet using the data in the transaction.
  • a smart contract can be used to work with the storage.
  • the ability to work with this smart contract must be built into the cloud service application in such a way that it looks like a simple client API to the user.
  • the smart contract code will be publicly available.
  • the repository will store the following information: list of Guarantors, list of
  • Verifiers data on verified users, additional data on user accounts and the system.
  • Any user of the system can enter information about any other user of the system or himself into the register.
  • an API can be built into the cloud service client.
  • the smart contract will be managed by a cloud service account, which will be able to add smart contract administrators who will have additional options for managing smart contract data and help manage the ecosystem: add verifiers, suspend verifier licenses, block unscrupulous Guarantors, but They cannot change the entered data by any (verified, unverified, verifiers, Guarantors, etc.) users of the system.
  • a verifier is an already verified account, approved and entered in the warehouse registry, which can leave information in the FOODCOIN REGISTRY system in the warehouse registry, the authenticity of which he is legally ready to guarantee.
  • the list of verifiers is stored in the repository registry.
  • a verifier can be added to the registry or its license can be suspended either by the contract administrator appointed by the cloud service administrator (as a legal entity).
  • the verifier is legally responsible for the information left in the cloud service and must have a valid state license on the right
  • the Verifier can use a web service or install special software that can work with an independently installed cloud service node on its network, on a computer or use the guarantor-provider's nodes on the Internet, and can also integrate this functionality into its system, using the node API.
  • the verifier can enter any information into the storage register
  • a guarantor is an account and a cloud service node that acts as a provider of user transactions sent from official wallets and can, including for a fee, act as a guarantor of the transaction and instantly guarantee that the transaction will be successful. If in the course of the transaction there are problems - the Guarantor conducts it independently at the expense of his fund.
  • the GUARANTEE list is kept in the warehouse registry.
  • Any verified user can declare himself a guarantor or add another verified user as a guarantor to the registry through the cloud service API.
  • the wallet will be formed using the smart contract of the storage registry.
  • the wallet can be replenished by the user himself, who is a potential Guarantor and other network users.
  • a potential Guarantor becomes a full-fledged Guarantor if and only when the wallet is completely filled for the minimum amount and a node is deployed in the network with a public ⁇ r-address. Until the wallet is full, the Guarantor node will only act as a transaction provider.
  • the guarantor may have restrictions, for example, guarantee transactions only for the wallet amount - 10%.
  • a virtual stable currency can be created, pegged to the rate of some actual world currency. This currency will be the ERC token in the cloud service network.
  • the sender using the software of an electronic wallet, selects the service of sending a guaranteed transaction with instant confirmation.
  • the software of the electronic wallet is connected to the node of the Guarantor-provider,
  • the e-wallet software initiates the transaction and signs it
  • the node of the Guarantor-provider checks the availability of the required amount for the transaction and payment of commissions to the miners and the Guarantor, and also checks the presence of pending user transactions in the network and whether the user account is verified. Based on the data received, the Provider-Guarantor node decides to carry out a guaranteed instant transaction.
  • the sender's transaction is sent to the network, where it will be further added by miners to the cloud service.
  • the deferred function of the smart contract is being executed to verify that the transaction is added by miners to the cloud service
  • the software of the wallet of the recipient of funds verifies the signature of the instant message by calling the function of the storage smart contract through a public randomly selected node of the Guarantor-Provider in the network.
  • the function is called instantly, since this function is not processed by miners. If all is well, then the recipient in his wallet sees information about the guaranteed receipt of funds.
  • Miners process the transaction sent to the network by the Im-Provider. If miners do not add a transaction to the blockchain, the smart contract will launch a new transaction, which, at the expense of the Guarantor fund, will transfer funds to the recipient and reduce the Guarantor fund, for example, by 25%.
  • counterparties need to certify a certain document of intent, purchase and sale or other signatures of all parties, they need a mechanism to ensure that this particular document was certified by these people, as well as the ability to obtain evidence of this fact at any time.
  • EDS Europay, MasterCard, and Visa.
  • a signature is a unique sequence of characters that is unique for each specific document and each specific owner of the private key.
  • EDS is precisely the technology for obtaining a unique signature.
  • the system is built on the basis of the declared cloud service and the "PoW / PoA" consensus algorithm and regulates the methods of verifying the owners of private keys, and the methods of storing the signature facts.
  • PoW / PoA miners collectively validate the entire cloud service and transactions are not considered fully “confirmed” until added several new blocks. If an attacker tries to change information in an illegal way, then his transactions will be ignored by the rest of the network.
  • a register is formed, where the fact of the signature, just like the data indicating who the owner of the private key is, is simultaneously stored in many places, thereby reducing the chance of data loss or compromise.
  • a smart contract can be created to solve the current task in the cloud service.
  • a smart contract is a computer algorithm designed to conclude and maintain self-executing contracts executed in the cloud.
  • Such contracts are written as code that exists in the cloud service's distributed ledger that is maintained, managed, and executed by a network of computers.
  • the cloud service system Since the cloud service system is built on blockchain technology, it is impossible to delete or fake the changes made. Miners who contribute information to the blockchain are always randomly selected. The guarantee that the accounts that signed the document are certain individuals or legal entities is confirmed by the information entered by the Verifier (has a valid state license on the right to provide KYC (Know Your Customer) service, information about the time of action, which is stored in the storage registry) of the cloud service. For unverified accounts, the electronic signature functionality is not available in the storage smart contract. A mechanism for obtaining a hash of an electronic document is built into the software, and any change in the document will lead to the fact that the received hash will be completely different.
  • KYC Know Your Customer
  • the software for working with the verification system may have:
  • Fgeth node - implementation of the blockchain itself in the Go language including, among other things, mining software, a wallet for working through the command line.
  • counterparties using the visual interface of the application, choose to create an electronic signature for this document in the cloud service system.
  • the application having connected to the node, forms and sends a transaction to call the function of signing a hash document in a smart contract (described above) with parameters agree / disagree.
  • each of the parties must have sufficient funds to pay for the performance of this function or sufficient rights for such actions, if the verification process is free.
  • cloud service and can be requested and received anytime, anywhere using the cloud service application.
  • a document is considered signed by all parties if and only if all counterparties have performed the function of signing a document with the same document hash.
  • Verifiers can act as a third party in the transaction and verify it remotely, as well as in the future participate in dispute resolution if
  • One or each of the parties can, using the visual interface of the cloud service application, order a remote "notarization" by choosing
  • the application having connected to the node, forms and sends a transaction for
  • the smart contract can automatically check the fact of payment for the service and the availability
  • the notary verifier certifies this fact.
  • the notary can add information to the smart contract, which confirms the fact that a particular counterparty signed the smart contract (i.e., it was not hacked and did it voluntarily).
  • the content of the signed document can only be owned by the counterparties themselves, without disclosing the content to the "notary verifier".
  • Another example of document verification through the operation of a cloud service and remote notarization may differ from the previous one in that the following items are added to the algorithm of the previous section:
  • the notary verifier using the visual interface, uploads a copy document (archive) to the cloud service application to get the hash of the document (archive). Further, the "Verifier-Notary”, similarly to items "5" - "7", verifies the hash of the document using the visual interface of its application.
  • the content of the signed document is disclosed to the "verifier-notary" and the notary can check the document for compliance with legal requirements.
  • An example of identity verification for video conferencing in courts or during interrogations using a cloud service and remote notarization may differ from the previous one in that the following items are added to the algorithm of the previous section:
  • the notary verifier is present in the same place with the person being verified, and using the visual interface, uploads a copy of the document of the person being verified (archive) into the cloud service application to obtain the hash of the document (archive). Further, the "Verifier-Notary”, similar to paragraphs 5-7 on verification, verifies the hash of the document using the visual interface of its application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

Изобретение относится к облачным сервисам и может найти применение для удаленной верификации документов, документов личностей, товарной документации товаров и осуществления верифицированной конференцсвязи. Техническим результатом изобретения является возможность абсолютно точной удаленной верификации документа без потребности его постоянной проверки на предмет внесения правок одной из сторон, и без возможности прочтения или редактирования документа облачным сервисом или третьими лицами без передачи такой возможности сторонами. Каждый из контрагентов и иных пользователей облачной сети, используя интерфейс облачного сайта и специальное приложение, работающее с ним, создают аккаунт в виде уникального идентификатора (ID), под который формируется приватный и публичный ключи, причем помимо ключей в облачной среде хранят информацию в виде файлов по документам, где файлы имеют атрибуты на запрет удаления и редактирования; каждый из контрагентов, подписав документ, используя приложение, загружает через него в облачное хранилище копию документа, где данная копия документа в виде закрытого файла подвергается обработке для формирования хеша, при этом хеш формируется случайным образом с помощью других пользователей сети - майнеров, также использующих приложение и которые не являются для данной процедуры верификации контрагентами, причем каждый из контрагентов, майнеров и других пользователей облачной сети проходит процедуру верификации личности у верификатора перед получением доступа к документам сети, а верификатором назначают лиц, обладающих лицензией на верифицирование; в том случае, когда все контрагенты выполнили функцию подписи документа с одним и тем же хешем документа, документ, считается подписанным всеми сторонами - верифицированным, о чем через приложение уведомляется каждая из сторон, а хеш документа формируют доступным для загрузки через сервер сайта для всех контрагентов в любое время.

Description

СПОСОБ УДАЛЕННОЙ ВЕРИФИКАЦИИ ДОКУМЕНТОВ
ОПИСАНИЕ
Изобретение относится к облачным сервисам и может найти применение для
удаленной верификации документов, документов личностей, товарной документации товаров и осуществления верифицированной конференцсвязи.
Известны облачные ресурсы публичного хранения и редактирования документов, которые являются своего рода верификаторами, например,
https://helpcenter.onlyoffice.com/ru/ (запущена в сети 07.07.2009., выбрано за прототип). Данный ресурс работает следующим образом.
Составляете ли вы договор, пишете ли статью, переводите ли текст - может
потребоваться взаимодействие с другими людьми, особенно на заключительном этапе, чтобы уточнить детали или проверить документ на наличие ошибок. В этом случае последовательность действий примерно одинакова: отправка документа - ожидание результата - исправление и редактирование - отправка документа - ожидание
результата - исправление и редактирование и так далее, пока результат не устроит обе стороны.
Чтобы избежать этой длительной процедуры и получить наилучший результат, не тратя времени на отправку и ожидание, можно воспользоваться функцией Совместного редактирования, доступной в онлайн-редакторе документов. Все, что нужно для этого, - отправить ссылку на документ нужному человеку и начать совместное редактирование документа, комментируя и обсуждая его в режиме реального времени, без установки каких-то дополнительных программ.
Технической проблемой прототипа является то, что хранение информации идет только на облачном сервере, и когда кто-то хочет добавить данные в облако, он вынужден перепроверить данные, добавленные ранее.
Кроме того, смысл верификации отредактированных документов состоит в том, что облачный сервис сам отслеживает редактирование документов, а иные пользователи ему доверяют. Но при желании, администраторы ресурса облачного сервиса могут вмешиваться в процесс редактирования документов пользователей и читать их конфиденциальную информацию, вносить в нее правки. Поэтому, нет никакой гарантии, что документ, созданный пользователями будет ими верифицирован абсолютно точно и только ими без вмешательства третьей стороны в лице облачного сервиса.
Задачей изобретения является устранение указанных недостатков.
Техническим результатом изобретения является возможность абсолютно точной удаленной верификации документа без потребности его постоянной проверки на предмет внесения правок одной из сторон, и без возможности прочтения или
редактирования документа облачным сервисом или третьими лицами без передачи такой возможности сторонами.
Также, техническим результатом является возможность удаленного нотариального верифицирования документов, причем как с присутствием сторон при нотариусе, так и без данного присутствия.
Также, техническим результатом является возможность осуществления удаленной конференцсвязи в судах без потребности одной из сторон судебного процесса присутствовать именно в зале суда своего региона.
Также, техническим результатом является возможность осуществления удаленного допроса свидетеля или подозреваемого, в том числе на международном уровне.
Также, техническим результатом является возможность осуществления верификации документов по товару, когда становится общедоступной вся цепочка от начального производителя до конечной точки сбыта товара, что делает рынок реализации продукции прозрачным для контроля потребителя и налогообложения.
Указанные технические результаты достигаются за счет того, что заявлен способ удаленной верификации документов, характеризующийся тем, что контрагенты создают предлагаемый для заверения сторонами документ, контрагенты обмениваются друг с другом одинаковой копией документа в электронном виде, подписывают электронной подписью свою копию документа, помещают подписанную копию в облачное хранилище используя приложение, посредством которого контрагенты могут загружать указанные документы в сеть, читать документы, менять статус доступа к документам, отличающийся тем, что каждый из контрагентов и иных пользователей облачной сети, используя интерфейс облачного сайта и специальное приложение, работающее с ним, создают аккаунт в виде уникального идентификатора (ID), под который формируется приватный ключ в виде последовательности символов, подбираемых случайным образом; электронной подписью каждого из контрагентов является публичный ключ, который формируют из приватного ключа таким образом, что если приватным ключом подписывается сообщение с документом от контрагента, то когда раскодируется сообщение, можно получить публичный ключ, причем помимо ключей в облачной среде хранят информацию в виде файлов по документам, где файлы имеют атрибуты на запрет удаления и редактирования; каждый из контрагентов, подписав документ, используя приложение, загружает через него в облачное
хранилище копию документа, где данная копия документа в виде закрытого файла подвергается обработке для формирования хеша, при этом хеш формируется
случайным образом с помощью других пользователей сети - майнеров, также
использующих приложение и которые не являются для данной процедуры
верификации контрагентами, причем каждый из контрагентов, майнеров и других пользователей облачной сети проходит процедуру верификации личности у
верификатора перед получением доступа к документам сети, а верификатором назначают лиц, обладающих лицензией на верифицирование; первый из майнеров, приложение которого сформировало хеш для верифицируемого документа, помещает его в облачное хранилище, а другие майнеры с помощью своих приложений проверяют действительность верификации действий предыдущего майнера и в случае ошибки одного из майнеров, связанной с наличием неликвидных данных, приложения других майнеров исправляют ошибку автоматически; в том случае, когда все контрагенты выполнили функцию подписи документа с одним и тем же хешем документа, документ, считается подписанным всеми сторонами - верифицированным, о чем через
приложение уведомляется каждая из сторон, а хеш документа формируют доступным для загрузки через сервер сайта для всех контрагентов в любое время.
Допустимо, что по крайней мере один из верификаторов является нотариусом, и в процессе нотариального верифицирования документов нотариус способен идентифицировать в облачной сети статус других нотариусов или иных верификаторов, при этом, контрагенты, получают от нотариуса статус верифицированного документа без его просмотра как факт того, что верифицированные стороны подписали некий документ.
Допустимо, что контрагенты дополнительно дают доступ к копии документа нотариусу или нескольким нотариусам, где каждый из нотариусов проверяет документ на его соответствие требованиям законодательства, и если документ соответствует
законодательству, нотариус поверх уже сформированной подписи контрагентов накладывает свою подпись нотариуса.
Допустимо, что с помощью нотариуса осуществляют ведение конференцсвязи судебного заседания, где по крайней мере одна из сторон присутствует у нотариуса и нотариус верифицирует статус стороны и подтверждает или отрицает принадлежность личности как представителя одной из сторон данного судебного процесса.
Допустимо, что по крайней мере один из верификаторов является следователем- дознавателем или сотрудником полиции, который ведет удаленно допрос свидетеля или обвиняемого, находящегося в присутствии другого верификатора.
Допустимо, что в качестве сведений по верифицируемому документу в облачное хранилище помещают данные по товару и каждая последующая точка сбыта или переработки данного товара верифицируется формированием дополнительного хеша в отношении того, кому передан товар по цепочке сбыта от начального производителя до конечной точки реализации товара в розницу.
Осуществление изобретения
Заявленный способ практически реализуется следующим образом.
Облачная сеть формирует специальное приложение для всех пользователей сети, каждый из которых закачивает данное приложение на свое мобильное устройство или компьютер и устанавливает там.
При этом, формируется приватный ключ - последовательность символов, формируется случайным образом при создании уникального аккаунта (ID) пользователя.
Также, при выгрузке данных в облачный сервис, из приватного ключа формируется публичный ключ. Особенность формирования приватного ключа состоит в том, что если приватным ключом подписается некое сообщение от уникального пользователя, то когда раскодируется это сообщение, можно получить публичный ключ.
Помимо ключей информация хранится в облачной среде так, что ее нельзя удалить и редактировать, в отличии от известных облачных ресурсов, где хранение идет на облачных серверах и когда кто-то хочет добавить данные в облако, он вынужден перепроверить данные, добавленные ранее и при этом вынужден доверять облаку.
В заявленном решении отслеживание публичного редактирования осуществляется с помощью майнеров, которые осуществляют функции верификации и нотаризации. Майнеры - случайные люди, проверяют подпись документа, проверяет соответствие отправляемых данных, выдергивает само сообщение и публичный ключи и
подтверждает, что данному сообщению соответствует данный публичный ключ.
Каждый следующий случайный майнер, получивший следующим доступ к ключу, проверяет запись, оставленную предыдущим майнером.
Майнер - любой участник сети, осуществляющий работу по проверке документов в сети, за что получает от системы вознаграждение за каждое правильное
подтверждение проверенным им данных.
Если в сеть поступает информация о том, что кто-то хочет отправить информацию в облачный сервис, заявка начинает распространяться между всеми майнерами случайным образом, где система стремится передать заявку наибольшему числу доступных в настоящий момент онлайн майнеров.
Майнеры начинают подбирать хеш и первый из них, для кого система идентифицирует факт подбора хэша, хеш функция формирует уникальную последовательность символов с уникальной подписью.
Каждый последующий майнер проверяет уже сформированный хеш предыдущего.
Чем больше майнеров пытается создать хеш, тем сложнее подобрать хэш и дольше по времени. Чем меньше майнеров, тем проще создать хэш.
Тем самым, система оптимизирует количество желающих осуществлять работу майнера за определенный размер вознаграждения.
Если есть ошибка, неликвидные данные проверяющий майнер отправляет в корзину на шаг ниже, если майнер ошибся и отправил правильные данные на шаг ниже, другие майнеры тоже увидят ошибку уже этого майнера и вернут данные на правильное место. В облачном сервисе существует также верификатор - лицо, обладающее лицензией и может верифицировать майнеров и иных участников сети, желающих верифицировать свою личность через верификатора.
Все участники сети и майнеры проходят процедуру верификации.
Для нотариального заверения документов есть две и более стороны, которым надо заверить договор у нотариуса, отправляют в облако, проверяют хеш, затем могут переслать нотариусу, который удостоверяет факт того, что стороны подписали некий документ. При необходимости формирования документа, в отношении которого проверено его соответствие законодательству, нотариусу предоставляют доступ к документу наравне с другими сторонами, нотариус его читает, и если документ соответствует законодательству, нотариус поверх уже сформированной подписи накладывает свою подпись нотариуса.
Для собрания нескольких людей для совершения удаленной сделки с целью
визирования документа у нотариуса каждый из людей приходит к верификатору в своем регионе, затем каждый из документов каждого из людей, участвующих в сделке, каждый из нотариусов заводит свою копию документа в облако, для него формируется хеш, и заверить документ может даже нотариус, возле которого не находится ни одна из сторон сделки.
Заявленный способ также позволяет вести судебные заседания без потребности одной из сторон судебного процесса присутствовать именно в зале суда своего региона.
Если где-то идет суд по конференцсвязи, специальный оператор подключается вместо другого суда к нотариусу, возле которого сидит участник процесса, при этом нотариус подтверждает личность участника процесса. Это возможно потому, что суд может идентифицировать личность верификатора-нотариуса.
Также обеспечивается возможность удаленного допроса свидетеля или
подозреваемого, в том числе на международном уровне, что реализуется участием в качестве верификаторов либо нотариуса, либо сотрудников полиции в здании полицейского управления с ведением видеозаписи. Тогда личность подозреваемого или свидетеля верифицирует нотариус или полиция, а допрашивает следователь в другом регионе, также в присутствии своего верификатора того же статуса. Заявленный способ также позволяет проводить верификацию товара. Допустим товар отправляется в точку переработки, а перед этим получает хеш и данные о товаре попадают в блокчейн. Каждая последующая точка сбыта или переработки данного товара верифицирована в системе и формирует дополнительный хеш в отношении того, кому передан товар. Так происходит добавление информации и видна вся цепочка от начального производителя до конечной точки сбыта, что делает рынок реализации продукции прозрачным для контроля потребителя и налогообложения.
Технически заявленный способ, как один из возможных вариантов реализации, может быть воплощен, например, следующим образом.
Облачный сервис может представлять собой программный комплекс построенный на базе Ethereum Blockchain реализации на языке Go с классическим подходом Proof of Work (PoW) или Proof of Authority (PoA), но дополненный новым функционалом. Тем самым заявленный облачный сервис будет поддерживать смарт-контракты Ethereum Blockchain и токены стандарта ERC-20 и будет обратно совместим с Ethereum Blockchain (элементы API и протоколы Ethereum Blockchain будут доступны).
Основные проблемы которые призван решать новый функционал это: моментальное подтверждение транзакций, гарантирование проведения транзакций, верификация аккаунтов и данных в облачной сети, рейтинги участников сети.
Основными программными элементами такого облачного сервиса могут быть:
1. Fgeth нода - имплементация самого блокчейна на языке Go, включающая в себя в том числе ПО для майнинга, кошелек для работы через командную строку.
2. Электронный кошелек с визуальным интерфейсом для работы с нодой и
Гарантами-провайдерами в сети.
3. ПО для работы верификаторов
4. ПО для работы Гарантов
5. Смарт-контракт для работы с хранилищем облачного сервиса
6. веб-сервис FoodScan, который будет предоставлять как дополнительную визуальную информацию о функционировании облачного сервиса, в так же методы API для получения данной информации.
7. Смарт-контракты облачного сервиса для работы с токенами реальных валют. Технологии и языки программирования: Go, C/C++, Java, РНР, JavaScript, HTML, CSS, Solidity.
ПО разработанное для работы с облачным сервисом будет иметь открытый исходный код.
Обязательные участники облачной сети:
1) Майнеры - ноды в сети, которые проводят транзакции формируют и верифицируют блоки в цепочке облачной сети на основе консенсуса PoW (Proof of Work) или PoA(Proof of Authority).
2) Аккаунты (обычные пользователи), которые взаимодействуют друг с другом посредством программного обеспечения.
3) Верификаторы - аккаунты облачного сервиса, занесенные им в реестр, которые могут заносить в облачный сервис информацию, достоверность которой они готовы гарантировать юридически.
Необязательные участники облачной сети: Гаранты - ноды в сети, которые выступают провайдерами транзакций пользователей и предоставляют дополнительный
функционал мгновенного гарантирования выполнения сделки. Гаранты используются только для верификации финансовых операций.
Сообщения в транзакциях.
Каждый аккаунт (пользователь) имеет возможность отправлять структурированные сообщения в транзакциях другим аккаунтам.
Стандартными примерами такого структурирования может являться текстовое описание или номера счетов.
Также может быть реализован механизм прикрепления к транзакциям приватной информации, когда сама информация хранится не в самом облаке, а на каком-то приватном ресурсе, получить доступ к которой может только отправитель и получатель в нашем кошельке, используя данные в транзакции.
Хранилище в собственном облачном сервисе.
Для работы с хранилищем может использоваться смарт контракт. Возможность работы с данным смарт-контрактом должна быть встроена в приложение облачного сервиса таким образом, что для пользователя это будет выглядеть как простая работа с API клиента. Код смарт-контракта будет доступен в публичном доступе.
Хранилище будет хранить следующую информацию: список Гарантов, список
Верификаторов, данные о верифицированных пользователях, дополнительные данные о аккаунтах пользователей и системе.
Любой пользователь системы может занести в реестр информацию о любом другом пользователе системы, либо о себе. Для этого в клиент облачного сервиса может быть встроено API.
Управление смарт-контрактом будет осуществляться аккаунтом облачного сервиса, который будет иметь возможность добавлять администраторов смарт-контракта, которые будут иметь дополнительные возможности управления данными смарт- контракта и будут помогать управлять экосистемой: добавлять верификаторов, приостанавливать действие лицензий верификаторов, блокировать недобросовестных Гарантов, но при этом изменять занесенные данные любыми (верифицированными, неверифицированными, верификаторами, Гарантами и т.д.) пользователями системы они не могут.
Верификаторы.
Верификатор - это уже верифицированный аккаунт, одобренный и занесенный в реестр хранилища, который может оставить в реестре хранилища информацию в системе FOODCOIN REGISTRY, достоверность которой он готов гарантировать юридически.
Список верификаторов хранится в реестре хранилища. Добавить верификатора в реестр или приостановить действие его лицензии может или администратор контракта, которого назначил администратор облачного сервиса (как легальное юридическое лицо).
Верификатор юридически отвечает за информацию оставленную в облачном сервисе и должен иметь действующую лицензию государственного образца о праве
предоставлять KYC сервис, информация о времени действии, которой хранится в реестре хранилища облачного сервиса. Работа через API с верификаторами будет встроена в клиент облачного сервиса.
Для работы Верификатор может использовать веб-сервис или установить специальное ПО, которое может работать с самостоятельно установленной нодой облачного сервиса у себя в сети, на компьютере или использовать ноды гаранта-провайдера в сети интернет, а так же сможет встроить эту функциональность в свою систему, используя API ноды.
Также верификатор может вносить в реестр хранилища любую информацию,
достоверность которой он готов гарантировать согласно лицензии, полученной в рамках законодательства юрисдикции, в которой он находится.
Во время процедуры верификации смарт-контрактом в хранилище создается два новых адреса для голосования: Positive - для позитивного голосования и Negative - для негативного голосования. Информация о данных адресах заносится в хранилище и привязана к верифицированному пользователю. Для голосования в API облачного сервиса могут быть добавлены соответствующие методы. Эти методы голосования будут доступны для выполнения только верифицированным пользователям и требовать перечисления определенных сумм на соответствующие адреса. Доступа к финансовым средствам на данных адресах не будет. Тем не менее голосующему будут доступны методы для отзыва своих голосов, уменьшая таким образом любой фонд, который он пополнил.
Гаранты.
Гарант - это аккаунт и нода облачного сервиса, которая выступает провайдером транзакций пользователей отправляемых с официальных кошельков и может, в том числе и за вознаграждение выступать гарантом сделки и мгновенно гарантировать, что транзакция пройдет успешно. В случае, если в процессе сделки возникли проблемы - Гарант проводит ее самостоятельно за счет средств своего фонда.
Список ГАРАНТОВ хранится в реестре хранилища.
Объявить себя гарантом или добавить другого верифицированного пользователя как гаранта в реестр может любой верифицированный пользователь через API облачного сервиса. При этом будет сформирован кошелек методом смарт-контракта реестра хранилища. Кошелек может быть пополнен как самим пользователем, который является потенциальным Гарантом, так и другими пользователями сети.
Потенциальный Гарант становится полноценным Гарантом, тогда и только тогда, когда будет полностью заполнен кошелек на минимальную сумму и будет развернута нода в сети с публичным ίr-адресом. Пока кошелек не заполнен - нода Гаранта будет выступать только провайдером транзакций. Гарант может иметь ограничения, например, гарантировать транзакции только на сумму кошелька - 10%.
Для проведения крупных транзакций может быть создана виртуальная стабильная валюта, привязанная к курсу какой-нибудь мировой валюты фактической. Данная валюта будет являться ERC токен в сети облачного сервиса.
Описание примера проведения мгновенных транзакций в среде облачного сервиса. Описывается алгоритм проведения моментальной транзакции между двумя
верифицированными пользователями сети в системе облачного сервиса.
Алгоритм:
1. Отправитель с помощью ПО электронного кошелька выбирает услугу отправки гарантированного проведения транзакции с моментальным подтверждением.
2. ПО электронного кошелька подключается к ноде Гаранта-провайдера,
осуществляющего данную услугу.
3. ПО электронного кошелька инициализирует транзакцию и подписывает ее
приватным ключом.
4. Нода Гаранта-провайдера проверяет наличие нужной суммы для проведения транзакции и оплаты комиссий майнерам и Гаранту, а также проверяет наличие в сети незавершенных транзакций пользователя и верифицирован ли аккаунт пользователя. На основе полученных данных нода Гаранта-провайдера принимает решение проведении гарантированной моментальной транзакции.
5. В случае положительного решения транзакция отправителя отправляется в сеть, где в дальнейшем будет добавлена майнерами в облачный сервис. Выполняется отложенная функция смарт контракта на проверку добавления транзакции майнерами в облачный сервис.
6. Нода Гаранта создает информационное сообщение, генерирует и подписывает его своей электронной подписью.
7. Информационное сообщение моментально доставляется на ПО кошелька
получателя средств.
8. ПО кошелька получателя средств проверяет подпись моментального сообщения вызывая функцию смарт-контракта хранилища через публичную рандомно выбранную ноду Гаранта-провайдера в сети. Вызов функции происходит моментально, так как данная функция не отрабатывается майнерами. Если все хорошо, то получатель в своем кошельке видит информацию о гарантированном получении средств.
9. Майнеры обрабатывают транзакцию, отправленную в сеть Г арантом- провайдером. В случае не добавления майнерами транзакции в блокчейн, смарт-контрактом будет запущена новая транзакция, которая за счет фонда Гаранта переведет средства получателю и уменьшит фонд Гаранта, например, на 25%.
Пример верификации в облачном сервисе.
В ситуациях, когда контрагентам нужно заверить некий документ о намерениях, купли- продажи или иной подписями всех сторон им нужен механизм, гарантирующий, что именно этот документ был заверен именно этими людьми, а также возможность в любой момент получить доказательство этого факта.
Данную задачу решает система, построенная в заявленном облачном сервисе.
Классическое использование ЭЦП и криптоключа - это создание уникальной подписи для конкретного уникального документа. Подпись - это уникальная последовательность символов, уникальная для каждого конкретного документа и каждого конкретного владельца приватного ключа. ЭЦП - это именно технология получения уникальной подписи.
В отличие от ЭЦП и криптоключа система построена на базе заявленного облачного сервиса и алгоритме консенсуса "PoW/PoA" и регламентирует способы верификации владельцев приватных ключей, и способы хранения фактов подписи. В PoW/PoA майнеры коллективно подтверждают действительность всего облачного сервиса, и транзакции не считаются полностью «подтвержденными», пока к ним не добавятся несколько новых блоков. Если злоумышленник попытается изменить информацию незаконным способом, то его транзакции будут проигнорированы остальной частью сети. Таким образом, помимо создания подписи формируется реестр, где факт подписи, точно также как данные, указывающие на то, кто есть владелец приватного ключа одновременно хранятся в множестве мест, тем самым уменьшая шанс утери или компрометации данных.
Для решения текущей задачи в облачном сервисе может быть создан смарт-контракт. Смарт-контракт (англ. Smart contract— "умный контракт")— компьютерный алгоритм, предназначенный для заключения и поддержания само исполняемых контрактов, выполняемых в облачной среде.
Такие контракты записываются в виде кода, существующего в распределенном реестре облачного сервиса, который поддерживается, управляется и выполняется сетью компьютеров.
Функциями смарт-контракта будут:
1) Функция подписи документа, которая принимает на вход хеш электронного документа (архива документов) и заносит в систему облачного сервиса запись о том, что аккаунт, вызвавший данную функцию ставит подпись согласен/не согласен с информацией находящейся в документе (архиве документов), также сохраняется дата внесения записи.
2) Функция получения хешей-документов из облачного сервиса, которые подписал аккаунт.
3) Функция получения информации об аккаунтах, которые поставили подпись под данным хешем-документа.
4) Функция заказа удаленного нотариального заверения хеша-документа, под которым уже поставили подпись стороны облачного сервиса.
Пользоваться функциями смарт-контракта могут только верифицированные аккаунты облачного сервиса.
Так как система облачного сервиса построена на блокчейн-технологии, то удалить или подделать внесенные изменения невозможно. Майнеры, вносящие информацию в блокчейн, выбираются всегда случайным образом. Гарантия того, что аккаунты, подписавшие документ являются теми или иными физическими или юридическими лицами подтверждается информацией, внесенной Верификатором (имеет действующую лицензию государственного образца о праве предоставлять KYC (Know Your Customer) сервис, информация о времени действии, которой хранится в реестре хранилища) облачного сервиса. Не верифицированным аккаунтам функционал электронной подписи недоступен в смарт-контракте хранилища. В ПО встраивается механизм получения хеша электронного документа и любое изменение в документе приведет к тому, что полученный хеш будет совершенно другой.
ПО для работы с системой верификации может иметь:
1. Fgeth нода - имплементация самого блокчейна на языке Go, включающая в себя в том числе ПО для майнинга, кошелек для работы через командную строку.
2. Электронный кошелек с визуальным интерфейсом для работы с нодой и
провайдерами в сети.
3. Смарт-контракт для работы с хранилищем в облачном сервисе.
Верификация документов посредством работы только облачного сервиса.
Алгоритм подписания документа:
1. Контрагенты создают документ (архив документов) любым возможным им
способом (документ может быть создан в электронном виде или же просто отсканирован), который они собираются заверить.
2. Контрагенты обмениваются друг с другом одинаковой копией документа
(архива) в электронном виде любым возможным им способом.
3. Контрагенты, используя визуальный интерфейс, загружают копию документа (архива) в специальное приложение, разработанное облачным сервисом, для получения хеша-документа (архива).
4. Далее контрагенты, используя визуальный интерфейс приложения, выбирают создание электронной подписи для данного документа в системе облачного сервиса.
5. Приложение, подключившись к ноде, формирует и отправляет транзакцию для вызова функции подписи хеша-документа в смарт-контракте (описан выше) с параметрами согласен/не согласен.
6. Для того, чтобы майнерами была внесена информация в систему облачного
сервиса, полученная в результате выполнения функции подписи хеша- документа, у каждой из сторон должно быть достаточно средств для оплаты выполнения данной функции или достаточно прав для таких действий, если процесс верификации бесплатный.
7. Информация о подписи документа (архива) успешна вносится в систему
облачного сервиса и может быть запрошена и получена в любое время и в любом месте с помощью приложения облачного сервиса.
Документ, считается подписанным всеми сторонами тогда и только тогда, когда все контрагенты выполнили функцию подписи документа с одним и тем же хешем документа.
В данном способе информацией о содержании подписанного документа владеют только сами контрагенты.
Пример верификации документов посредством работы облачного сервиса и
удаленного нотариального заверения.
В реестре системы облачного сервиса присутствуют Верификаторы с действующей лицензией на нотариальную деятельность в рамках законодательства той страны, где они ее получили. Реестр верификаторов и действие их лицензий контролируется системой облачного сервиса.
Данные Верификаторы могут выступить третьим лицом в сделке и удаленно ее верифицировать, а также в будущем участвовать в разрешении споров, если
понадобится. За свою деятельность они могут брать плату в системе облачного сервиса.
К предыдущему алгоритму добавляются шаги:
- Одна или каждая из сторон может, используя визуальный интерфейс приложения облачного сервиса, заказать удаленное "нотариальное заверение", выбрав
"верификатора-нотариуса" из списка.
- Приложение, подключившись к ноде, формирует и отправляет транзакцию для
вызова функции смарт-контракта, которая зарегистрирует заявку на удаленное заверение в системе облачного сервиса. За данную операцию может списаться плата с аккаунта, запросившего данную услугу. Информация о стоимости услуги также будет отражена в визуальном интерфейсе приложения.
- "Верификатор-нотариус" в визуальном интерфейсе своего приложения получит
заявку с информацией о хеше документа (архива) и адресах аккаунтов контрагентов. Получив информацию о запросе удаленной верификации - "Верификатор-нотариус", аналогично ранее описанным шагам, верифицирует хеш документа с помощью визуального интерфейса своего приложения.
- Смарт-контракт может автоматически проверить факт оплаты услуги и наличие
подписей в системе облачного сервиса других контрагентов для данного хеша документа и внести информацию в систему облачного сервиса от том, что
верификатор-нотариус заверяет этот факт.
В данной схеме возможен еще один вариант. Любой может обратится к "нотарису", указав на смарт-контракт и попросить бумажно заверить, что конкретные лица поставили свои подписи под одинаковым документом. "Нотариус" видит, что все контрагенты поставили подпись под одинаковым документом и дали согласие с ним. Таким образом, нотариусу даже не надо высылать никакие хеши документов, так как он заверяет произошедшие событие.
Нотариус может добавить информацию в смарт-контракт, что он подтверждает факт того, что конкретный контрагент ставил подпись в смарт-контракте (т.е. не был взломан и делал это добровольно).
В данном способе содержанием подписанного документа могут владеть только сами контрагенты, не раскрывая содержимое "верификатору-нотариусу".
Другой пример верификации документов посредством работы облачного сервиса и удаленного нотариального заверения может отличаться от предыдущего тем, что к алгоритму предыдущего раздела добавляются пункты:
1. Контрагенты высылают электронную копию документа удаленному
верификатору-нотариусу.
2. Верификатор-нотариус, используя визуальный интерфейс, загружает копию документа (архива) в приложение облачного сервиса, для получения хеша документа (архива). Далее "Верификатор-нотариус", аналогично пунктам "5"-"7", верифицирует хеш документа с помощью визуального интерфейса своего приложения.
В данном способе содержание подписанного документа раскрывается "верификатору- нотариусу" и нотариус может проверить документ на соответствие требованиям законодательства.
Пример верификации личностей для видеоконференцсвязи в судах или при допросах посредством работы облачного сервиса и удаленного нотариального заверения может отличаться от предыдущего тем, что к алгоритму предыдущего раздела добавляются пункты:
- Верификатор-нотариус, присутствует в одном и том же месте с верифицируемой личностью, и используя визуальный интерфейс, загружает копию документа верифицируемой личности (архива) в приложение облачного сервиса, для получения хеша документа (архива). Далее "Верификатор-нотариус", аналогично пунктам 5-7 по верификации, верифицирует хеш документа с помощью визуального интерфейса своего приложения.
- Другая сторона видеоконференцсвязи, получив документ верифицируемой
личности (архив), так же загружает его в приложение облачного сервиса, для получения хеша документа (архива) и далее, аналогично пунктам 5-7 по
верификации, верифицирует хеш документа с помощью визуального интерфейса своего приложения.

Claims

ФОРМУЛА
1. Способ удаленной верификации документов, характеризующийся тем, что контрагенты создают предлагаемый для заверения сторонами документ, контрагенты обмениваются друг с другом одинаковой копией документа в электронном виде, подписывают электронной подписью свою копию документа, помещают подписанную копию в облачное хранилище используя приложение, посредством которого
контрагенты могут загружать указанные документы в сеть, читать документы, менять статус доступа к документам, отличающийся тем, что каждый из контрагентов и иных пользователей облачной сети, используя интерфейс облачного сайта и специальное приложение, работающее с ним, создают аккаунт в виде уникального идентификатора
(ID), под который формируется приватный ключ в виде последовательности символов, подбираемых случайным образом; электронной подписью каждого из контрагентов является публичный ключ, который формируют из приватного ключа таким образом, что если приватным ключом подписывается сообщение с документом от контрагента, то когда раскодируется сообщение, можно получить публичный ключ, причем помимо ключей в облачной среде хранят информацию в виде файлов по документам, где файлы имеют атрибуты на запрет удаления и редактирования; каждый из контрагентов, подписав документ, используя приложение, загружает через него в облачное
хранилище копию документа, где данная копия документа в виде закрытого файла подвергается обработке для формирования хеша, при этом хеш формируется
случайным образом с помощью других пользователей сети - майнеров, также использующих приложение и которые не являются для данной процедуры
верификации контрагентами, причем каждый из контрагентов, майнеров и других пользователей облачной сети проходит процедуру верификации личности у
верификатора перед получением доступа к документам сети, а верификатором назначают лиц, обладающих лицензией на верифицирование; первый из майнеров, приложение которого сформировало хеш для верифицируемого документа, помещает его в облачное хранилище, а другие майнеры с помощью своих приложений проверяют действительность верификации действий предыдущего майнера и в случае ошибки одного из майнеров, связанной с наличием неликвидных данных, приложения других айнеров исправляют ошибку автоматически; в том случае, когда все контрагенты выполнили функцию подписи документа с одним и тем же хешем документа, документ, считается подписанным всеми сторонами - верифицированным, о чем через
приложение уведомляется каждая из сторон, а хеш документа формируют доступным для загрузки через сервер сайта для всех контрагентов в любое время.
2. Способ по п.1, отличающийся тем, что по крайней мере один из верификаторов является нотариусом, и в процессе нотариального верифицирования документов нотариус способен идентифицировать в облачной сети статус других нотариусов или иных верификаторов, при этом, контрагенты, получают от нотариуса статус
верифицированного документа без его просмотра как факт того, что
верифицированные стороны подписали некий документ.
3. Способ по п.2, отличающийся тем, что контрагенты дополнительно дают доступ к копии документа нотариусу или нескольким нотариусам, где каждый из нотариусов проверяет документ на его соответствие требованиям законодательства, и если документ соответствует законодательству, нотариус поверх уже сформированной подписи контрагентов накладывает свою подпись нотариуса.
4. Способ по п.2, отличающийся тем, что с помощью нотариуса осуществляют ведение конференцсвязи судебного заседания, где по крайней мере одна из сторон присутствует у нотариуса и нотариус верифицирует статус стороны и подтверждает или отрицает принадлежность личности как представителя одной из сторон данного судебного процесса.
5. Способ по п.2, отличающийся тем, что по крайней мере один из верификаторов является следователем- дознавателем или сотрудником полиции, который ведет удаленно допрос свидетеля или обвиняемого, находящегося в присутствии другого верификатора.
6. Способ по п.1, отличающийся тем, что в качестве сведений по верифицируемому документу в облачное хранилище помещают данные по товару и каждая последующая точка сбыта или переработки данного товара верифицируется формированием дополнительного хеша в отношении того, кому передан товар по цепочке сбыта от начального производителя до конечной точки реализации товара в розницу.
PCT/RU2020/000097 2019-02-28 2020-02-26 Способ удаленной верификации документов WO2020226531A2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2019105735A RU2707700C1 (ru) 2019-02-28 2019-02-28 Способ удаленной верификации документов
RU2019105735 2019-02-28

Publications (2)

Publication Number Publication Date
WO2020226531A2 true WO2020226531A2 (ru) 2020-11-12
WO2020226531A3 WO2020226531A3 (ru) 2021-01-14

Family

ID=68836212

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2020/000097 WO2020226531A2 (ru) 2019-02-28 2020-02-26 Способ удаленной верификации документов

Country Status (2)

Country Link
RU (1) RU2707700C1 (ru)
WO (1) WO2020226531A2 (ru)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112116472A (zh) * 2020-09-18 2020-12-22 上海计算机软件技术开发中心 区块链跨链交易模型、方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10425230B1 (en) * 2019-03-01 2019-09-24 Capital One Services, Llc Identity and electronic signature verification in blockchain

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010061257A2 (en) * 2008-11-03 2010-06-03 Luiz Alberto Wanderley Systems and processes of protection and automatic verification of paper documents against falsification, adulteration and leakage
WO2012131474A1 (en) * 2011-03-29 2012-10-04 Jura Trade, Limited Method and apparatus for generating and authenticating security documents
RU2641225C2 (ru) * 2014-01-21 2018-01-16 Общество с ограниченной ответственностью "Аби Девелопмент" Способ выявления необходимости обучения эталона при верификации распознанного текста
RU2571396C2 (ru) * 2014-03-26 2015-12-20 Общество с ограниченной ответственностью "Аби Девелопмент" Способ и система для верификации в процессе чтения

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112116472A (zh) * 2020-09-18 2020-12-22 上海计算机软件技术开发中心 区块链跨链交易模型、方法

Also Published As

Publication number Publication date
WO2020226531A3 (ru) 2021-01-14
RU2707700C1 (ru) 2019-11-28

Similar Documents

Publication Publication Date Title
US11777726B2 (en) Methods and systems for recovering data using dynamic passwords
CN111164594B (zh) 用于将去中心化标识映射到真实实体的系统和方法
US11271754B2 (en) Data authorization based on decentralized identifiers
US11818265B2 (en) Methods and systems for creating and recovering accounts using dynamic passwords
US11900491B2 (en) Systems and methods for executing and delivering electronic documents
US20230059739A1 (en) System and method for authenticating user identity
US20220239495A1 (en) Method And System For Certification And Authentication Of Objects
US20090271321A1 (en) Method and system for verification of personal information
Jeong et al. Design of recruitment management platform using digital certificate on blockchain
US20220311611A1 (en) Reputation profile propagation on blockchain networks
US20220391887A1 (en) Systems and Methods for Maintenance of NFT Assets
Hsu et al. Design of an e-diploma system based on consortium blockchain and facial recognition
Dash et al. Artificial intelligence models for blockchain-based intelligent networks systems: Concepts, methodologies, tools, and applications
US20150206143A1 (en) Line item processing in a multi-layer transaction tracking system
WO2020226531A2 (ru) Способ удаленной верификации документов
CN110599347A (zh) 票据处理方法、装置、计算机可读存储介质和计算机设备
KR102493093B1 (ko) 블록체인 기반의 내용증명 이메일 서비스 제공 장치 및 방법
US20230419285A1 (en) NFT Enforcement Control System
US20230419302A1 (en) Api for incremental and periodic crypto asset transfer
US20230419309A1 (en) Blockchain-based security token for kyc verification
US20240202711A1 (en) Decentralized incentive system for validating transactions to blockchain miners
US20230281603A1 (en) Systems and methods for generating and distributing digital contract tokens
US20150206142A1 (en) Batch processing in a multi-layer transaction tracking system
Sengstschmid Community blockchain interaction patterns
Tumati et al. A Soulbound Token Certificate Verification System (SBTCert): Design and Implementation

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20801476

Country of ref document: EP

Kind code of ref document: A2