СИСТЕМЫ И СПОСОБЫ ПЕРСОНАЛЬНОЙ ИДЕНТИФИКАЦИИ И ВЕРИФИКАЦИИ Российский патент 2021 года по МПК G06Q20/40 H04L9/32 

ПЕРЕКРЕСТНАЯ ССЫЛКА НА СВЯЗАННЫЕ ЗАЯВКИ

(01) Настоящая заявка испрашивает приоритет Европейской патентной заявки ЕР15161502.8, поданной 27 марта 2015 и озаглавленной "A System And A Method For Personal Identification And Verification", которая включена в настоящий документ посредством ссылки.

ОБЛАСТЬ РАСКРЫТИЯ

(02) Настоящее изобретение относится к системе и способу персональной идентификации и верификации. В частности, настоящее изобретение относится к процессу персональной/клиентской идентификации и верификации, псевдонимной системе и транзакционной сети для мониторинга и ограничения транзакций с основанными на криптографии электронными деньгами - протоколу аутентификации учетных данных (учетной записи с параметрами доступа), связанных с подлинной личностью (легальным идентификатором).

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

(03) Предшествующий уровень техники определяет цифровую валюту или цифровые деньги. Основанная на Интернете среда обмена (т.е. отличающаяся от физической, например, банкнот и монет) демонстрирует свойства, подобные физическим валютам, однако позволяет совершать мгновенные транзакции и безграничную передачу собственности.

(04) Как виртуальные валюты, так и криптовалюты являются типами цифровых валют, но обратное неверно. Как и традиционные деньги, эти валюты могут использоваться для покупки физических товаров и услуг. Цифровые валюты, такие как биткойн, известны как "децентрализованные цифровые валюты", что означает, что нет центральной точки контроля над денежной массой (см. Википедию).

(05) Биткойн - это первые, основанные на криптографии, электронные деньги, которые были изобретены в 2008 году. Биткойн также упоминается как первая криптовалюта. Биткойн - это не только виртуальные деньги, но и платежная система, состоящая из децентрализованной одноранговой транзакционной сети для записи и верификации денежных транзакций.

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

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

(08) С момента появления биткойна были созданы различные основанные на криптографии электронные валюты, в совокупности называемые альтернативными криптовалютами. Среди них, некоторые являются модифицированными формами биткойнов, использующими различные криптографические алгоритмы хеширования (например, Litecoin) и/или имеющими дополнительные функции (например, CinniCoin), а некоторые из них создаются с использованием различных технологий подписи (например, CryptoNote).

(09) По замыслу, биткойн является псевдонимной криптовалютой, в то время как все альтернативные криптовалюты являются либо псевдонимными, либо анонимными. Что касается анонимной криптовалюты, ее можно легко применить к деятельности по отмыванию денег, поскольку все отправители и получатели в денежных транзакциях не могут прослеживаться. Что касается псевдонимной криптовалюты, академическое исследование (Meiklejohn S, et al. University of California, Сан-Диего, 2013) показало, что доказательства взаимодействий между учреждениями могут быть определены путем анализа схемы вовлечения биткойн-адресов в эмпирические покупки товаров и услуг.

(10) Этот подход может быть способен выявлять незаконную деятельность на уровне учреждения, но все же не может быть сужен до уровня одного человека. Недавнее академическое исследование (Koshy Р, et al. Pennsylvania State University, 2014) показало, что имеется возможность отобразить биткойн-адрес на IP-адрес. Однако этот подход применим только менее чем к 10% биткойн-адресов. Поэтому обычно считается, что биткойн и другие альтернативные криптовалюты могут использоваться для незаконной деятельности, такой как отмывание денег (Bryans D, Indiana Law Journal, 89 (1): 441, 2014).

(11) Псевдонимное/анонимное свойство также делает биткойн и альтернативные криптовалюты привлекательными мишенями для хакеров и воров. Например, в феврале 2014 года компания Mt. Gox, которая в то время была крупнейшей в мире компанией по обмену биткойнов, обратилась с заявлением о защите от банкротства, потому что компания подвергалась атакам хакеров, что привело к потере 850 000 биткойнов (около 480 миллионов долларов США).

(12) В январе 2015 года Словенская биткойн-биржа Bitstamp, которая была третьей по величине в мире биткойн-биржей в то время, был взломана, и было похищено около 19000 ВТС (стоимостью около 5 миллионов долларов США). Хотя хакеры/похитители должны переносить похищенные биткойны на свои биткойн-адреса, удостоверения личности (идентификаторы) большинства этих хакеров и похитителей остаются неизвестными.

(13) Поэтому необходимы решения для защиты от хищений биткойнов. Владение биткойнами защищается секретными ключами, которые хранятся в кошельке пользователей. Частные ключи могут быть созданы из парольной (идентификационной) фразы. Например, Brainwallet - это веб-сайт, который предоставляет инструмент для создания биткойн-адреса и его секретного ключа из sha256 парольной фразы. Используя словарь паролей, можно было бы проанализировать блокчейн биткойнов и отыскивать активные биткойн-адреса, созданные из типовых паролей, и похищать биткойны с этих адресов с использованием соответствующих секретных ключей.

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

(15) Еще один способ хищения биткойнов состоит в хищении основного файла данных кошелька (т.е. файла wallet.dat) в биткойн-кошельке, который инсталлирован на компьютере или сервере, соединенном с Интернетом. Роберт Липовски (Robert Lipovsky, 2013) сообщил о "троянце" онлайн-банкинга, который может похищать файлы wallet.dat. Частные ключи хранятся в файлах wallet.dat и защищены парольной фразой. После того, как основной файл данных кошелька похищен, парольная фраза защиты может быть взломана с помощью словарного угадывания, перестановок словарных слов или чисто грубой силы.

(16) Один пример решений для таких похищенных биткойн-кошельков представлен в публикации патентной заявки CN103927 656 (А), озаглавленной "Кошелек биткойн-терминала со встроенным фиксированным адресом сбора и способ биткойн-оплаты кошелька биткойн-терминала".

(17) Одним из простых решений, в отношении приведенного выше, является сохранение биткойнов на адресе с несколькими подписями (мультиподписью), для которого требуется два секретных ключа для расходования биткойнов. Один секретный ключ хранится в вычислительном устройстве (например, на локальном компьютере), а другой ключ хранится в отдельном вычислительном устройстве (например, смартфоне, удаленном сервере), создавая двухфакторную аутентификацию для транзакций. Такое решение было недоступно до создания настоящего изобретения.

(18) Другое решение состоит в том, чтобы сделать идентифицируемыми всех отправителей и получателей биткойнов. Подлинные личности (идентификаторы) похитителей или хакеров могут быть раскрыты на основе раскрытия подлинных личностей владельцев биткойн-адресов, принимающих похищенные биткойны. Такое решение было недоступно до создания настоящего изобретения.

(19) В настоящее время решения, направленные на борьбу с отмыванием денег (AML) для биткойнов, весьма востребованы. Для компаний, предоставляющих услуги биткойнов, которые отвечают нормам, принятым в США (FinCEN) и по всему миру в AML, современный подход состоит в совместном использовании правила "знай своего клиента" (KYC) и мониторинга транзакций. Чтобы это стало возможным, все трейдеры/клиенты должны предоставлять свои подлинные удостоверения личности и подвергаться верификации. Однако этот подход страдает двумя серьезными проблемами. Во-первых, этот подход в основном принимается компаниями, предоставляющими законные услуги. Поэтому AML-деятельность с вовлечением биткойнов может по-прежнему осуществляться в общемировом масштабе. Во-вторых, компании обычно имеют собственные системы регистрации клиентов и верификации идентичности.

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

(21) 25 февраля 2015 года Банк Англии запустил свою программу работ One Bank Research Agenda - амбициозную и широкую структуру для трансформации того, как исследования проводятся в банке. Согласно этому документу, представленному на обсуждение, Банк Англии исследует вопрос о том, должны ли центральные банки сами использовать технологию блокчейнов биткойна для выпуска своих собственных цифровых валют. Банк Англии заявил, что необходимо решать вопросы, связанные с KYC и AML, и изучать вопрос о том, как можно добиться управления цифровым удостоверением личности при балансировании соображений конфиденциальности.

(22) Принимая во внимание вышесказанное, было бы полезно разработать процесс персональной/клиентской идентификации и верификации, псевдонимную систему и транзакционную сеть для мониторинга и ограничения транзакций с электронными деньгами, основанными на криптографии, которые устраняли бы по меньшей мере некоторые из вышеупомянутых недостатков.

(23) Настоящее изобретение - "протокол аутентификации учетных данных, связанных с подлинной личностью" - это первый протокол, обеспечивающий практическое решение проблем, связанных с хищением криптовалюты, KYC и AML, при сохранении конфиденциальности пользователей.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

(25) Изобретение, представленное здесь, может быть обобщено следующими пунктами.

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

- предоставления доступа одному или нескольким потенциальным или существующим пользователям валюты (103);

- предоставления регистрационного интерфейса (102) для одного или нескольких потенциальных пользователей валюты для регистрации аккаунта (учетной записи) пользователя, требующего аутентификации (104);

- запроса на представление документов для подтверждения подлинной личности регистрируемого лица (регистранта) (105);

- верификации подлинной личности регистранта (106);

- отказа в создании аккаунта для регистрантов, не прошедших верификацию подлинной личности (107);

- создания персонального/клиентского аккаунта (108) для индивидуальных регистрантов (109) с успешной верификацией подлинной личности (110);

- разрешения успешному регистранту (109) создать учетные данные (111), которые содержат ассоциированную аутентификацию (112);

- сохранения (116) всей представленной информации в базе данных клиентской информации (115);

- отправки (117) учетных данных на центральные серверы утверждения (401); и

- отображения и сохранения (118) снабженного(ых) мультиподписью адреса(ов) валюты, учетных данных и подлинной личности индивидуальных регистрантов.

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

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

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

5. Способ создания основанных на криптографии электронных денег (СВЕМ) (201) и ассоциированной с ними транзакционной сети (202), причем способ выполняется сетью компьютерных программ, функционирующих как узлы, причем способ характеризуется тем, что он содержит этапы:

- инсталляции узла (203), который может быть автономной компьютерной программой или функциональным модулем клиентского кошелька (111), на одном или нескольких клиентских компьютерах и/или серверах (204);

