СПОСОБЫ И СИСТЕМЫ ДЛЯ ОСНОВАННОЙ НА ТОКЕНАХ ПРИВЯЗКИ ФИЗИЧЕСКИХ ОБЪЕКТОВ В СРЕДЕ РАСПРЕДЕЛЕННОГО РЕЕСТРА Российский патент 2023 года по МПК H04L9/32 G06Q10/87 G06Q30/18 

Область изобретения

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

Предпосылки создания изобретения

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

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

Примерами являются промышленные рабочие места, регулируемые официальными регуляторами, такими как FDA (управление по продовольствию и лекарствам США), и/или сертифицированные, например, согласно GMP (качественная производственная практика), GLP (качественная лабораторная практика), GCP (качественная клиническая практика) или DIN ISO или другие подобные стандарты и правила. Каждая из этих регулируемых сред требует, прежде всего, аудиторского следа и контролируемых технологий. Другим примером является прослеживаемость высокоценных продуктов, таких как промышленные запасные части, для подтверждения аутентичности и предполагаемого использования этих деталей на вторичных рынках.

Для ограничения контрафакции и обеспечения цепочки поставок и целостности рабочего процесса, включая опознавание и проверку аутентичности продуктов в рабочем процессе, разные отрасли промышленности разработали несколько разных защитных мер и решений идентификации. Широко используемые меры защиты включают в себя добавление к продукту так называемого признака защиты, причем признак довольно сложно подделать. Например, голограммы, цветопеременные чернила, защитные нити и внедренные магнитные частицы являются известными признаками защиты, которые сложно воспроизвести фальсификатору. В то время как некоторые из этих признаков защиты являются "открытыми", то есть могут быть легко увидены или иным образом опознаны пользователем продукта, другие признаки защиты являются "скрытыми", то есть они спрятаны и могут быть обнаружены только посредством использования специальных приборов, таких как источники ультрафиолетового света, спектрометры, микроскопы или детекторы магнитного поля или даже более сложное криминалистическое оборудование. Примерами 25 скрытых признаков защиты являются, прежде всего, надпечатки люминесцентными чернилами или чернилами, которые видны только в инфракрасной части электромагнитного спектра, но не в видимой части, особые составы материала и магнитные пигменты.

Особая группа признаков защиты, которые, прежде всего, используются в криптографии, известна как "физические неклонируемые функции" (PUFs). Физическая неклонируемая функция (PUF) является физическим объектом, который воплощен в физической структуре и его можно просто оценить, но сложно предсказать даже для взломщика с физическим доступом к PUF. PUFs зависят от уникальности своей физической микроструктуры, которая типично включает в себя случайный компонент, который, по существу, уже присутствует физическом объекте или явным образом внедрен в физический объект или сгенерирован в физическом объекте во время его изготовления и который, по существу, является неконтролируемым и непредсказуемым. Соответственно, даже PUFs, произведенные по абсолютно такому же производственному процессу, отличаются, по меньшей мере, своим случайным компонентом и, таким образом, могут быть различены. В то время как в большинстве случаев PUFs являются скрытыми признаками, это не является ограничением, и возможны также открытые PUFs. Кроме того, PUFs являются идеальными для предоставления возможности пассивной (то есть без активного транслирования) идентификации физических объектов.

PUFs известны, прежде всего, в связи с их реализацией в интегральных электронные схемах посредством минимальных неизбежных вариаций в произведенных на микросхеме микроструктурах в заданных соотнесенных с процессом допусках и, прежде всего, используемых для получения из них криптографических ключей, например в микросхемах для смарт-карт или других соотнесенных с безопасностью микросхем. Пример разъяснения и применения таких соотнесенных с микросхемами PUFs раскрыт в статье "Background on Physical Unclonable Functions (PUFs) [Предпосылки физически неклонируемых функций ((PUFs)]", Virginia Tech, Department of Electrical and Computer Engineering, 2011, которая доступна в Интернете по ссылке: http://rijndael.ece.vt.edu/puf/background.html.

