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

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

 

Изобретение относится к облачным сервисам и может найти применение для удаленной верификации документов, документов личностей, товарной документации товаров и осуществления верифицированной конференцсвязи.

Известны облачные ресурсы публичного хранения и редактирования документов, которые являются своего рода верификаторами, например, 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, PHP, 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 облачного сервиса. При этом будет сформирован кошелек методом смарт-контракта реестра хранилища. Кошелек может быть пополнен как самим пользователем, который является потенциальным Гарантом, так и другими пользователями сети. Потенциальный Гарант становится полноценным Гарантом, тогда и только тогда, когда будет полностью заполнен кошелек на минимальную сумму и будет развернута нода в сети с публичным ip-адресом. Пока кошелек не заполнен - нода Гаранта будет выступать только провайдером транзакций. Гарант может иметь ограничения, например, гарантировать транзакции только на сумму кошелька - 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 по верификации, верифицирует хеш документа с помощью визуального интерфейса своего приложения.

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

2. Способ по п. 1, отличающийся тем, что по крайней мере один из верификаторов является нотариусом, и в процессе нотариального верифицирования документов нотариус способен идентифицировать в облачной сети статус других нотариусов или иных верификаторов, при этом контрагенты получают от нотариуса статус верифицированного документа без его просмотра как факт того, что верифицированные стороны подписали некий документ.

3. Способ по п. 2, отличающийся тем, что контрагенты дополнительно дают доступ к копии документа нотариусу или нескольким нотариусам, где каждый из нотариусов проверяет документ на его соответствие требованиям законодательства и, если документ соответствует законодательству, нотариус поверх уже сформированной подписи контрагентов накладывает свою подпись нотариуса.

4. Способ по п. 2, отличающийся тем, что с помощью нотариуса осуществляют ведение конференцсвязи судебного заседания, где по крайней мере одна из сторон присутствует у нотариуса и нотариус верифицирует статус стороны и подтверждает или отрицает принадлежность личности как представителя одной из сторон данного судебного процесса.

5. Способ по п. 2, отличающийся тем, что по крайней мере один из верификаторов является следователем-дознавателем или сотрудником полиции, который ведет удаленно допрос свидетеля или обвиняемого, находящегося в присутствии другого верификатора.

6. Способ по п. 1, отличающийся тем, что в качестве сведений по верифицируемому документу в облачное хранилище помещают данные по товару и каждая последующая точка сбыта или переработки данного товара верифицируется формированием дополнительного хеша в отношении того, кому передан товар по цепочке сбыта от начального производителя до конечной точки реализации товара в розницу.