- соединения всех узлов для формирования узлов (205) ретрансляции одноранговой сети через сеть передачи данных (206);

- управления способом для создания по меньшей мере одной единицы СВЕМ (207); защиты владения по меньшей мере одной единицей СВЕМ с помощью криптографии открытого/секретного ключа (208);

- регистрации владения по меньшей мере одной единицей СВЕМ в реестре всех транзакций (например, блокчейне) (209) с использованием адресов валюты владельцев (313) (210);

- верификации владения по меньшей мере одной единицей СВЕМ (211);

- ограничения только действительных зарегистрированных пользователей (109), чтобы генерировать один или несколько действительных адресов валюты (313) для приема по меньшей мере одного блока СВЕМ, путем верификации представленных учетных данных (111) одним из центральных серверов (401) (212) утверждения;

- записи транзакций по меньшей мере одной единицы СВЕМ в реестре (209) (213);

- верификации транзакций по меньшей мере одной единицы СВЕМ (214);

- управления способом для выполнения транзакции по меньшей мере одной единицы СВЕМ (215); включения правил транзакции в код программирования по меньшей мере одного узла (216);

- ограничения по меньшей мере одного правила (217) утверждения транзакции, содержащего по меньшей мере одно из: запрашивания действительных учетных данных (111) от отправителя, запрашивания одного или нескольких секретных ключей утверждения (406) от одного из центральных серверов утверждения (401);

- разрешения создания только транзакций с мультиподписью в формате pay-to-script-hash (платы хешу сценария) или в любом другом совместимом формате (218);

- разрешения создания только транзакций с мультиподписью, каждая из которых требует по меньшей мере двух секретных ключей в качестве подписей (219);

- разрешения создания только транзакций с мультиподписью при наличии действительных учетных данных (111) (220);

- ограничения одного из этих секретных ключей (219), чтобы он являлся секретным ключом утверждения (406) от одного из центральных серверов утверждения (221);

- ограничения остальных секретных ключей (219), чтобы они являлись клиентскими секретными ключами (222), которые зашифрованы и сохранены в клиентском(их) кошельке(ах) (301) (223);

- отправки всех запросов транзакций из клиентских кошельков (301) на один из центральных серверов утверждения (401) для получения секретного ключа утверждения для подписания транзакций (224); и

- отклонения всех транзакций, в которых отсутствует какой-либо один из требуемых секретных ключей (219); (225).

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

- инсталляции компьютерной программы клиентского устройства, чтобы функционировать в качестве клиентского кошелька (301) по меньшей мере на одном компьютере или вычислительном сервере (302);

- работы в качестве одного из узлов (205) ретрансляции для ретрансляции информации всех единиц СВЕМ (например, монет), генерируемых в транзакционной сети (202) (303); работы в качестве одного из узлов (205) ретрансляции для ретрансляции информации всех транзакций в транзакционной сети (202) (304);

- работы в качестве одного из узлов ретрансляции для верификации и подтверждения всех транзакций, которые транслируются в транзакционная сеть (202) (305);

- генерирования новых монет (денег) путем содействия записи любой новой информации транзакции в реестр всех транзакций (например, блокчейн) (209) (306);

- генерирования одной или нескольких пар криптографического клиентского открытого ключа (307) и клиентского секретного ключа (308) для приема и отправки монет (309);

- сохранения пар клиентских открытого и секретного ключей (пункты 307, 308) одного или нескольких адресов валюты, сгенерированных пользователями валюты (310);

- работы в качестве клиентского кошелька для пользователей валюты для приема и отправки монет; (311);

- работы в качестве клиентского кошелька для осуществления связи между одним из центральных серверов утверждения (401) и зарегистрированными пользователями валюты (109) (312);

- генерирования (314) только адресов валюты, которые являются адресами с мультиподписью (313);

- генерирования одного из нескольких адресов с мультиподписью (313) из клиентского открытого ключа (307) и открытого ключа утверждения (405) (315);

- сохранения только одного или нескольких адресов с мультиподписью (313) в клиентском кошельке (301) для отправки и приема монет (316);

- отправки одного из нескольких адресов с мультиподписью (313) в базу данных (401) клиентской информации для сохранения и отображения на подлинную личность владельца адреса(ов) (317);

- отправки сгенерированных действительных адресов с мультиподписью (313) на центральные серверы (401) утверждения для сохранения (318);

- представления учетных данных (111) действительных зарегистрированных пользователей (109) одному из центральных серверов утверждения для получения разрешения на генерацию одного или нескольких действительных адресов с мультиподписью валюты (313) (319);

- представления учетных данных (111) действительных зарегистрированных пользователей (109) одному из центральных серверов утверждения для получения разрешения на создание одной или нескольких действительных транзакций (пункты 218, 219, 220, 221, 223) для отправки монет на один или более адресов валюты (320);

- разрешения создания только транзакций, которые используют адреса с мультиподписью (313) для отправки и приема монет (321); и

- записи неизрасходованных монет (если таковые имеются) в блокчейн по адресу валюты, откуда только что были отправлены монеты (322).

7. Способ персональной/клиентской идентификации и верификации для транзакций с использованием основанных на криптографии электронных денег, причем способ выполняется компьютерной программой на вычислительном сервере, функционирующем как центральный сервер (401) утверждения, и способ характеризуется тем, что он содержит этапы:

- осуществления связи (407) с клиентским кошельком (301) для генерирования одного или нескольких действительных адресов валюты с мультиподписью (313) при наличии действительных учетных данных;

- предоставления (408) открытого ключа утверждения (405) в кошелек валюты для создания одного или нескольких адресов с мультиподписью (313),

- осуществления связи (409) с клиентским кошельком (301) для генерирования одной или нескольких действительных транзакций (218, 219, 220, 221, 223) для отправки монет по одному или нескольким адресам валюты при наличии действительных учетных данных;

- предоставления (410) секретного ключа утверждения (406), который соответствует открытому ключу (405) утверждения, использованному при создании адреса с мультиподписью (313), для подписи ввода транзакции для одной или нескольких действительных транзакций (218, 219, 220, 221, 223);

- предоставления самого последнего секретного ключа (411) для подписи всей транзакции для одной или нескольких действительных транзакций (412); и

- сохранения (414) информации о транзакции в базе данных транзакций (413).

8. Способ согласно п. 7, характеризующийся тем, что самый последний секретный ключ утверждения (411) является секретным ключом утверждения, соответствующим открытому ключу утверждения (405), использованному при создании адреса с мультиподписью (313), или другим секретным ключом утверждения.

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

10. Способ согласно п. 7, характеризующийся тем, что способ дополнительно содержит этап верификации транзакции по одному или нескольким критериям транзакции (501, 502) на центральном сервере утверждения (401).

11. Способ согласно п. 7, характеризующийся тем, что один или несколько критериев транзакции (501, 502) включают в себя критерии, предварительно определенные центральным органом управления (601) и/или регистрантом.

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

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

- приема учетных данных регистранта, содержащих по меньшей мере учетные данные двухфакторной аутентификации, определяющие мультиподпись;

- верификации подлинной личности регистранта;

- создания персонального/клиентского аккаунта (108) для индивидуального успешного регистранта (109) с успешной верификацией подлинной личности (110), причем

- персональный/клиентский аккаунт способствует отображению и хранению мультиподписи адреса валюты и подлинной личности индивидуальных регистрантов (118);

- предоставления кошелька регистранта, содержащего по меньшей мере одну единицу электронных денег;

- записи владения по меньшей мере одной единицей электронных денег в базу данных транзакций (413) с использованием адреса валюты регистрантов (313);

- создания транзакции с мультиподписью в формате pay-to-script-hash или любом другом совместимом формате (218), каждый из которых требует по меньшей мере двух секретных ключей в качестве подписей утверждения (219);

- ограничения одного из этих секретных ключей (219), чтобы он являлся секретным ключом утверждения (406) от одного из центральных серверов утверждения (221);

- ограничения остальных секретных ключей (219), чтобы они являлись секретными ключами регистранта (222), которые хранятся в клиентском кошельке (301, 223);

- отправки запроса транзакции из клиентского кошелька (301) по меньшей мере на один из центральных серверов утверждения (401) для получения секретного ключа утверждения для подписания транзакции (224); и

- трансляции сообщений об утвержденных транзакциях ко всем узлам ретрансляции в транзакционной сети (214).

14. Система персональной/клиентской идентификации и верификации для транзакций, связанных с основанными на криптографии электронными деньгами, причем система содержит:

- центральный сервер (401) утверждения, сконфигурированный, чтобы выполнять способ согласно пункту 7, чтобы обрабатывать клиентские запросы регистрации, клиентские адреса криптовалюты, транзакции с криптовалютой;

- базу данных (404) клиентской информации, коммуникативно связанную с центральным сервером утверждения (401);

- базу данных транзакций (413), коммуникативно связанную с центральным сервером утверждения (401);

- по меньшей мере одно клиентское устройство (414, 415), снабженное кошельком регистранта (416, 417), содержащим по меньшей мере одну единицу электронных денег;

- причем по меньшей мере одно клиентское устройство (414, 415) сконфигурировано для выполнения способа согласно пункту 13.

15. Компьютерная программа, содержащая средство программного кода для выполнения всех этапов реализуемого компьютером способа согласно п. 1, п. 5, п. 6, п. 7 и п. 13, когда упомянутая программа выполняется на компьютере или вычислительном сервере.

16. Считываемый компьютером носитель, хранящий исполняемые компьютером инструкции, выполняющие все этапы реализуемого компьютером способа согласно п. 1, п. 5, п. 6, п. 7 и п. 13 при исполнении на компьютере или вычислительном сервере.

17. Способ согласно п. 7, в котором пара открытого ключа утверждения (405) и секретного ключа утверждения (406) может изменяться вручную или автоматически с регулярным периодом, чтобы избежать утечки открытого ключа утверждения и секретного ключа утверждения к общественности. После перехода на новую пару ключей утверждения, старый секретный ключ утверждения будет использоваться для подписания ввода транзакции (410), а новый секретный ключ утверждения будет использоваться для подписания всей транзакции (т.е. данных всей транзакции) (412).

18. Способы согласно п. 5, п. 6 и п. 7, в которых любые адреса валюты, которые не генерируются путем представления действительных учетных данных на один из центральных серверов утверждения (401), являются недействительными и не способны принимать какие-либо монеты.