Однако известны также другие типы PUFs, такие как случайное распределение волокон в используемой в качестве субстрата для изготовления банкнот бумаге, причем распределение и ориентация волокон могу быть обнаружены специальными детекторами и использованы в качестве признака защиты банкноты. Для оценки PUF используется так называемая схема проверки аутентичности "вызов-отклик". "Вызов" является приложенным к PUF физическим воздействием, а "отклик" является реакцией на воздействие. Отклик зависит от неконтролируемой и непредсказуемой природы физической микроструктуры и, следовательно, может быть использован для проверки аутентичности PUF и, следовательно, также физического объекта, часть которого образует PUF. Особый вызов и соответствующий ему отклик вместе образуют так называемую "пару вызов-отклик" (CRP).

Основанные на использовании PUFs для проверки аутентичности продуктов системы и способы защиты от фальсифицирования описаны в следующих Европейских патентных заявках: EP 3 340 213 A1, EP 3 340 212 A1, EP 5 18170044.4, и EP 18170047.7, каждая из которых включена в полном объеме в данную заявку посредством ссылки. Способы и системы для автоматического распознавания объекта и соотнесенные с ними системы и способы защиты от фальсифицирования раскрыты в Европейской патентной заявке EP 18214512.8, которая также включена в полном объеме в данную заявку посредством ссылки.

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

Недавно была разработана технология блокчейна, причем блокчейн является распределенным реестром в виде содержащей множество блоков данных распределенной базы данных, который поддерживает непрерывно расширяющийся список записей данных и защищен от фальсифицирования и изменения посредством криптографических средств. Известным применением технологи блокчейна является виртуальная валюта "Биткойн", используемая для денежных операций в Интернете. Другая известная блокчейн-платформа разработана, например, проектом Ethereum. По существу, блокчейн может быть описан как децентрализованный протокол для записи сделок между контрагентами, который явно фиксирует и запоминает любые изменения в своей распределенной базе данных и хранит их "вечно", то есть до тех пор, пока существует блокчейн. Хранение информации в блокчейне включает в себя цифровое подписание подлежащей хранению в блоке блокчейна информации. Кроме того, поддержание блокчейна включает в себя процесс, называемый майнинг блокчейна", причем так называемые "майнеры", являясь частью инфраструктуры блокчейна, проверяют подлинность и запечатывают каждый блок, так что содержащаяся в нем информация сохраняется "вечно", и блок больше не может быть изменен.

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