19. Способ согласно п. 10, в котором транзакционная сеть (202) может быть модифицирована, чтобы отклонять любые транзакции, которые не удовлетворяют централизованным критериям транзакции (501) или клиентским критериям транзакции (502), хранящимся на одном из центральных серверов утверждения (401).

20. Способ согласно п. 19, в котором клиентские критерии транзакции (502) могут быть определены действительным зарегистрированным пользователем для ограничения его/ее собственных транзакций.

21. Способ согласно п. 19, в котором критерии транзакции (501) могут быть определены центральным органом управления (601) для прекращения подозрительных транзакций, которые могут быть вовлечены в незаконную деятельность, такую как отмывание денег.

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

23. Способ согласно п. 5, в котором подлинные личности владельцев индивидуальных адресов валюты хранятся в базе данных клиентской информации. Для транзакций, заподозренных в принадлежности к незаконной деятельности (п. 22), идентификаторы их ассоциированных отправителей и получателей будут извлечены из базы данных клиентской информации путем отслеживания адресов валюты отправителей и получателей. Затем подозрительные действия и ассоциированная клиентская информация будут сообщены правительственным учреждениям в соответствии с нормами и законами в соответствующих странах.

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

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

26. Способы согласно п. 1 и п. 5, в которых пользователь может изменить его/ее учетные данные (111), чтобы остановить перевод монет из похищенного основного файла данных (например, файла wallet.dat) его/ее кошелька валюты (301).

27. Способы согласно п. 1, п. 5, п. 6 и п. 12, в которых (i) подлинные личности владельцев для индивидуальных адресов валюты хранятся в базе данных клиентской информации, (ii) любые адреса валюты, которые не генерируются посредством представления действительных учетных данных на один из центральных серверов утверждения (401), недействительны и не могут принимать какие-либо монеты (п. 18), и (iii) только действительные зарегистрированные пользователи имеют действительные учетные данные (112). Когда монеты похищены у кого-либо, похититель(и) или хакер(ы) могут быть легко прослежены путем извлечения подлинной(ых) личности(ей) получателя(ей) из базы данных клиентской информации в соответствии с адресом(ами) валюты получателя(ей). Таким образом, реализация способов согласно п. 1, п. 6 и п. 7 предотвращает хищение криптовалюты.

28. Способы согласно п. 5, п. 6 и п. 12, в которых количество монет, принадлежащих действительному зарегистрированному пользователю, является полностью и легко отслеживаемым и может отслеживаться центральным органом управления (601) путем анализа записей транзакций в базе данных транзакций (413). Помимо возможности связывания индивидуальных адресов валют с их владельцами, этому уникальному свойству содействует запись неизрасходованных монет (если таковые имеются) на адресе валюты, из которого только что были отправлены/потрачены монеты (322). Это уникальное свойство обеспечивает возможность применений нашей системы к финансовой и банковской деятельности, особенно той, для которой требуется сторонний аудит.

29. Способы согласно п. 20 и п. 21, которые обеспечивают практические решения проблем, связанных с хищением криптовалюты, KYC и AML, при сохранении конфиденциальности пользователей.

30. Системы согласно п. 20 и п. 21, которые могут быть приняты или модифицированы центральными банками или другими финансовыми учреждениями для выпуска своих собственных цифровых валют, которые поддерживаются платежной системой распределенного реестра, но также регулируются центральным органом управления.

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

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

- предоставление доступа одному или нескольким потенциальным или существующим пользователям валюты;

- предоставление онлайн-интерфейса для одного или нескольких потенциальных пользователей валюты для регистрации пользовательского аккаунта с защитой паролем, двухфакторной аутентификации или многофакторной аутентификации;

- запрашивание предоставления документов для проверки подлинной личности регистранта;

- обработка верификации подлинной личности регистранта;

- отказ создания аккаунта для регистрантов, не прошедших верификацию подлинной личности;

- создание персонального/клиентского аккаунта для индивидуальных успешных регистрантов с успешной верификацией подлинной личности;

- разрешение успешному регистранту создать учетные данные, которые содержат метку и пароль;

- разрешение успешному регистранту изменять учетные данные и контактную информацию;

- шифрование учетных данных;

- сохранение всей предоставленной информации, в частности, подлинной личности и зашифрованных учетных данных, в базе данных клиентских данных;

- отправка зашифрованных учетных данных, которые были вновь сгенерированы или изменены, на центральные серверы утверждения;

- отображение и сохранение адреса(ов) валюты с мультиподписью, учетных данных и подлинной личности индивидуальных регистрантов.

(27) Одни основанные на криптографии электронные деньги и ассоциированная с ними транзакционная сеть выполняют по меньшей мере некоторые или все из следующих базовых функций и уникальных функций:

1. Базовые функции - общие для всех других основанных на криптографии электронных денег:

- предоставление общественности программного обеспечения клиентского кошелька;

- соединение компьютеров или серверов через клиентские кошельки;

- использование соединенных компьютеров или серверов для формирования узлов ретрансляции транзакционной сети;

- генерирование предопределенного количества денежных единиц (монет) с предопределенной скоростью;

- защита владельцев монет посредством криптографии открытого/секретного ключа;

- запись владельцев монет в реестр всех транзакций (например, блокчейн) с использованием адресов валюты владельцев;

- распространение реестра всех транзакций (например, блокчейна) и его обновлений людям, которые соединены с транзакционной сетью через клиентский кошелек;

- разрешение владельцу секретного ключа отправлять некоторое количество монет только без превышения количества монет, записанного на соответствующем адресе валюты, после вычета требуемой комиссии за транзакцию;

- трансляция сообщений обо всех новых транзакциях ко всем узлам ретрансляции в транзакционной сети;

- верификация сообщений обо всех новых транзакциях на индивидуальных узлах ретрансляции;

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

2. Уникальные функции:

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

- разрешение создания только транзакций с мультиподписью в формате "pay-to-script-hash" или в любом другом совместимом формате;

- разрешение создания только транзакций с мультиподписью, каждая из которых требует по меньшей мере два секретных ключа в качестве подписей;

- разрешение создания только транзакций с мультиподписью при наличии действительных учетных данных;

- ограничение одного из этих секретных ключей, чтобы он являлся секретным ключом утверждения от одного из центральных серверов утверждения;

- ограничение остальных секретных ключей, чтобы они являлись клиентскими секретными ключами, которые зашифрованы и сохранены в клиентском(их) кошельке(ах);

- отправка всех запросов транзакций из клиентских кошельков на один из центральных серверов утверждения для получения секретного ключа утверждения для подписания транзакций;

- отклонение всех транзакций, в которых отсутствует какой-либо из требуемых секретных ключей;

- ограничение правил утверждения транзакций (включая, но без ограничения указанным, затребование действительных учетных данных от отправителя, затребование одного или нескольких секретных ключей утверждения от одного из центральных серверов утверждения для подписания ввода транзакции и для подписания всей транзакции) для индивидуальных транзакций с использованием сценария "pay-to-script-hash" или любого другого совместимого сценария, который встроен в источник электронных денег как единственный сценарий для создания транзакции.

(28) По меньшей мере один компьютер или сервер для исполнения программного обеспечения клиентского кошелька, причем по меньшей мере один клиентский кошелек выполняет по меньшей мере некоторые или все следующие базовые функции и уникальные функции:

1. Базовые функции - общие для всех других основанных на криптографии электронных денег:

- работа в качестве одного из узлов ретрансляции для ретрансляции информации всех транзакций в транзакционную сеть;

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

- генерирование новых монет путем способствования записи информации любой новой транзакции в реестр всех транзакций (например, блокчейн);

- генерирование одной или нескольких пар криптографического клиентского открытого ключа и клиентского секретного ключа для приема и отправки денег;

- сохранение пары клиентских открытого-секретного ключей пары одного или нескольких адресов валют, генерируемых пользователями валюты;

- работа в качестве клиентского кошелька для пользователей валюты, чтобы получать и отправлять деньги;

2. Уникальные функции

- работа в качестве клиентского кошелька, чтобы осуществлять связь между одним из центральных серверов утверждения и зарегистрированными пользователями валюты;

- генерирование только адресов валют, которые являются адресами с мультиподписью;

- генерирование одного из нескольких адресов с мультиподписью из клиентского открытого ключа и открытого ключа утверждения;

- сохранение только одного или нескольких адресов с мультиподписью в клиентском кошельке для отправки и приема монет;

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

- отправка сгенерированных действительных адресов с мультиподписью на центральные серверы утверждения для сохранения;

- представление учетных данных действительного зарегистрированного пользователя на один из центральных серверов утверждения для получения разрешения на генерирование одного или нескольких допустимых адресов с мультиподписью валюты;

- представление учетных данных действительного зарегистрированного пользователя на один из центральных серверов утверждения для получения разрешения на создание одной или нескольких действительных транзакций для отправки монет по одному или нескольким адресам валюты;

- разрешение создания только транзакций, которые используют адреса с мультиподписью для отправки и приема монет;

- запись неизрасходованных монет (если таковые имеются) в блокчейн по адресу валюты, откуда только что были отправлены монеты.

(29) По меньшей мере один центральный сервер утверждения, причем по меньшей мере один центральный сервер утверждения выполняет по меньшей мере некоторые или все из следующих функций:

1. извлечение новых или обновленных учетных данных и ассоциированных с ними адресов валюты из базы данных клиентской информации;

2. сохранение и обновление учетных данных пользователей и ассоциированных с ними адресов валюты в центральной базе данных утверждения;

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

4. осуществление связи с клиентским кошельком, чтобы генерировать один или несколько допустимых адресов валюты с мультиподписью при наличии действительных учетных данных;

5. предоставление открытого ключа подтверждения для кошелька валюты, чтобы создать один или нескольких адресов с мультиподписью;

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

7. предоставление секретного ключа утверждения, который соответствует открытому ключу утверждения, используемому при создании адреса с мультиподписью, чтобы подписывать ввод транзакции для одной или нескольких действительных транзакций;

8. предоставление другого секретного ключа утверждения, который может быть секретным ключом утверждения, используемым в пункте 410, или самым последним секретным ключом утверждения, чтобы подписывать всю транзакцию для одной или нескольких действительных транзакций;

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

(30) Далее, раскрыт способ персональной/клиентской идентификации и верификации для транзакций, связанных с основанными на криптографии электронными деньгами, причем способ содержит по меньшей мере некоторые или все из этапов:

1. верификации подлинной личности регистранта;

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

3. приема учетных данных индивидуального успешного регистранта, определяющего идентичность регистранта, владение адресом валюты и идентичность отправителя транзакции;

4. сохранения подлинной личности регистранта и учетных данных на одном или нескольких центральных серверах утверждения;

5. предоставления кошелька регистранта для отправки и приема по меньшей мере одной единицы электронных денег;

6. записи владения по меньшей мере одной единицей электронных денег в реестр всех транзакций (например, блокчейн) с использованием адреса(ов) валюты регистранта;

7. приема и верификации учетных данных, которые представлены из кошелька регистранта по запросу на генерацию адреса валюты, на центральном сервере утверждения;

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

9. генерирования действительного адреса валюты для приема по меньшей мере одной единицы электронных денег путем комбинирования открытого ключа регистранта и открытого ключа утверждения центрального сервера утверждения в кошельке регистранта;

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

11. создания транзакции в формате "pay-to-script-hash" или в любом другом совместимом формате, каждый из которых требует по меньшей мере двух секретных ключей в качестве подписей в кошельке регистранта;

12. ограничения по меньшей мере одного из этих секретных ключей, чтобы он являлся секретным ключом утверждения из одного из центральных серверов утверждения;

13. ограничения остальных секретных ключей, чтобы они являлись секретными ключами регистрантов, которые хранятся в клиентских кошельках;

14. ограничения правил утверждения транзакции (включая, но без ограничения указанным, затребование действительных учетных данных от отправителя, затребование одного или нескольких секретных ключей утверждения от одного из центральных серверов утверждения для подписания ввода транзакции и для подписания всей транзакции) для индивидуальных транзакций с использованием сценария "pay-to-script-hash" или любого другого совместимого сценария, который встроен в источник электронных денег в качестве единственного сценария создания транзакции;

15. приема и верификации учетных данных, которые представлены из кошелька регистранта по запросу на создание транзакции, на центральном сервере утверждения;

16. верификации транзакции по одному или нескольким критериям транзакции (включая, но без ограничения указанным, те, которые предварительно определены центральным органом управления и/или регистрантом) на центральном сервере утверждения;

17. одобрения выполнения транзакции путем подписания транзакции с одним или несколькими секретными ключами в кошельке(ах) регистранта и путем подписания транзакции одним или несколькими секретными ключами утверждения на центральном сервере утверждения;

18. записи сообщения транзакции в реестр всех транзакций (например, блокчейн);

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

20. трансляции подписанного сообщения транзакции ко всем узлам ретрансляции в транзакционной сети для подтверждения;

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

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

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

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

(34) Системы и способы, описанные выше, могут иметь по меньшей мере некоторые или все из следующих предпочтительных признаков.

(35) Предпочтительно, пара открытого ключа утверждения и секретного ключа утверждения может изменяться вручную или автоматически с регулярным периодом, чтобы избежать утечки открытого ключа утверждения и секретного ключа утверждения к общественности. После перехода на новую пару ключей утверждения, старый секретный ключ утверждения будет использоваться для подписания ввода транзакции, а новый секретный ключ утверждения будет использоваться для подписания всей транзакции (т.е. данных всей транзакции).

(36) Предпочтительно, любые адреса валюты, которые не генерируются путем представления действительных учетных данных на один из центральных серверов утверждения, являются недействительными и не способны принимать какие-либо монеты.

(37) Предпочтительно, транзакционная сеть может быть модифицирована, чтобы отклонять любые транзакции, которые не удовлетворяют централизованным критериям транзакций, сохраненным на одном из центральных серверов утверждения.

(38) Предпочтительно, клиентские критерии транзакции могут быть определены действительным зарегистрированным пользователем, чтобы ограничивать его/ее собственные транзакции.

(39) Предпочтительно, критерии транзакции могут быть определены центральным органом управления для прекращения подозрительных транзакций, которые могут быть вовлечены в незаконную деятельность, такую как отмывание денег.

(40) Предпочтительно, индивидуальные транзакции могут контролироваться с помощью определенных правил для идентификации, регистрации и отправки сообщений о подозрительных транзакциях, которые могут быть вовлечены в незаконную деятельность, такую как отмывание денег.

(41) Предпочтительно, подлинные личности владельцев индивидуальных адресов валюты хранятся в базе данных клиентской информации. Для транзакций, подозреваемых в принадлежности к незаконной деятельности, идентичности их ассоциированных отправителей и получателей будут извлечены из базы данных клиентской информации путем отслеживания адресов валюты отправителей и получателей. Затем подозрительная деятельность и ассоциированная с ними клиентская информация будут сообщены правительственным учреждениям с учетом норм и законов в соответствующих странах.

(42) Предпочтительно, подлинные личности владельцев индивидуальных адресов валюты хранятся в базе данных клиентской информации. Это соответствует нормативному требованию "знай своего клиента". Это позволяет использовать систему в качестве платежной системы для коммерческой деятельности.

(43) Предпочтительно, подлинные личности владельцев индивидуальных адресов валюты хранятся в базе данных клиентской информации. Однако такая информация недоступна для общественности, чтобы поддерживать псевдонимное свойство основанных на криптографии электронных денег и их транзакционной сети.

(44) Предпочтительно, пользователь может изменить его/ее учетные данные, чтобы прекратить перевод денег из похищенного основного файла данных (например, файла wallet.dat) его/ее кошелька валюты. Предпочтительно, (i) подлинные личности владельцев индивидуальных адресов валюты хранятся в базе данных клиентской информации, (ii) любые адреса валюты, которые не сгенерированы путем представления действительных учетных данных на один из центральных серверов утверждения, не способны принимать какие-либо монеты, и только действительные зарегистрированные пользователи имеют действительные учетные данные. Когда монеты похищены у кого-то, похититель(и) или хакер(ы) могут легко прослеживаться путем извлечения подлинной(ых) личности(ей) получателя(ей) из базы данных клиентской информации. Таким образом, реализация системы препятствует хищению криптовалюты.

(45) Предпочтительно, количество монет, принадлежащих действительному зарегистрированному пользователю, является полностью и легко отслеживаемым и может отслеживаться центральным органом управления путем анализа записей транзакций в базе данных транзакций. Помимо возможности связывания индивидуальных адресов валют с их владельцами, это уникальное свойство обеспечивается путем записи неизрасходованных денег (если таковые имеются) по адресу валюты, из которого только что были отправлены/потрачены монеты. Это уникальное свойство обеспечивает возможность применений нашей системы в финансовой и банковской деятельности, в частности, той, для которой требуется сторонний аудит.

(46) Предпочтительно, системы обеспечивают практическое решение проблем, связанных с хищением криптовалюты, KYC и AML, при сохранении конфиденциальности пользователей.

(47) Предпочтительно, системы могут быть приняты или модифицированы центральными банками или другими финансовыми учреждениями для выпуска своих собственных цифровых валют, которые поддерживаются платежной системой распределенного реестра, но также регулируются центральным органом управления.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

(48) Эти и другие цели изобретения, представленные здесь, выполняются путем предоставления системы и способа персональной/клиентской идентификации и верификации. Дополнительные подробности и признаки настоящего изобретения, его сущность и различные преимущества поясняются в последующем подробном описании предпочтительных вариантов осуществления, показанных на чертежах, на которых:

(49) Фиг. 1 представляет систему регистрации и базы данных для сбора, верификации и хранения подлинной личности нового пользователя для основанных на криптографии электронных денег;

(50) Фиг. 2 изображает систему аутентификации связанных с подлинной личностью учетных данных для генерации адреса валюты с мультиподписью для приема и отправки основанных на криптографии электронных денег;

(51) Фиг. 3 изображает систему аутентификации связанных с подлинной личностью учетных данных и схему подписи двумя сторонами для генерации платежной транзакции с количеством монет, принадлежащих пользователю и записанных по адресу с мультиподписью;

(52) Фиг. 4 представляет схему системы в соответствии с настоящим изобретением.

Примечания и терминология

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

(54) Обычно эти величины принимают форму электрических или магнитных сигналов, которые можно хранить, передавать, комбинировать, сравнивать и которыми можно иным образом манипулировать в компьютерной системе. На основании обычного использования, эти сигналы называются битами, пакетами, сообщениями, значениями, элементами, символами, знаками, термами, числами и т.п.

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

(56) Считываемый компьютером носитель (хранения), такой как упоминается в настоящем документе, обычно может быть некратковременным (непереходным) и/или может содержать некратковременное устройство. В этом контексте, некратковременный носитель хранения может включать в себя устройство, которое может быть осязаемым, что означает, что устройство имеет конкретную физическую форму, хотя устройство может изменять свое физическое состояние. Так, например, непереходность относится к устройству, остающемуся осязаемым, несмотря на изменение состояния.

(57) Как используется в настоящем документе, термин "примерный" означает служащий в качестве неограничивающего примера, образца или иллюстрации. Как используется в настоящем документе, термин "например" вводит список из одного или нескольких неограничивающих примеров, образцов или иллюстраций.

ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

(58) Настоящее изобретение относится к техническим областям основанных на криптографии электронных денег (СВЕМ), таких как альтернативная криптовалюта, и систем транзакций. Более конкретно, настоящее изобретение относится к способу и системе для создания новых СВЕМ и ассоциированной с ними платежной системы, которая позволяет раскрывать подлинную личность отправителей и получателей во всех денежных транзакциях, сохраняя при этом псевдонимное свойство СВЕМ.

(59) Настоящее изобретение позволяет включать дополнительные модули для мониторинга всех транзакций и идентификации тех, которые потенциально связаны с незаконной деятельностью, и для включения критериев, которые определяются центральным органом управления или пользователями СВЕМ, для регулирования или ограничения транзакций.

(60) В результате настоящее изобретение обеспечивает практическое решение проблем, связанных с хищением криптовалюты, KYC и AML, при сохранении конфиденциальности пользователей. Более того, настоящее изобретение может быть принято или модифицировано центральными банками или другими финансовыми учреждениями для выпуска своих собственных цифровых валют, которые поддерживаются платежной системой распределенного реестра, но также регулируется центральным органом управления.