Прежде всего, в связи с технологией блокчейна была введена токенизация важных данных, то есть процесс замещения чувствительного элемента данных на называемый токеном нечувствительный эквивалент, который не имеет внешнее или пригодное для использования значение или величину, прежде всего для применений в финансовой индустрии и в связи с так называемыми смарт контрактами. "Смарт контракт" – это компьютерный протокол, предназначенный для цифрового упрощения, или проверки подлинности, или принудительного выполнения переговоров или выполнения контракта. Смарт контракты позволяют совершать заслуживающие доверия сделки без третьих сторон. Эти сделки являются прослеживаемыми и необратимыми. Показательная открытая цифровая платформа, которая основана на токенизации и смарт контрактах, известна как платформа Etherium (https://www.ethereum.org), которая позволяет, прежде всего, создавать основанную на платформе цифровую валюту.

Используемый этой платформой технический стандарт токена известен как стандарт токена "ERC 20" (ср. https://theethereum.wiki/w/index.php/Ethereum Based Tokens (основанные на Ethereum токены)\ https://theethereum.wiki/w/index.php/ERC20 Token Standard (Стандарт токена)). Однако концепции токенов и смарт контрактов не ограничиваются платформой Etherium, а наоборот, являются более общими концепциями, которые могут быть использованы для других платформ или применений.

Краткое изложение сущности изобретения

Предметом настоящего изобретения является разработка решения для основанной на токене привязки физического объекта, такого как продукт, в среде распределенного реестра.

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

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

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

Предлагаемый способ также включает в себя: (iii) передачу данных запроса на проверку достоверности несертифицированного токена через фреймворк токена к одной или нескольким системам сертификации, причем данные запроса на проверку достоверности несертифицированного токена представляют информацию, указывающую на создание несертифицированного токена в связи с данными идентификации объекта и запрос на проверку достоверности токена, (iv) получение данных сертификации токена, представляющих сертификацию прежде несертифицированного токена посредством по меньшей мере одной из систем сертификации, и (v) сохранение данных сертификации в: (v-1) несертифицированном токене для преобразования несертифицированного токена в сертифицированный токен, сертифицированный посредством и с учетом каждой из сертификаций, представленных данными сертификации токена, или (v-2) другом полученном из несертифицированного токена токене и посредством этого сертифицирующим другой токен с учетом каждой из сертификаций, представленных данными сертификации токена, и (vi) сохранение сертифицированного токена и/или метаданных, соотнесенных с данными идентификации объекта, в защищенном хранилище данных, предпочтительно в цифровом бумажнике.

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

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

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

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

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

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

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

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

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

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

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

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

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

Четвертый аспект изобретения направлен на реализуемый на компьютере способ сертификации токена, включающему в себя данные идентификации объекта, причем способ содержит: (i) получение или генерирование и сохранение данных идентификации эталонного объекта, соотнесенных с особым физическим эталонным объектом и включающих в себя по меньшей мере одно криптографическое значение хеш-функции в виде устойчивого к конфликтам виртуального представления эталонного физического объекта, (ii) получение от запрашивающей системы через фреймворк токена данных запроса на проверку достоверности несертифицированного токена, представляющих (ii-1) данные идентификации объекта, соотнесенные с особым физическим объектом и включающие в себя по меньшей мере одно криптографическое значение хеш-функции в виде устойчивого к конфликтам виртуального представления физического объекта, и (ii-2) информацию, указывающую на создание несертифицированного токена в связи с данными идентификации объекта и запрос на проверку достоверности несертифицированного токена, (iii) корреляцию, например сравнение, данных идентификации объекта с данными идентификации эталонного объекта в отношении заданного критерия соответствия, и (iv) если согласно критерию соответствия данные идентификации объекта соответствуют данным идентификации эталонного объекта, передачу через фреймворк токена данных сертификации токена, представляющих сертификацию прежде несертифицированного токена, запрашивающей системе (иначе передача данных сертификации пропускается).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любая упомянутая здесь компьютерная программа может быть, прежде всего, реализована в виде долговременной запоминающей среды, на которой хранятся одна или более программ для выполнения соответствующего, реализованного компьютерной программой способа. Предпочтительно, это носитель данных, такой как CD, DVD или модуль флеш-памяти. Это может быть предпочтительным, если компьютерный программный продукт предназначен для продажи в виде индивидуального продукта, независимо от процессорной платформы, на которой должны выполняться одна или более программ. В другом исполнении компьютерный программный продукт обеспечен в виде файла на блоке обработки данных, прежде всего на сервере, и может быть загружен через информационное соединение, например Интернет или специализированное информационное соединение, такое как личная или локальная сеть.

Если в настоящем описании и в пунктах формулы изобретения используется термин "включающий в себя", он не исключает другие элементы или шаги. Если используется неопределенный или определенный артикль при ссылке на единственное число имени существительного, например "a" или "an", "the", то это включает с себя множественное множество таких имен существительных, если только это не установлено иначе.

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

Краткое описание чертежей

Другие преимущества, признаки и применения настоящего изобретения приведены в следующем подробном писании и прилагаемых фигурах, причем:

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

Фиг. 2 схематически показывает служащую примером цепочку A поставок, соотнесеную со способом токенизации физического объекта согласно вариантам осуществления настоящего изобретения,

Фиг. 3 показывает блок-схему, иллюстрирующую служащий примером способ токенизации физического объекта согласно вариантам осуществления настоящего изобретения,

Фиг. 4 схематически показывает набор из двух служащих примером цепочек A и B поставки, причем цепочка A поставок соотнесена со способом токенизации первого физического объекта PO1 в первой экосистема E1, и цепочка B поставок соотнесена со способом токенизации второго физического объекта PO2 во второй, другой экосистеме E2 согласно вариантам осуществления настоящего изобретения,

Фиг. 5 показывает блок-схему, иллюстрирующую служащий примером способ обеспечения основанного на токенах взаимодействия между двумя экосистемами E1 и E2 согласно фиг. 4 согласно вариантам осуществления настоящего изобретения,

Фиг. 6 схематически иллюстрирует связь двух служащих примером цепочек A и B поставок, причем цепочка A поставок относится к способу токенизации первого физического объекта PO1 в первой экосистема E1, и цепочка B поставок относится к способу токенизации второго физического объекта PO2 во второй, другой экосистеме E2 согласно вариантам осуществления настоящего изобретения,

Фиг. 7 показывает блок-схему, иллюстрирующую служащий примером способ обеспечения основанной на токенах связи данных между двумя экосистемами E1 и E2 согласно фиг. 6 согласно вариантам осуществления настоящего изобретения,

Фиг. 8А, 8Б и 8В в сочетании показывают другую блок-схему, иллюстрирующую взаимодействие способов согласно фиг. 2-7 в обобщенном виде, и

Фиг. 9 показывает служащие примером структуры и содержание имущественного токена и утилитарного токена, пригодных для использования в связи с описанными здесь способами.

Подробное описание вариантов осуществления изобретения

В общем, участники показанной на фиг. 1 основанной на токенах экосистемы 1 могут включать в себя (i) самые разные устройства 2, например считыватели PUF для считывания одной или более PUFs физического объекта, (ii) других участников 3, таких как другие устройства, люди, организации или интерфейсы прикладных программ (API), (ii) сертифицирующие организации 4 с их соответствующими системами сертификации, (iii) шлюзы к другим основанным на токенах экосистемам 5, например валютным экосистемам, и (iv) один или несколько распределенных реестров 6, таких как блокчейны, которые могут принадлежать к одной или более разным основанным на токенах экосистемам.

Связь может быть основана, прежде всего, на технологии Интернета и типично осуществляться через Интернет или другие коммуникационные сети. На низких уровнях 7, 8 находятся хорошо известные стеки протоколов, такие как стеки протоколов, использующие низкоуровневые транспортные технологии, такие как Ethernet, DSL, сотовая беспроводная связь, SONET/SDH и т.п. и TCP/IP или другие хорошо известные протоколы на транспортных слоях (третий и четвертый слои модели OSI). В дополнение в качестве другого коммуникационного слоя добавлен фреймворк 9 токена, которые делает возможной основанную на токенах связь между устройствами и другими участниками основанной на токенах экосистемы. Прежде всего, фреймворк 9 токена может определять и требовать особый формат данных для подлежащих использования с ним токенов и может в дополнение иметь функцию шлюза, на основе которой полученная запрошенная токеном информация может направляться, в смысле маршрутизации, к подходящему другому участнику, который фактически может обеспечивать информацию, причем такая маршрутизация выполнена основанной на доступной фреймворку токена информации.

В нижеследующем описании других фигур ссылка дается на описанные выше в связи с фиг. 1 элементы.

Согласно фиг. 2 соотнесенная с первой экосистемой E1 служащая примером первая цепочка A поставок имеет первый соотнесенный с ней распределенный реестр, например блокчейн B1. Цепочка A поставок может быть соотнесенной с отслеживанием физического объекта PO1 в виде мясных продуктов, произведенных в первом узле A-1 экосистемы E1, таком как, например, производственная площадка 3a по производству мяса, например, ферма. Перед поставкой мясного продукта вдоль цепочки A поставок, производственная площадка 3a применяет, например, один или более считывателей 2a PUF для обнаружения одной или более PUFs, прикрепленных или иным образом соединенных или внедренных в мясной продукт PO1 для генерирования данных идентификации объекта и их обработки с целью генерирования представляющего его токена согласно описанному ниже в связи с фиг. 3 способу. Конкретно, представляющий данные идентификации объекта токен сгенерирован и сохранен или принужден к сохранению в соотнесенным с первой экосистемой E1 блокчейне B1.

Аналогичным образом, когда мясной продукт был транспортирован вдоль цепочки A поставок к другому узлу A-2 (в показанном примере имеются всего только три узла, хотя обычно могут быть любое число узлов) происходит обследование продукта в узле A-2 с использованием аналогичной технологии для подтверждения аутентичности продукта. Эта проверка аутентичности может быть, например, выполнена участником 3b согласно способам и с устройствами, описанными в любой из процитированных в разделе «Предпосылки создания» европейских патентных заявок. Затем узел A-2 может сохранять или вызывать сохранение результатов проверки аутентичности вместе с метаданными, такими как время и место проверки аутентичности, в блокчейн B1.

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

Согласно фиг. 3 служащий примером способ 100 ("случай 1") токенизации физического объекта в единственной основанной на токенах экосистеме, например экосистеме E1, включает в себя включающие в себя начальную фазу шаги 105 и 110, где сертифицируются вносящие вклад в способ устройства или другие участники. В этом примере подлежащий токенизации физический объект PO включает в себя M PUFs с M∈N и, следовательно, могут быть до M считывателей PUF, используемых для считывания соответствующих PUFs. Кроме того, имеются N∈N других участников, например операторов соответствующих считывателей PUF, вносящих вклад в процесс токенизации. Во время начальной фазы каждый из участников, включая считывателей PUF, посылает на шаге 105 токенизированный запрос системе 4 сертификации приписанной к экосистеме E1 сертифицирующей организации для получения соответственно на шаге 110 сертификации и, таким образом, становясь сертифицированным участником. Это является предпосылкой возможности принятия участия в качестве участника в последующем соотнесенным с физическим объектом процессе токенизации.

В следующем шаге 115, который запускает вторую фазу способа 100, одна или более PUFs физического объекта PO1 сканируются посредством соответствующего считывателя PUF, используемого соответствующими действующими в качестве участников людьми/организациями. Это сканирование может быть выполнено, например, согласно способам и с помощью устройств, описанных в любой из упоминавшихся в разделе «Предпосылки создания» европейских патентных заявок. Этот процесс сканирования имеет результатом уникальные соотнесенные с физическим объектом PO1 данные идентификации, прежде всего, в устойчивом к коллизиям и, предпочтительно, имеющем цифровую подпись хеш-коде (также называемом здесь "секретом объекта"), представляющем идентификатор физического объекта.

В следующем шаге 120 генерируется несертифицированный токен, который, прежде всего, может называться несертифицированным имущественным токеном. Этот несертифицированный токен является структурой данных, задаваемой согласно специфическому, предпочтительно стандартизованному формату данных (формату токена), например, показанному на фиг. 9(А) формату токена. В дополнение несертифицированный токен типично будет содержать добавочную информацию, такую как (i) указание на тип токена, (ii) идентификацию объекта или имущества, служащую в качестве идентификатора (ID) токена, (iii) идентификатор используемого фреймворка токена, прежде всего, если в экосистеме E1 или в связи с экосистемой E1 имеются несколько разных фреймворков, (iv) открытый ключ PKI-системы владельца токена, например объекта, который его создал, который одновременно может служить в качестве удостоверения личности владельца, и, предпочтительно зашифрованную, другую соотнесенную с физическим объектом информацию, например, соответствующее количество, владелец, вид объекта, выполненный в связи с ним процесс и т.д., как показано на фиг. 9(А). Токен также включает в себя сертификаты для различных участников, которые были сертифицированы во время начальной фазы способа.

Затем несертифицированный токен на шаге 125 сохраняется в защищенном хранилище данных, предпочтительно в цифровом бумажнике, который привязан к выполняющей способ 100 системе, которая может, прежде всего, включать в себя одно или более устройств считывания PUF, используемых для сканирования объекта PO1. Кроме того, на шаге 130 несертифицированный токен направляется во фреймворк 9 токена, где он преобразуется в утилитарный токен, который, прежде всего, может иметь показанный на фиг. 9(Б) формат токена.

Основное различие между двумя показанными на фиг. 9 форматами токена заключается в том, что в отличие от показанного на фиг. 9(А), формата имущественного токена, формат имущественного токена согласно фиг. 9(Б) имеет два дополнительных поля данных, которые зарезервированы для (i) информации, указывающей на действие или процесс, с которым связан утилитарный токен, и (ii) одного или более ресурсов, например устройств или (других) участников, подвергшихся влиянию действия или процесса, соответственно. Итак, формат имущественного токена, прежде всего, пригоден и предназначен для связи с токеном, представляющим имущество, такое как физический объект как таковой, в то время как формат утилитарного токена пригоден и предназначен, прежде всего, для того, чтобы быть соотнесенным с, по меньшей мере, частично представляющим действие или процесс токеном.

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

Факультативно, на шаге 140 утилитарный токен может дополнительно сохраняться в одном или более распределенных реестрах, предпочтительно, включая соотнесенный с экосистемой E1 распределенный реестр, например блокчейн B1.

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

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

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

На фиг. 4 схематически показан набор двух служащих примером цепочек A и B поставок, причем цепочка A поставок соотнесена со способом токенизации первого физического объекта PO1 в первой экосистеме E1, и цепочка B поставок соотнесена со способом токенизации второго физического объекта PO2 во второй, разной экосистеме E2. Цепочка поставок A соответствует цепочке согласно фиг. 2 и фиг. 3. Цепочка B поставок может, например, отображать логистическую цепочку, используемую для обеспечения цепочки A поставок. Соответствующая основанная на токенах экосистема E2 может, прежде всего, включать в себя распределенный реестр, например другой блокчейн B2. Хранимые в нем в виде (имущественного) токена данные могут быть, прежде всего, соотнесены с физическим объектом PO2, такому как холодильная камера транспортного средства, используемого для поставки PO1 вдоль цепочки A поставок, и может иметь участников 3a', 3b' и 3c', соотнесенных с его узлами. Необходимо взаимодействие между двумя экосистемами, если имеющиеся в одной или двух экосистемах данные должны быть сделаны доступными для соответственно другой экосистемы посредством обмена одного или более токенов между экосистемами сертифицированным и, следовательно, надежным способом.

На фиг. 5 показана иллюстрирующая способ 200 блок-схема, которая может быть использована для осуществления этой возможности взаимодействия. В настоящем примере компонент экосистемы E1 требует и запрашивает данные, имеющиеся только в экосистеме E2. Обычно на шаге 205 компонент экосистемы E1 отправляет представляющий запрос утилитарный токен через фреймворк 9 - токена, который простирается и имеется в обеих экосистемах, компетентной системе 4 сертификации. Прежде всего, фреймворк токена может иметь в дополнение к функциональности для идентификации правильной системы сертификации для запроса среди набора из нескольких систем сертификации, адресуемых через фреймворк токена, возможность направлять утилитарный токен к правильной системе сертификации, которая сертифицирует запрос и, таким образом, утилитарный токен, если выполняются условия для сертификации. Фреймворк токена может также иметь функциональность для идентификации правильного получателя для сертифицированного запроса, который может сделать доступной запрошенную информацию, например блокчейн B2, среди набора разных компонентов экосистемы E2 или даже одной или более других экосистем E3 и т.п.

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

На фиг. 6 схематически показана связь двух служащих примером цепочек A и B поставок, причем цепочка A поставок соотносится со способом токенизации первого физического объекта PO1 в первой экосистеме E1, и цепочка B поставок соотносится со способом токенизации второго физического объекта PO3 во второй, другой экосистеме E2. Цепочка A поставок соответствует цепочке поставок согласно фиг. 2 и фиг. 3. Цепочка B поставок может, например, представлять цепочку процесса, использованную для поставки второго физического объекта PO3, использованного для проверки первого физического объекта PO1, поставляемого вдоль цепочки A поставок, и с целью проверки в качестве PO3 может быть, прежде всего, использован одноразовый (продукт), использованный для проверки мясного продукта PO1, например кювета. Соответствующая основанная на токенах экосистема E2 может, прежде всего, включать в себя распределенный реестр, например другой блокчейн, B2. Сохраненные в нем данные в виде (имущественного) токена могут, прежде всего, относиться к физическим объектам PO3, таким как одноразовые продукты. Как в случае фиг. 4 и фиг. 5, необходимо взаимодействие между двумя экосистемами, поскольку доступные в одной из двух экосистем данные необходимо сделать доступными для соответственно другой экосистемы посредством обмена одного или более токенов между экосистемами сертифицированным и, таким образом, надежным способом. Фиг. 6, прежде всего, относится к сценарию, где результаты выполненного в экосистеме 2 процесса должны быть связаны токенизированным и сертифицированным способом с экосистемой E1.

На фиг. 7 показана блок-схема, иллюстрирующая служащий примером способ 300 обеспечения основанной на токенах связи данных между двумя экосистемами E1 и E2 в соответствии с фиг. 6 согласно вариантам осуществления настоящего изобретения.

Согласно фиг. 6 и фиг. 7, с одной стороны, для цепочки A поставок/экосистемы E1 способ 100 выполняется в связи с соотнесенным физическим объектом PO1, как описано выше, для токенизации физического объекта PO1, то есть в настоящем неограничивающем примере мясной продукт. Получившийся сертифицированный токен посредством этого сохраняется в блокчейне B1

С другой стороны, для цепочки B поставок/экосистемы E2 результаты процесса проверки должны быть сертифицированы и токенизированы, что включает в себя сертификацию одноразового PO3, требуемого для выполнения проверки. Процесс токенизации результата процесса включает в себя шаги 305-335 согласно фиг. 7.

Основанный на выданном экосистемой E1 через фреймворк 9 токена запросе, результат сертифицированного процесса проверки обеспечивается посредством способа 200 взаимодействия согласно фиг. 5 для экосистемы E1, причем он получен на шаге 340 и хранится в блокчейне B1, например в соответствующем соотнесенном с физическим объектом PO1 имущественном токене.

Фиг. 8А-8В совместно показывают иллюстрирующую в объединенном виде взаимодействие способов согласно фиг. 2-7 блок-схему, представляющую основной тип блок-схемы UML (единый язык моделирования), давая программно-процессорно-архитектурный обзор изобретения.

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

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

Когда предварительный имущественный токен создан, в качестве следующего шага этот токен должен быть проверен на достоверность, что включает в себя так называемую проверку достоверности токена. По существу, это означает, что существование недавно сгенерированного предварительного имущественного токен через фреймворк протокола, называемого "фреймворком токена", направляется в центральную сертифицирующую организацию таким образом, что эта центральная сертифицирующая организация может быть соотнесена с этим токеном. Затем центральная сертифицирующая организация инициирует процесс проверки на достоверность, который может включать в себя, с одной стороны, проверку, имеется ли для соответствующего объекта предыдущий имущественный токен и, таким образом, потенциальный конфликт, в случае которого предварительный токен не будет преобразован в конечный сертифицированный имущественный токен, то есть не будет нотариально засвидетельствован в качестве имущественного токена. Кроме того, процесс проверки достоверности может включать в себя коммерческий аспект проверки достоверности, который, однако, не является объектом настоящего изобретения.

Если проверка достоверности прошла успешно, центральная сертифицирующая организация передает эти полученные сведения назад к среде производства продукта, а именно, к ассоциированному со считывающим устройством бумажнику и, как следствие, предварительный имущественный токен преобразуется в (не предварительный) сертифицированный имущественный токен, причем это преобразование включает в себя подтверждение присвоенного ему значения. В дополнение центральная сертифицирующая организация хранит или побуждает к хранению полученную ей информацию, которая соотносится с этим токеном в среде распределенного реестра, который соотнесен со средой производства продукта (домашней среде, например DLT). Например, в случае являющейся генератором имущества экосистемы E1 это может быть блокчейн или другая контролируемая экосистемой E1 среда хранения. Вкратце, эта начальная часть процесса приводит к "нотариально засвидетельствованному" объекту, представленному соответствующим проверенным на достоверность имущественным токеном. Главной ролью имущественного токена является сохранение первоначально сгенерированного относящегося к физическому объекту токена как основы для коммерциализации объекта.

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

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

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

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

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

С другой стороны, процесс сертификации используется во втором режиме во время фактической проверки подлинности такого объекта, причем соотнесенный с подлежащим проверке аутентичности объектом утилитарный токен (и, факультативно, дополнительные данные процесса) передается через фреймворк токена центральной сертификационной организации, которая в ответ проверяет подлинность содержимого утилитарного токена посредством сравнения его с сохраненной во время процесса инициализации эталонной информацией (ср. европейские патентные заявки: EP 3 340 213 A1, EP 3 340 212 A1, EP 18170044.4, EP 18170047.7 и EP 18214512.8) и в ответ передает результаты проверки подлинности (возвращает токен сертификации) (достоверность), причем последние являются утилитарным токеном (включая другую запись, сертифицирующую результат проверки подлинности). Процесс проверки может быть также назван смарт контрактом, поскольку, по существу, как на техническом, так и на коммерческом уровне это является тем, чем, по существу, является. Затем возвращенный утилитарный токен сохраняется в хранилище данных домашней среды, то есть домашней DTL, что может быть, прежде всего, инициировано центральной сертификационной организацией.

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

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

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

Перечень ссылочных обозначений:

1 основанная на токенах экосистема

2, 2А, 2Б считывающее устройство

3, 3А, 3Б, 3В, 3А', 3Б', 3В' участник

4 сертифицирующая организация

5 основанная на токенах экосистема

6 распределенный реестр

9 фреймворк токена

100 способ токенизации

105 запрос на сертификацию

110 получение сертификата

115 сканирование PUF

120 создание имущественного токена

125 хранение токена

130 обеспечение токена

135 создание утилитарного токена/преобразование

140 распределяющее действие

145 сертификация токена

200 способ взаимодействия

205 запрос данных

210 получение в ответ сертифицированных данных

300 основанная на токене связь между экосистемами E1 и E2

310 получение сертификации

315 процесс 1'... N'

320 результат процесса создания утилитарного токена

325 запрос процесса проверки подлинности

330 сертификация токена

335 распределение сертифицированных данных процесса

340 получение сертифицированного результата

A1, A2, A3 узлы

B1, B2, B3 блокчейн

E1, E2 экосистема

PO, PO1, PO2 физический объект.

Настоящее изобретения относится к средствам для токенизации физического объекта. Технический результат – повышение защищенности токенизации физического объекта. Получают данные идентификации объекта, основанные на проверке физического объекта, причем данные идентификации объекта включают в себя по меньшей мере одно криптографическое значение хеш-функции в виде устойчивого к конфликтам виртуального представления физического объекта. Осуществляют генерирование несертифицированного токена, соотнесенного с физическим объектом и представляющего данные идентификации объекта. 6 н. и 13 з.п. ф-лы, 11 ил.

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

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

- генерирование несертифицированного токена, соотнесенного с физическим объектом и представляющего данные идентификации объекта,

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

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

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

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

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

2. Способ по п. 1, также включающий в себя:

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

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

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

4. Способ по одному из предшествующих пунктов, также включающий в себя:

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

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

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

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

7. Способ по одному из предшествующих пунктов, также включающий в себя:

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

- передачу в ответ запрошенных данных через фреймворк токена.

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

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

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

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

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

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

- информацию, указывающую на создание несертифицированного токена в связи с данными идентификации объекта и запрос на проверку достоверности несертифицированного токена,

- корреляцию данных идентификации объекта с данными идентификации эталонного объекта в отношении заданного критерия соответствия, и

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

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

12. Реализуемый на компьютере способ токенизации процесса, такого как процесс идентификации физического объекта, причем способ включает в себя:

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

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

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

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

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

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

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

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

13. Способ по п. 12, также включающий в себя:

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

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

14. Способ по п. 12 или 13, также включающий в себя:

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

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

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

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

17. Способ по одному из пп. 12-16, также включающий в себя:

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

- передачу в ответ запрошенных данных через фреймворк токена.

18. Способ по одному из пп. 12-17, причем по меньшей мере одно из данных идентификации объекта, данных сертификации проверки, данных запроса на проверку достоверности несертифицированного утилитарного токена, данных сертификации утилитарного токена, данных запроса информации и запрошенных данных передают, получают или сохраняют, соответственно, в виде внедренных в токен данных.

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