(61) С этой целью настоящее изобретение задействует интеграцию трех основных процессов, включая (i) верификацию подлинной личности, (ii) аутентификацию учетных данных и (iii) схему подписи двух сторон. Варианты осуществления настоящего изобретения могут обеспечивать системы и способы создания СВЕМ и ассоциированной с ними платежной системы, которая позволяет центральному органу управления выявлять подлинные личности отправителей и получателей в любых денежных транзакциях, сохраняя при этом псевдонимное свойство СВЕМ.

(62) Механизм аутентификации учетных данных согласно настоящему изобретению позволяет пользователю изменять учетные данные, чтобы останавливать перевод денег из похищенного кошелька. И наконец, но не в последнюю очередь, поскольку отправители и получатели всех транзакций могут быть выявлены, похититель (и) или хакер(ы), которые похитили деньги, могут легко прослеживаться путем извлечения подлинной(ых) личности(ей) получателя(ей) из базы данных клиентской информации. В результате, варианты осуществления настоящего изобретения могут предотвратить хищения монет СВЕМ.

(63) Для того чтобы иметь возможность выявлять подлинные личности отправителей и получателей всех транзакций СВЕМ, требуются следующие два ключевых элемента:

1. подлинные личности всех получателей и отправителей СВЕМ;

2. запрет анонимным людям получать и отправлять монеты СВЕМ.

(64) Эти два ключевых элемента можно обеспечить, путем разрешения только зарегистрированным пользователям с верифицированной подлинной личностью получать и отправлять СВЕМ. Для регистрации и верификации подлинных личностей, для каждого регистранта создается веб-интерфейс регистрации для представления информации, чтобы предоставлять и подтверждать его/ее подлинную личность, и только те люди, которые имеют успешно верифицированную подлинную личность, принимаются в качестве действительных пользователей. Затем они могут получать и отправлять СВЕМ. Однако основная трудность заключается в том, как запретить анонимным людям получать и отправлять монеты СВЕМ, особенно СВЕМ открытых исходников.

(65) СВЕМ, такие как биткойн, спроектированы как децентрализованная платежная система. Ожидается, что их коды компьютерного программирования будут доступны для ознакомления любым из онлайн-сообществ открытого исходника. Когда СВЕМ является открытым исходником, любой может использовать исходный код для создания своего адреса валюты для получения и отправки монет. Поэтому подход к регистрации KYC может применяться только к конкретным поставщикам услуг, но не ко всем пользователям монет.

(66) Чтобы ограничить использование монет только зарегистрированными пользователями, был разработан новый метод для дифференциации адресов валюты, генерируемых зарегистрированными не анонимными пользователями (то есть действительных адресов валют), от тех, которые генерируются незарегистрированными анонимными пользователями (т.е. недействительных адресов валюты), и был разработан другой метод, позволяющий использовать только действительные адреса валюты для приема и отправки монет.

(67) Настоящее изобретение обеспечивает практическое решение этих двух задач путем интеграции трех основных процессов, включая (х) верификацию подлинной личности, (ii) аутентификацию учетных данных и (iii) схему подписи двух сторон. Такая интеграция требует технических изменений в следующем:

1. модификации протокола биткойн-транзакций с мультиподписью;

2. привязки его к базе данных клиентской информации;

3. обеспечения его в качестве обязательного протокола транзакции и

4. обязательного обеспечения одной подписи транзакции в качестве секретного ключа из одного из центральных серверов утверждения.

(68) Варианты осуществления настоящего изобретения могут быть достигнуты с помощью следующих основных этапов:

Этап 1. Настройка компьютерного сервера и веб-интерфейса для сбора, верификации и хранения подлинных личностей пользователей и для создания специфических для пользователей учетных данных;

Этап 2. Использование веб-интерфейса для создания учетных данных для регулирования процесса генерации адресов валюты;

Этап 3: Использование подхода мультиподписи для приема и отправки монет; и

Этап 4: Приведение в исполнение транзакций с оплатой кэшу сценария ("pay-to-script-hash"), регулируемых определенными правилами.

(69) Вышеупомянутые этапы будут описаны ниже более подробно.

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

(70) Этап настройки компьютерного сервера и веб-интерфейса (например, BGCwallet.com) касается пользователей СВЕМ (например, Aten Coin). В процессе регистрации, лицо должно предоставить документ/информацию о его/ее подлинной личности (например, ID паспорта и копию страницы удостоверения личности его/ее паспорта) и пройти процесс верификации его/ее подлинной личности (например, служба верификации идентичности от MiiCard или IDchecker). Для успешной регистрации требуется успешная верификации его/ее подлинной личности. Вся предоставленная информация будет храниться в базе данных клиентской информации.

(71) На фиг. 1 представлена система регистрации и базы данных для сбора, верификации и хранения подлинной личности нового пользователя для основанных на криптографии электронных денег.

(72) По меньшей мере один сервер, содержащий по меньшей мере один веб-интерфейс регистрации (102), выполняет следующие функции. Сначала, на этапе (105) через веб-интерфейс регистрации (102) запрашивается представление документов для подтверждения подлинной личности регистранта. Затем, на этапе (106) обрабатывается верификация подлинной личности регистранта. Безуспешная верификации приводит к ошибке регистрации (107). В качестве альтернативы, успешному регистранту (109) разрешается создать двухфакторную аутентификацию или многофакторную аутентификацию (104), чтобы предотвратить несанкционированный доступ к его/ее зарегистрированному пользовательскому аккаунту и вредоносную атаку.

(73) Двухфакторная аутентификация - это безопасный способ защиты онлайн пользовательского аккаунта (104). Он работает путем затребования от пользователя идентифицировать себя с использованием двух различных факторов, когда он/она входит в его/ее онлайн аккаунт. Первым фактором аутентификации является пара зарегистрированного имени для входа в систему и пароля для входа в систему, созданных пользователем; вторым фактором аутентификации является постоянно меняющийся токен (например, уникальный 7-значный код), который привязан к физическому устройству, которое принадлежит пользователю, например сотовому телефону или персонализированному устройству для генерации защищенных ключей. Тогда такой онлайн пользовательский аккаунт нельзя взломать без кражи персонального физического устройства. Многофакторная аутентификация также может быть возможна путем затребования от пользователя идентифицировать себя, используя три или более различных факторов, когда он/она входит в его/ее онлайн аккаунт (например, пара имени для входа в систему и пароля для входа в систему, сотовый телефон и смарт-карта удостоверения личности).

(74) От успешного регистранта (109) требуется создать учетные данные (111), которые содержат метку и пароль (112). Естественно, успешному регистранту (109) разрешено изменять учетные данные и контактную информацию (113), все из которых предпочтительно зашифрованы на этапе (114). Учетные данные требуются пользователю, чтобы генерировать его/ее адрес(а) кошелька с мультиподписью (фиг. 2) для получения монет (например, атенкойнов (atencoin)) и для создания транзакций (фиг. 3).

(75) Опционально, на этапе 502 могут быть определены клиентские критерии транзакции действительным зарегистрированным пользователем для ограничения его/ее собственных транзакций. Например, пользователь может установить критерий, который ограничивает максимальную количество монет, отправленных с его/ее адреса(ов) валюты в течение 24 часов. Это может свести к минимуму потерю его/ее монет, когда его/ее кошелек валюты похищен или взломан.

(76) Когда все вышеописанное завершено, на этапе (116) выполняется сохранение всей представленной информации, особенно подлинной личности и зашифрованных учетных данных, в базе данных клиентской информации (115).

(77) Наконец, на этапе 117 выполняется отправка зашифрованных учетных данных, которые сгенерированы заново или изменены, на центральные серверы утверждения (401). Центральные серверы утверждения выполняют отображение и сохранение адреса(ов) валюты с мультиподписью, учетных данных и подлинной личности индивидуальных регистрантов (118). Например, адрес валюты с мультиподписью представляет собой уникальную строку из 34 символов, состоящую из чисел, строчных и прописных букв алфавита (например, Aj8xFozUjo3GoNvi95kABpTj02qQReZo5P); идентификационные данные (идентичность) лица составляется из (i) полного легального имени, напечатанного на национальном удостоверении личности или паспорте пользователя, (ii) номера национального удостоверения личности/паспорта и (iii) даты рождения.

(78) Этап 2: Использование веб-интерфейса для создания учетных данных для регулирования процесса генерации адреса валюты

Используя веб-интерфейс, только действительный зарегистрированный пользователь (106, 109) может генерировать учетные данные (111) (фиг. 1, 112), которые требуются для генерации его/ее адреса(ов) с мультиподписью (как показано на фиг. 2) для приема и отправки монет (например, атенкойнов) (как показано на фиг. 3). Использование учетных данных запрещает незарегистрированным анонимным пользователям генерировать любые действительные адреса с мультиподписью для приема и отправки денег в системе. Другими словами, все действительные адреса валюты для отправки или получения денег СВЕМ связаны с реальными людьми с известными подлинными личностями.

(79) Этап 3: Использование подхода с мультиподписью для приема и отправки денег

(80) По замыслу, один открытый ключ утверждения из одного из центральных серверов утверждения и по меньшей мере один клиентский открытый ключ требуются для генерации действительных адресов с мультиподписью для приема и отправки денег (фиг. 2). Прежде чем пользователь сможет использовать клиентский кошелек (301) для генерации адреса для приема монет, он/она должны ввести его/ее учетные данные (111) в клиентский кошелек. В процессе генерации адреса, клиентский кошелек сначала будет представлять учетные данные на один из центральных серверов утверждения (401) через электронную/цифровую сеть передачи данных (например, Интернет) для верификации (407).

(81) После проверки действительности учетных данных, то есть успешного сопоставления с действительными и активными учетными данными в базе данных центральных серверов утверждения (319, 401, 407), центральный сервер утверждения предоставит открытый ключ утверждения (408) на клиентский кошелек через электронную/цифровую сеть передачи данных. Если учетные данные обнаружены недействительными или неактивными, центральный сервер утверждения возвращает сообщение об ошибке на клиентский кошелек. После получения открытого ключа утверждения, клиентский кошелек будет продолжать генерировать адрес с мультиподписью (315).

(82) После получения сообщения об ошибке, клиентский кошелек остановит процесс генерации адреса с мультиподписью. При наличии открытого ключа утверждения, клиентский кошелек генерирует (309) пару клиентского открытого ключа (307) и секретного ключа (308) и сохраняет (310) в клиентском кошельке и затем объединяет открытый ключ утверждения (405) и клиентский открытый ключ (307) для создания адреса с мультиподписью (315), который, следовательно, тесно связан с секретным ключом утверждения и клиентским секретным ключом. Адрес с мультиподписью сохраняется и отображается в клиентском кошельке (316). Пользователь может использовать адрес с мультиподписью для приема монет СВЕМ (например, атенкойнов).

(83) Наличие открытого публичного ключа утверждения в каждом адресе с мультиподписью предписывает, что все транзакции должны получить как подпись утверждения (т.е. секретный ключ утверждения (406)) из одного из центральных серверов утверждения, так и клиентскую подпись (т.е. клиентский секретный ключ (308)) для подтверждения действительности.

(84) Используя эту систему управления, только допустимые зарегистрированные пользователи могут генерировать адреса с мультиподписью. Эти адреса затем могут использоваться для совершения транзакций, которые должны быть подписаны заверяющей подписью одним из центральных серверов утверждения.

(85) На фиг. 2 изображена система аутентификации учетных данных, связанных с подлинной личностью, для генерации адреса валюты с мультиподписью для приема и отправки основанных на криптографии электронных денег.

(86) Процесс начинается на этапе (301) с предоставления клиентского кошелька, который является сетевым ресурсом, предпочтительно доступным как программное обеспечение. Затем введенные пользовательские учетные данные с этапа (111) применяются, чтобы активировать клиентский кошелек. Затем на этапе (314) пользователь пытается создать адрес валюты, причем система генерирует только адреса валюты, которые являются адресами с мультиподписью.

(87) Затем на этапе (319) выполняется представление учетных данных действительных зарегистрированных пользователей на один из центральных серверов (401) утверждения для получения разрешения на генерацию одного или нескольких действительных адресов валюты с мультиподписью.

(88) В случае отказа в разрешении, может генерироваться соответствующее сообщение об ошибке. Иначе, в случае разрешения, на этапе (309) выполняется генерация одной или нескольких пар криптографического клиентского открытого ключа (307) и клиентского секретного ключа (308) для приема и отправки монет. Эти клиентский открытый ключ и клиентский секретный ключ сохранены и ассоциированы с клиентским кошельком (310). В случае разрешения, на этапе 408 также выполняется предоставление открытого ключа (405) утверждения, который математически связан с секретным ключом утверждения (406), от центрального сервера утверждения на клиентский кошелек.

(89) Кроме того, на этапе (315) выполняется генерация одного из нескольких адресов с мультиподписью из клиентского(их) открытого(ых) ключа(ей) (307) и открытого(ых) ключа(ей) утверждения (405). Сгенерированный адрес валюты с мультиподписью сохраняется и ассоциирован с клиентским кошельком (316).

(90) Затем на этапе (317) выполняется отправка одного из нескольких адресов с мультиподписью в базу данных клиентской информации (115) для сохранения и отображения на подлинную личность владельца адреса(ов) (118).

(91) Этап 4: Обеспечение выполнения транзакций pay-to-script-hash, регулируемых конкретными правилами

(92) Разработчики биткойнов в настоящее время создали два разных метода для создания и утверждения транзакций биткойнов с использованием разных пар scriptSig/scriptPubKey. Этими двумя методами являются: pay-to-pubkey-hash и pay-to-script-hash.

(93) Pay-to-pubkey-hash является наиболее часто используемым методом в ежедневных биткойн-транзакциях. В транзакции pay-to-pubkey-hash биткойн-адрес представляет собой 160-битный хэш общедоступной части пары открытого/секретного ключей алгоритма цифровых подписей на основе эллиптических кривых (ECDSA), и отправитель биткойнов предоставляет биткойн-адрес в scriptPubKey. В транзакции pay-to-pubkey-hash, отправитель передает биткойны непосредственно владельцу открытого ключа.

(94) Для того, чтобы инициировать транзакцию pay-to-pubkey-hash, отправителю необходимо предоставить открытый ключ, биткойны которого сохранены в соответствующем биткойн-адресе, и соответствующую подпись (т.е. парный секретный ключ), и биткойн-адрес для приема биткойнов. Биткойн-адрес приема напрямую связан с его соответствующим открытым ключом и подписью. При погашении монет, которые были отправлены на биткойн-адрес, получатель предоставляет как подпись, так и открытый ключ. Сценарий проверяет, что предоставленный открытый ключ создает хеш соответственно хешу в scriptPubKey, а затем проверяет подпись по отношению к открытому ключу.

(95) Адреса, ассоциированные с транзакциями pay-to-script, представляют собой хеши сценариев вместо хеша открытого ключа. Чтобы тратить биткойны посредством pay-to-script-hash, процесс требует предоставления сценария, соответствующего хешу сценария, и данных, которые приводят к оценке сценария как "истинно". Другими словами, нужно предоставить ввод (т.е. ответ) на соответствующий сценарий, который сценарий принимает, и транзакция продолжается. Если ввод недействителен и сценарий не будет принят, это приведет к прекращению транзакции.

(96) Используя pay-to-script-hash, можно отправлять биткойны на адрес, который защищен различными необычными способами, не зная ничего о деталях настройки безопасности. Например, получателю могут потребоваться подписи нескольких человек для приема биткойнов, хранящихся на конкретном биткойн-адресе, или может потребоваться пароль, или требования могут быть полностью уникальными. Для биткойнов и всех других современных криптовалют, разработанных на основе технологии биткойнов, pay-to-script-hash не является обязательным.

(97) Pay-to-pubkey-hash является стандартным методом в биткойн-транзакциях и в транзакциях для всех других современных криптовалют, основанных на биткойн-технологии. Функция pay-to-script-hash встроена в программное обеспечение клиентского кошелька криптовалюты. Владелец криптовалюты может использовать программное обеспечение клиентского кошелька, чтобы выбрать использование метода pay-to-pubkey-hash или pay-to-script-hash для создания транзакций.

(98) В соответствии с настоящим изобретением, в транзакционной сети СВЕМ разрешены только транзакции pay-to-script-hash. В отличие от биткойнов и всех других современных криптовалют, основанных на биткойн-технологии, это ограничение реализуется внутри исходных кодов СВЕМ, а не только внутри исходного кода программного обеспечения клиентского кошелька. Таким образом, разработчик СВЕМ может внедрять определенные правила во всех транзакциях, и это позволяет реализовать систему аутентификации учетных данных, связанных с подлинной личностью, для контроля всех транзакций. Система аутентификации связанных с подлинной личностью учетных данных предполагает использование специфических для пользователя учетных данных и адресов с мультиподписью для приема и отправки СВЕМ.

(99) В системе аутентификации связанных с подлинной личностью учетных данных, в транзакциях pay-to-script-hash используются только адреса с мультиподписью для приема и отправки СВЕМ. Каждый клиентский адрес с мультиподписью связан со сценарием, который включает в себя клиентский открытый ключ (который сгенерирован из клиентского кошелька) (307) и открытый ключ утверждения (который сгенерирован из одного из центральных серверов утверждения) (405) для создания и подписания транзакций. Следовательно, для каждой из транзакций pay-to-script-hash требуется по меньшей мере клиентский секретный ключ (308) и секретный ключ утверждения (406), чтобы сделать транзакцию действительной.

(100) Сценарий для транзакций pay-to-script-hash реализуется внутри исходных кодов СВЕМ, а не только внутри клиентских кошельков. Это позволяет сценарию обеспечивать выполнение требований одного или нескольких секретных ключей утверждения (406) от одного или нескольких центральных серверов утверждения для инициализации и подписания всех транзакций. Поскольку предоставление секретных ключей утверждения может регулироваться через центральные серверы утверждения, никто не может создать какую-либо транзакцию pay-to-pubkey-hash или pay-to-script-hash, которая может обойти требования, нормы и/или правила, которые предварительно определены на центральных серверах утверждения.

(101) На фиг. 3 показана система аутентификации связанных с подлинной личностью учетных данных и схема двухсторонней подписи для генерации платежной транзакции с некоторым количеством монет, которые принадлежат пользователю и записаны по адресу с мультиподписью.

(102) Чтобы создать транзакцию pay-to-script-hash (218), клиентский кошелек (301) требует подписи (т.е. секретного ключа утверждения) (406) от одного из центральных серверов утверждения (401), чтобы получить разрешение. Этот запрос отправляется с вызовом API на центральные серверы утверждения для аутентификации (220). В случае отказа аутентификации может быть сгенерировано соответствующее сообщение об ошибке.

(103) Если учетные данные, предоставленные клиентским кошельком на центральные серверы утверждения (401), являются действительными (220, 409), и запрашиваемая транзакция не считается подозрительной в соответствии с предопределенными критериями (501, 502), она получает подпись от клиентского кошелька (т.е. клиентский секретный ключ) (308) и подписи (т.е. секретный(е) ключ(и) утверждения) (406, 411) от одного из центральных серверов утверждения для утверждения транзакции (410, 412).

(104) Сценарий pay-to-script-hash может быть модифицирован, чтобы требовать более одного клиентского открытого ключа и/или секретного ключа утверждения, что приводит к платежным транзакциям, требующим более одной подписи от одного или нескольких клиентов (либо отправителей, либо получателей) и/или от одного или нескольких учреждений утверждения для совершения транзакции. Кроме того, для повышения безопасности, для подписания ввода транзакции (410) и для подписания всей транзакции (412) могут быть использованы два разных секретных ключа утверждения.

(105) Настоящее изобретение обеспечивает выполнение всех транзакций, требующих по меньшей мере одного секретного ключа утверждения с центрального сервера утверждения в качестве подписи для осуществления транзакции. Кроме того, предоставление секретных ключей утверждения требует успешного подтверждения подлинности действительных учетных данных, предоставленных отправителем. Поскольку все действительные учетные данные связаны с индивидуальными адресами клиентских кошельков и принадлежат зарегистрированным пользователям, подлинные личности которых были проверены и сохранены в базе данных клиентской информации (фиг. 2), то только зарегистрированный пользователь с его/ее подлинной личностью, сохраненной в базе данных, может переводить деньги с его/ее адресов кошельков на другие адреса кошельков при представлении действительных учетных данных.

(106) Учетные данные обеспечивают ссылку для центрального органа управления, владеющего центральными серверами утверждения и базой данных клиентской информации, чтобы выявить подлинную личность отправителя или получателя СВЕМ, когда это необходимо. Поскольку информация о подлинной личности не требуется во всем процессе транзакции pay-to-script-hash, отправитель и получатель остаются псевдонимными.

(107) Центральный сервер утверждения может отклонять любые транзакции, которые не удовлетворяют централизованным критериям транзакции (501), сохраненным по меньшей мере на одном из центральных серверов утверждения (401). В частности, индивидуальные транзакции могут контролироваться с помощью предопределенных правил для выявления, регистрации и отправки сообщений о подозрительных транзакциях, которые могут быть вовлечены в незаконную деятельность, такую как отмывание денег. Любые подозрительные транзакции и идентификаторы ассоциированных отправителей и получателей могут сообщаться соответствующим государственным учреждениям для дальнейших действий. Таким образом, изобретение обеспечивает практическое решение текущих проблем несоответствия KYC/AML для биткойнов и различных альтернативных валют.

(108) Опционально, на этапе 502 могут быть определены клиентские критерии транзакции действительным зарегистрированным пользователем для ограничения его/ее собственных транзакций. Например, пользователь может установить критерий, который ограничивает максимальное количество монет, отправленных с его/ее адреса(ов) валюты в течение 2 4 часов. Это может свести к минимуму потерю его/ее монет, когда его/ее кошелек валюты похищен или взломан.

(109) Затем транзакция транслируется в сеть узлов (214) для подтверждения (305). После того, как транзакция сгенерирована, она отправляется в транзакционную сеть для обработки и должна быть включена в блок блокчейна, прежде чем стать легитимной. Узлы принимают блок только в том случае, если все транзакции в нем действительны (т.е. надлежащим образом подписаны) и еще не потрачены. Узлы выражают принятие блока, работая над созданием следующего блока в цепочке, используя хэш принятого блока как предыдущий хеш.

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

(111) Уникальными функциями схемы, представленной на фиг. 1 - фиг. 3, являются:

- разрешение создания только адресов с мультиподписью (313) в качестве действительных адресов валюты (314);

- разрешение создания только транзакций, использующих адреса с мультиподписью (313) для отправки и получения монет (321);

- разрешение создания только транзакций в формате pay-to-script-hash или любом другом совместимом формате (218); (311);

- разрешение создания только транзакций, каждая из которых требует по меньшей мере два секретных ключа в качестве подписей (308, 406);

- ограничение одного из этих секретных ключей (308, 406), чтобы он являлся секретным ключом утверждения (4 06) из одного из центральных серверов утверждения (401);

- ограничение остальных секретных ключей (308, 406), чтобы они являлись клиентскими секретными ключами (308), которые зашифрованы и сохранены в клиентском(их) кошельке(ах) (301);

- ограничение только допустимых зарегистрированных пользователей (109), чтобы создавать действительные учетные данные (111); (112);

- ограничение только пользователей, которые имеют действительные учетные данные (111), чтобы генерировать один или несколько действительных адресов валюты с мультиподписью (313) для приема монет путем верификации представленных учетных данных (111), через один из центральных серверов утверждения (401); (319, 407);

- ограничение только пользователей, которые имеют действительные учетные данные (111), один или несколько действительных адресов валюты с мультиподписью (313) и соответствующие клиентские секретные ключи (308, 309), чтобы создавать одну или несколько действительных транзакций; (220, 320, 409);

- ограничение только пользователей, которые имеют действительные учетные данные (111), чтобы получать один или несколько секретных ключей утверждения (406, 411) с одного из центральных серверов утверждения (401) для подписания одной или нескольких транзакций (410, 412) путем верификации (220, 320, 409) представленных учетных данных (111) через один из центральных серверов утверждения (401);

- ограничение только пользователей, которые получили один или несколько секретных ключей утверждения (406, 411) от одного из центральных серверов утверждения (401), чтобы создавать действительные транзакции путем верификации (220, 320, 409) представленных учетных данных (111) посредством одного из центральных серверов утверждения (401), и, следовательно, ограничение только пользователей, которые имеют действительные учетные данные (111), чтобы создавать действительные транзакции;

- связывание индивидуальных учетных данных (111, 112, 113, 114) с подлинными личностями пользователей (105); (фиг. 1);

- использование индивидуальных учетных данных (фиг. 1, 111) для отслеживания подлинных личностей их владельцев (105); (116);

- связывание индивидуальных адресов с мультиподписью (313, 314) с учетными данными пользователей (111); (фиг. 2);

- использование индивидуальных адресов с мультиподписью (313) для отслеживания (118) учетных данных (111) их владельцев (фиг. 2) и, следовательно, использование учетных данных (111) для отслеживания (116) подлинных личностей (105) владельцев (фиг. 1);

- использование индивидуальных транзакций для отслеживания адресов с мультиподписью (313) отправителей и получателей (фиг. 3), затем использование адресов с мультиподписью (313) для отслеживания (118) учетных данных (111) отправителей и получателей (фиг. 2) и, наконец, использование учетных данных (фиг. 1, 111) для отслеживания (116) подлинных личностей (105) отправителей и получателей;

- обеспечение возможности прослеживания и отслеживание (116) подлинных личностей отправителей (фиг. 1, 105) и получателей во всех действительных транзакциях (фиг. 3), поскольку только пользователи, которые имеют действительные учетные данные (111), могут создавать действительные адреса с мультиподписью (фиг. 2) и создавать действительные транзакции (фиг. 3).

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

(113) На фиг. 4 представлена схема системы в соответствии с настоящим изобретением. Система представляет собой устройство клиент-сервер, в котором сервер является одним или несколькими центральными серверами утверждения. На схеме показана примерная компьютерная сеть ("система 400"), в которой может быть осуществлена одна или несколько реализаций настоящего изобретения. В некоторых реализациях, система 400 может включать в себя один или несколько серверов 401. Сервер(ы) 401 может (могут) быть сконфигурирован(ы) для связи с одной или несколькими клиентскими вычислительными платформами 414/415 в соответствии с архитектурой клиент/сервер. Пользователи могут получить доступ к системе 400 через клиентскую(ие) вычислительную(ые) платформу(ы) 414/415. Сервер(ы) 401 и клиентская(ие) вычислительная(ые) платформа(ы) 414/415 могут быть сконфигурированы для исполнения считываемых компьютером инструкций.

(114) В некоторых реализациях, сервер(ы) 401, клиентская(ие) вычислительная(ые) платформа(ы) 414/415 и/или внешний(е) ресурс(ы) 418 могут быть функционально связаны через одну или несколько электронных линий связи. Например, такие электронные линии связи могут быть установлены, по меньшей мере частично, через сеть, такую как Интернет и/или другие сети. Понятно, что это не предназначено для ограничения, и что объем настоящего раскрытия включает в себя реализации, в которых сервер (ы) 401, клиентская(ие) вычислительная (ые) платформа(ы) 414/415 и/или внешний(е) ресурс(ы) 418 могут быть функционально связанными через некоторые другие средства связи.

(115) Данная клиентская вычислительная платформа 414/415 может включать в себя один или несколько процессоров, сконфигурированных для выполнения считываемых компьютером инструкций. Считываемые компьютером инструкции могут быть сконфигурированы так, чтобы позволить специалисту или пользователю, связанным с данной клиентской вычислительной платформой 414/415, взаимодействовать с системой 400 и/или внешним(и) ресурсом(ами) 418 и/или предоставлять другие функции, отнесенные здесь к клиентской(им) вычислительной(ым) платформе(ам) 414/415. В качестве неограничивающего примера, данная клиентская вычислительная платформа 414/415 может включать в себя один или несколько из настольного компьютера, портативного компьютера, карманного компьютера, планшетной компьютерной платформы, NetBook, смартфона, игровой приставки и/или других вычислительных платформ.

(116) Внешний(е) ресурс(ы) 418 может (могут) включать в себя источники информации, внешние объекты, участвующие в системе 400, и/или другой(ие) ресурс(ы). В некоторых реализациях, некоторые или все функциональные возможности, отнесенные здесь к внешнему(им) ресурсу(ам) 418, могут быть предоставлены ресурсом(ами), включенным(и) в систему 400.

(117) Сервер(ы) 401 и/или клиентская(ие) вычислительная(ые) платформа(ы) 414/415 могут включать в себя электронное хранилище 419, один или несколько процессоров 420 и/или другие компоненты. Сервер(ы) 401 может (могут) включать в себя линии связи или порты, чтобы обеспечивать обмен информацией с сетью и/или другими вычислительными платформами. Иллюстрация сервера(ов) 401 на фиг. 1 не является ограничивающей. Сервер(ы) 401 может (могут) включать в себя множество аппаратных средств, программного обеспечения и/или встроенного программного обеспечения, работающих вместе, чтобы обеспечивать функциональность, отнесенную здесь к серверу(ам) 401. Например, сервер(ы) 401 может (могут) быть реализован(ы) облаком вычислительных платформ, работающие вместе как сервер(ы) 401.

(118) Электронное хранилище 419 может содержать некратковременные носители хранения данных, которые электронным образом хранят информацию. Электронные носители хранения электронного хранилища 419 могут включать в себя одно или оба из системного хранилища, которое предусмотрено как одно целое (то есть, по существу, несъемное) с сервером(ами) 401, и/или съемного хранилища, которое съемным образом может соединяться с сервером(ами) 401 через, например, порт (например, порт USB, порт FireWire и т.д.), или накопителя (например, дисковода и т.д.). Электронное хранилище 419 может содержать один или несколько оптически считываемых носителей хранения данных (например, оптические диски и т.д.), магнитно считываемых носителей хранения данных (например, магнитную ленту, магнитный жесткий диск, накопитель на гибких дисках и т.д.), носителей хранения на основе электрического заряда (например, EEPROM, RAM и т.д.), твердотельных носителей (например, флэш-накопитель и т.д.) и/или других электронным образом считываемых носителей информации. Электронное хранилище 419 может включать в себя один или несколько виртуальных ресурсов хранения (например, облачное хранилище, виртуальную частную сеть и/или другой(ие) ресурс(ы) виртуального хранилища). Электронное хранилище 419 может хранить программные алгоритмы, информацию, определяемую процессором 420, информацию, полученную от сервера(ов) 401, информацию, полученную от клиентской(их) вычислительной(ых) платформы (платформ) 414/415, и/или другую информацию, которая позволяет серверу(ам) 401 функционировать так, как описано в настоящем документе.

(119) Процессор 420 может быть сконфигурирован для обеспечения возможностей обработки информации на сервере(ах) 401. Таким образом, процессор 420 может включать в себя один или несколько цифровых процессоров, аналоговый процессор, цифровую схему, предназначенную для обработки информации, аналоговую схему, предназначенную для обработки информации, конечный автомат и/или другие механизмы для электронной обработки информации. Хотя процессор 420 показан на фиг. 1 как единое целое, это сделано только для иллюстративных целей. В некоторых реализациях процессор 420 может включать в себя множество блоков обработки. Эти блоки обработки могут быть физически расположены внутри одного и того же устройства, или процессор 420 может представлять функциональность обработки множества устройств, работающих в координации. Процессор 420 может быть сконфигурирован для считываемых компьютером инструкций и/или компонентов считываемых компьютером инструкций с помощью программного обеспечения; аппаратных средства; встроенного программного обеспечения; некоторой комбинации программного обеспечения, аппаратных средств и/или встроенного программного обеспечения; и/или других механизмов для конфигурирования возможностей обработки на процессоре 420. Используемый здесь термин "компонент" может относиться к любому компоненту или набору компонентов, которые выполняют функциональность, относящуюся к компоненту. Это может включать в себя один или несколько физических процессоров при выполнении считываемых процессором инструкций, считываемые процессором инструкции, схемы, аппаратные средства, носители хранения данных или любые другие компоненты.

(120) Клиент 414/415 и сервер 401 могут содержать ресурсы обработки данных, которые могут быть реализованы с использованием специально предназначенных компонентов или специализированных схем FPGA или ASIC. Эти вычислительные ресурсы подходят для хранения и выполнения программного обеспечения, реализующего этапы способа в соответствии с настоящим изобретением.

(121) Центральный сервер утверждения (401) обрабатывает запросы регистрации клиентов (фиг. 1), клиентские адреса криптовалюты (фиг. 2), запросы обновления аккаунта клиента и транзакции с криптовалютой (фиг. 3). Таким образом, центральный сервер (401) утверждения взаимодействует с базой данных клиентской информации (404) (например, Пользователь X: юридическое имя, дата рождения, домашний адрес, контактный адрес, учетные данные, адрес криптовалюты, критерии транзакции), и базой данных транзакций (413) (например, Транзакция Y: идентификатор транзакции, адреса криптовалюты отправителя и получателя, количество монет в транзакции, время транзакции и IP-адреса клиентских кошельков отправителя и получателя).

(122) Подлинные личности владельцев индивидуальных адресов валюты хранятся в базе данных клиентской информации (фиг. 1, 115). Это соответствует нормативному требованию "знай своего клиента" и позволяет использовать систему в качестве платежной системы для коммерческой деятельности. Однако такая информация недоступна для общественности, чтобы поддерживать псевдонимное свойство СВЕМ и их транзакционной сети.

(123) В случае хищения денег, похититель(и) или хакер(ы) могут быть легко прослежены путем получения легальной(ых) идентичности(ий) получателя(ей) из базы данных клиентской информации (115). Поэтому реализация системы предотвращает хищение монет СВЕМ.

(124) Из-за псевдонимного или анонимного характера биткойнов и альтернативных криптовалют, основанных на биткойн-технологии, баланс монет индивидуальных владельцев монет не может прослеживаться только анализом публичных записей транзакций, сохраненных в блокчейне. Кроме того, по замыслу, когда кто-либо тратит только часть монет, записанных на определенном адресе валюты, количество неизрасходованных монет записывается по вновь сгенерированному адресу валюты. Через анализ блокчейна, для третьей стороны потребовались бы интенсивные вычисления, чтобы отслеживать, где принятая сумма монет в конечном счете участвовала в транзакции и по каким адресам она записана.

(125) В соответствии с настоящим изобретением количество монет, принадлежащих действительному зарегистрированному пользователю, является полностью прослеживаемым и может отслеживаться центральным органом управления посредством анализа записей транзакций в базе данных транзакций (413). Помимо возможности связывания индивидуальных адресов валюты с их владельцами, этому уникальному свойству настоящей системы способствует запись неизрасходованных монет (если таковые имеются) на адресе валюты, с которого монеты только что были отправлены/потрачены. Другими словами, количество монет, зарегистрированных на адресе валюты, станет равным нулю только после того, как все монеты, которые ранее были отправлены на этот адрес, были отправлены/потрачены (322). Это уникальное свойство не только упрощает сторонний процесс для прослеживания и сопровождения передач собственности на монеты криптовалюты путем анализа записей транзакций в блокчейне, но также обеспечивает возможность применения системы к финансовой и банковской деятельности, в частности, такой, для которой требуется сторонний аудит.

(126) Центральный сервер (401) подтверждения осуществляет связь с одним или несколькими клиентами (414, 415), реализующими клиентские кошельки (416, 417).

(127) Пользователь кошелька запрашивает транзакцию, которая должна быть подтверждена одним или несколькими центральными серверами утверждения (401). Поэтому клиенты соединены с серверами (401) через подходящую двунаправленную линию связи, такую как GSM, UMTS, DSL.

(128) Изобретение может включать в себя средства для автоматической идентификации и прекращения любых подозрительных или неавторизованных транзакций. Кроме того, настоящее изобретение предотвращает (i) использование СВЕМ для отмывания денег и (ii) хищение СВЕМ. Таким образом, настоящее изобретение позволяет СВЕМ и их транзакционной сети соблюдать политику и правила AML и (KYC). Например, PATRIOT OFFICER от GlobalVision Systems, усовершенствованная интеллектуальная, основанная на правилах система BSA/AML/ATF может применяться для эффективной автоматизации рабочего потока BSA/AML/ATF посредством мониторинга, фильтрации, обнаружения, оповещения, расследования и анализа подозрительных действий всех транзакций.

(129) Изобретение обеспечивает полезный результат, который повышает безопасность и отслеживаемость транзакций. Этот результат также является конкретным и ощутимым, поскольку статистические измерения показывают улучшенную безопасность и меньшее количество попыток кражи СВЕМ. Следовательно, изобретение обеспечивает полезный, конкретный и ощутимый результат. Машинный или трансформационный тест выполняется тем фактом, что улучшенная безопасность, достигаемая посредством настоящего изобретения, требует генераций адресов с мультиподписью и транзакций "pay-to-script-hash" и их конкретных модификаций, реализаций и приложений, тем самым трансформируя данные, ассоциированные с криптовалютами. Ввиду конкретной схемы реализации, данная идея не является абстрактной.

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

(131) Хотя изобретение, представленное здесь, было изображено, описано и определено со ссылкой на конкретные предпочтительные варианты осуществления, такие ссылки и примеры реализации в вышеприведенной спецификации не подразумевают какого-либо ограничения изобретения. Однако будет очевидно, что в него могут быть внесены различные модификации и изменения без отклонения от более широкого объема технической концепции. Представленные предпочтительные варианты осуществления являются только примерными и не исчерпывают объем технической концепции, представленной в настоящем документе.

(132) Соответственно, объем защиты не ограничивается предпочтительными вариантами осуществления, описанными в спецификации, но ограничивается только прилагаемыми пунктами формулы изобретения.

Изобретение относится к области вычислительной техники для персональной идентификации и верификации. Технический результат заключается в повышении безопасности выполнения транзакций. Изобретение также позволяет включать дополнительные модули для мониторинга всех транзакций и выявления тех, которые потенциально связаны с незаконной деятельностью, а также для включения критериев, определенных центральным руководящим органом или пользователями CBEM для регулирования или ограничения транзакций. В результате настоящее изобретение обеспечивает практическое решение проблем, связанных с «знай своего клиента», борьбой с отмыванием денег и кражей криптовалюты при сохранении конфиденциальности пользователя. Более того, настоящее изобретение может быть принято или изменено центральными банками или другими финансовыми учреждениями для выпуска своих собственных цифровых валют, которые регулируются центральным руководящим органом и поддерживаются платежной системой с распределенной бухгалтерской книгой. 3 н. и 7 з.п. ф-лы, 4 ил.

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

обеспечения, используя вычислительный сервер, доступа одному или нескольким потенциальным или существующим пользователям валюты (103); и

обеспечения, используя вычислительный сервер, регистрационного интерфейса (102) для одного или нескольких потенциальных пользователей валюты для регистрации пользовательского аккаунта, требующего аутентификации (104), причем способ отличается тем, что он содержит этапы:

запрашивания, используя вычислительный сервер, представления документов для подтверждения подлинной личности регистранта (105);

верификации, используя вычислительный сервер, подлинной личности регистранта (106);

отклонения, используя вычислительный сервер, создания аккаунта для регистрантов, не прошедших верификацию подлинной личности (107);

создания, используя вычислительный сервер, персонального аккаунта (108) для индивидуальных успешных регистрантов (109) с успешной верификацией подлинной личности (110);

разрешения, используя вычислительный сервер, успешному регистранту (109) создавать учетные данные (111), которые содержат ассоциированную аутентификацию (112);

сохранения (116), используя вычислительный сервер, всей представленной информации в базе данных клиентской информации (115);

отправки (117), используя вычислительный сервер, учетных данных к центральным серверам утверждения (401);

использования центральных серверов утверждения (401) для генерирования адреса валюты с мультиподписью для использования в транзакциях; и

отображения и сохранения (118), используя центральные серверы утверждения (401), адреса(ов) валюты с мультиподписью, учетных данных и подлинной личности индивидуальных регистрантов в базе данных,

при этом использование центральных серверов утверждения (401) для генерирования адреса валюты с мультиподписью включает в себя:

- получение одним из центральных серверов утверждения (401) учетных данных от клиентского кошелька,

- проверку одним из центральных серверов утверждения (401) действительности учетных данных путем сопоставления учетных данных с действительными и активными учетными данными, хранящимися в базе данных, и

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

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

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

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

5. Способы по п. 1, в которых (i) подлинные личности владельцев индивидуальных адресов валюты хранятся в базе данных клиентской информации, (ii) любые адреса валюты, которые не сгенерированы путем представления действительных учетных данных на один из центральных серверов утверждения (401), являются недействительными и не способны принимать какие-либо монеты, и (iii) только действительные зарегистрированные пользователи имеют действительные учетные данные (112).

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

7. Способ по п. 1, отличающийся тем, что он дополнительно содержит этап шифрования учетных данных (114).

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

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

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