КРИПТОГРАФИЧЕСКАЯ АУТЕНТИФИКАЦИЯ И ТОКЕНИЗИРОВАННЫЕ ТРАНЗАКЦИИ Российский патент 2021 года по МПК G06Q20/20 

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

По данной заявке испрашивается преимущество и приоритет на основании заявки на патент Соединенного Королевства № 1613882.8, поданной 12 августа 2016г. Полное раскрытие вышеупомянутой заявки на патент включено в настоящее описание путем ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

УРОВЕНЬ ТЕХНИКИ

Платежные карты, такие как кредитные карты и дебетовые карты, очень широко используются для всех форм финансовой транзакции. В последние годы в связи с технологическими разработками использование платежных карт получило значительное развитие. Первоначально транзакции были на бумаге, используя оттиск карты транзакции, и подтверждались подписью. Данный подход был в значительной степени замещен посредством использования магнитной полосы карты транзакции, проводимой через устройство чтения магнитной полосы на терминале точки продажи (POS), чтобы выполнить транзакцию. Разработаны карты транзакции, содержащие интегральную микросхему («карты с микропроцессором» или «интеллектуальные карты»), которые осуществляют связь с устройством чтения интеллектуальных карт в терминале POS. При использовании данного подхода транзакция как правило подтверждается персональным идентификационным номером (PIN), который вводится пользователем карты. Карты данного типа как правило работают по стандарту EMV для взаимодействия карт с микропроцессором и ассоциированного устройства (такого как терминалы POS и банкоматы). Документ ISO/IEC 7816 предоставляет стандарт для работы карт данного типа. Платежные карты и устройства предоставляются в соответствии со схемой транзакции (такой как MasterCard, American Express или Visa), а механизм транзакции реализуется при посредничестве инфраструктуры схемы транзакции.

Технические описания EMV относятся к протоколам контактных и бесконтактных платежей и являются общедоступными на web-сайте EMVCo (EMVCo является отраслевым органом, на который возложено обеспечение этих технических описаний при поддержке основных поставщиков схемы транзакции) - https://www.emvco.com/document-search/ - и специалист в соответствующей области может легко к ним обратиться. Терминология, относящаяся к технологии EMV, которая в явной форме не определена в данном документе, упоминается и определяется в технических описаниях EMV, как будет понятно специалисту в соответствующей области техники.

Технология получила дальнейшее развитие для предоставления платежных карт, которые работают бесконтактным образом - в соответствии с EMV они подпадают под стандарт ISO/IEC 14443. При использовании таких карт первичный номер счета (PAN) может быть считан автоматически с карты терминалом POS, используя протоколы NFC - данный подход как правило упоминается как «бесконтактный» или «основанный на близости» платеж. Это как правило возможно путем встраивания чипа NFC в корпус карты вместе с подходящей антенной, чтобы обеспечивать передачу и прием беспроводных сигналов - питание для передач может подаваться посредством магнитного индуктивного поля, излучаемого устройством чтения на основе близости в терминале POS. Чтобы была выполнена эффективная транзакция платежная карта должна быть помещена в непосредственной близости от устройства чтения на основе близости - EMVCo определил данный диапазон в соответствии с рабочим динамическим диапазоном Уровня 1 в 0-4см.

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

При выполнении цифровых транзакций, используя вычислительное устройство, предпочтительным подходом является токенизация. Она включает замещение в транзакции первичного номера счета карты (PAN - данный номер ассоциирован со счетом держателя карты в банке-эмитенте) альтернативным номером карты или токенами. Токенизация как правило используется для транзакций в точке продажи с помощью мобильных устройств, покупок через приложение или онлайновых покупок. Чтобы обеспечивать токенизацию подробности карты удерживаются в цифровом кошельке на устройстве держателя карты, которое поддерживается поставщиком кошелька. Схема транзакции предоставляет услугу цифровой разблокировки, чтобы поддерживать токены, а администрирование токенов осуществляется поставщиком услуги токена. Предоставляются платежные протоколы, которые обеспечивают выполнение транзакций в соответствии с техническими описаниями EMV, используя токены вместо PAN карты. Несмотря на то, что существуют другие платежные технологии для мобильного использования, настоящий заявитель использует для токенизации платежное решение, именуемое DSRP (Цифровой Защищенный Дистанционный Платеж) в поддержку мобильного платежного приложения Mobile PayPass, с цифровой разблокировкой в инфраструктуре схемы транзакции обеспечиваемой Услугой Цифровой Разблокировки Mastercard (MDES).

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

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

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

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

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

Данные начального значения транзакции могут содержать непредсказуемое число.

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

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

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

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

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

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

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

Фигура 2 показывает реализацию системы транзакции с Фигуры 1, адаптированную для выполнения вариантов осуществления изобретения;

Фигуры 3A и 3B показывают соответственно функциональные элементы вычислительного устройства пользователя и устройства продавца для использования в реализации системы транзакции Фигуры 2;

Фигура 4 показывает в варианте осуществления способ изобретения;

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

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

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

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

Фигура 9 иллюстрирует привязку в вариантах осуществления изобретения;

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

Фигура 11 иллюстрирует процесс для предоставления статуса аутентификации эмитента в вариантах осуществления изобретения.

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

Общие и особые варианты осуществления изобретения будут описаны ниже при обращении к фигурам.

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

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

Четырехсторонняя модель может быть использована в качестве основы для сети транзакции. Применительно к каждой транзакции модель содержит четыре типа объектов: держатель 110 карты, продавец 120, эмитент 130 и эквайер 140. В данной модели держатель 110 карты покупает товары или услуги у продавца 120. Эмитент 130 является банком или любым другим финансовым учреждением, которое выпускает карту держателю 110 карты. Эквайер 140 предоставляет услуги применительно к обработке карты продавцу 120.

Модель также содержит центральный коммутатор 150 - маршрутизация взаимодействий между эмитентом 130 и эквайером 140 осуществляется через коммутатор 150. Коммутатор 150 позволяет продавцу 120, ассоциированному с одним конкретным банком-эквайером 140, осуществлять принятие платежных транзакций от держателя 110 карты, ассоциированного с другим банком-эмитентом 130.

Типичная транзакция между объектами в четырехсторонней модели может быть разделена на две основные стадии: авторизация и расчет. Держатель 110 карты инициирует покупку товара или услуги у продавца 120, используя свою карту. Подробности карты и транзакции отправляются эмитенту 130 через эквайера 140 и коммутатор 150, чтобы авторизовать транзакцию. Если эмитент 130 посчитает транзакцию ненормальной, держателю 110 карты может потребоваться пройти дополнительный процесс верификации, чтобы верифицировать свои идентификационные данные и подробности транзакции. Как только процесс дополнительной верификации завершен, транзакция является авторизованной.

По завершению транзакции между держателем 110 карты и продавцом 120 подробности транзакции представляются продавцом 120 эквайеру для расчета.

Затем осуществляется маршрутизация подробностей транзакции к релевантному эмитенту 130 посредством эквайера 140 через коммутатор 150. По приему этих подробностей транзакции эмитент 130 предоставляет расчетные денежные средства коммутатору 150, который в свою очередь переадресовывает эти денежные средства продавцу 120 через эквайера 140.

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

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

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

Держатель 1 карты использует свое вычислительное устройство - которое может быть любым или всем из сотовой телефонной трубки, планшета, лэптопа, стационарного персонального компьютера или любым другим подходящим вычислительным устройством (здесь показана сотовая телефонная трубка или интеллектуальный телефон 11) - чтобы оно действовало либо в качестве посредника для физической платежной карты 6, либо в качестве виртуальной платежной карты, работающей только в цифровой области. Интеллектуальный телефон 11 добивается этого с помощью мобильного платежного приложения и цифрового кошелька, как описывается ниже. Таким образом интеллектуальный телефон 11 способен совершать сделки с терминалом 7 POS продавца, используя NFC или другую бесконтактную технологию. Интеллектуальный телефон 11 также способен взаимодействовать с сервером 12 продавца, представляющим собой продавца 2, через подходящее сетевое соединение, такое как общедоступная сеть Интернет.

Инфраструктура 5 схемы транзакции (инфраструктура транзакции) обеспечивает не только вычислительную инфраструктуру, необходимую для работы схемы карты и обеспечивает маршрутизацию транзакций и другой обмен сообщениями для сторон, таких как эквайер 3 и эмитент 4, но также услугу 17 кошелька, чтобы поддерживать цифровой кошелек на вычислительном устройстве держателя карты, и интернет-шлюз 18, чтобы осуществлять принятие основанных на Интернет транзакций для обработки посредством инфраструктуры транзакции. В других вариантах осуществления услуга 17 кошелька может быть предоставлена аналогично третьей стороной с помощью подходящего доверительного отношения с поставщиком схемы транзакции. Чтобы поддерживать токенизацию присутствует поставщик 19 услуги токена (вновь он показан как часть инфраструктуры 5 транзакции, но может быть предоставлен третьей стороной с помощью подходящих доверительных отношений) и инфраструктура схемы транзакции предоставляет услугу 16 цифровой разблокировки, чтобы поддерживать выполнение токенизированных цифровых транзакций, и чтобы взаимодействовать с другими элементами системы, чтобы обеспечивать корректное выполнение транзакций.

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

Фигура 3A и 3B схематично иллюстрирую по функциям вычислительное устройство пользователя и устройство POS продавца соответственно. Прочие элементы архитектуры Фигуры 2 либо не модифицируются в вариантах осуществления изобретения, либо организованы по существу обычным образом - например сервер 12 продавца, который может быть реализован сервером промышленного стандарта, запрограммированным для наличия обычного отношения сервер/клиент с клиентами, такими как приложение продавца на интеллектуальном телефоне пользователя. Аналогично элементы показаны явно в схеме транзакции, которая может быть выполнена походящим образом запрограммированными серверами, ассоциированными со схемой транзакции. В целом инфраструктура 5 схемы транзакции содержит серверы, сетевые связи и коммутаторы, для обеспечения корректной маршрутизации и обработки транзакций.

Фигура 3A показывает вычислительное устройство пользователя, в данном случае интеллектуальный телефон 11. Интеллектуальный телефон обладает по меньшей мере одним процессором 31 и по меньшей мере одной памятью 32, определяя между ними вычислительную среду 33 для выполнения приложений. Приложения, работающие в вычислительной среде, включают в себя приложение 331 кошелька, приложение 332 продавца и среду 333 платежной системы на основании близости, которые описываются более подробно ниже. Могут присутствовать другие элементы, такие как биометрическое приложение 334, которое может быть использовано чтобы осуществлять аутентификацию пользователя 1 интеллектуального телефона 11 до того, как будет предпринято действие. Память 32 может содержать одну или более физическим или логическим образом защищенные области 321 для защиты уязвимых данных, которые требуются этими приложениями - такие безопасные среды могут быть реализованы разнообразными путями (как будет понятно специалисту в соответствующей области техники) и здесь явно не показаны, но доступ к безопасной обработке данных как правило потребуется как для приложения кошелька, так и биометрического приложения. Интеллектуальный телефон 11 конечно выполнен с возможностью осуществления сотовой связи (и как обычно также беспроводной связи малого радиуса действия) и имеет систему 34 беспроводной связи. Интеллектуальный телефон 11 здесь также имеет биометрический датчик, в данном случае устройство 35 чтения отпечатка пальца. Присутствуют другие обычные элементы устройства интеллектуального телефона, такие как интерфейс 36 пользователя сенсорного экрана и камера 37, но, тогда как их работа является обычной, они в явной форме здесь не описываются.

Фигура 3B показывает терминал 7 POS, выполненный с возможностью реализации варианта осуществления изобретения - в данном случае терминал 7 POS показан в качестве мобильного устройства, но в других вариантах осуществления он может быть стационарным вычислительным устройством. Терминал 7 POS также обладает по меньшей мере одним процессором 31a и по меньшей мере одной памятью 32a, определяя между ними вычислительную среду 33a для выполнения приложений. Приложения здесь включают в себя приложение 335 точки продажи (POS), использующее интерфейс 34a связи для связи с интеллектуальным телефоном 11 пользователя и интерфейс 36a пользователя (также могут быть предоставлены другие опции связи, такие как обычное соединение с другими объединенными в сеть устройствами в рамках более широкой архитектуры сети). Функции приложения 335 POS будут описаны дополнительно ниже - как отмечается дополнительно ниже, это включает обсуждение функций, которые могут быть выполнены на устройстве POS продавца, но также могут быть выполнены в другой системе продавца, такой как сервер продавца.

Общий вариант осуществления способа в соответствии с изобретением иллюстрируется схематично на Фигуре 4. Фигура 4 показывает этапы при выполнении токенизированной транзакции в соответствии с вариантами осуществления изобретения. В данном подходе стороне принятия платежа (продавец) были предоставлены идентификационные данные продавца и сертификат продавца, ассоциированный с теми идентификационными данными посредством поставщика схемы транзакции. Применительно к токенизированной транзакции продавец предоставляет 410 идентификационные данные продавца и данные начального значения транзакции стороне предложения платежа (покупателю, как представлено вычислительным устройством покупателя, содержащим мобильное платежное приложение и приложение кошелька). Устройство покупателя проверяет 420 достоверность идентификационных данных продавца и использует идентификационные данные продавца и данные начального значения транзакции, чтобы сгенерировать криптограмму для токенизированной транзакции. Данная криптограмма может быть сгенерирована (в качестве Прикладной Криптограммы) в соответствии с техническими описаниями EMV с помощью данных, связанных с функциональной возможностью изобретения, предоставленных в полях данных внутри существующих полей данных EMV назначенных или переназначенных соответственно. Затем устройство покупателя предоставляет 430 криптограмму продавцу для передачи поставщику схемы транзакции для авторизации токенизированной транзакции.

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

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

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

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

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

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

Это позволяет продавцам обеспечивать оптимизированное восприятие пользователя.

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

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

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

Реализации аспектов изобретения описываются в отношении настоящего платежного решения Цифрового Защищенного Дистанционного Платежа (DSRP) заявителя. Данное платежное решение позволяет продавцам Без Присутствия Карты извлекать выгоду из динамических данных транзакции, генерируемых мобильными платежными приложениями, используя токенизацию. Продавец Без Присутствия Карты является продавцом, осуществляющим транзакцию с помощью объекта отличного от физической карты таким образом, что продавец не может получить заверение из использования физической карты покупателя на терминале продавца. DSRP используется в ассоциации с токенизированными картами, которые допускаются Услугой Цифровой Разблокировки Mastercard (MDES).

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

- Транзакции Цифрового Защищенного Дистанционного Платежа требуют аутентификации держателя карты и включают в себя динамические данные, чтобы предоставлять доказательство того, что была выполнена аутентификация держателя карты.

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

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

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

- Процесс Аутентификации Продавца

- Доставка Аутентифицированного Непредсказуемого Числа

- Привязка Канала, используя модель аутентификации

- Управляемое Продавцом Восприятие Пользователя

- Статус Аутентификации Эмитента для Продавца

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

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

Процесс привязки канала использует модель аутентификации, чтобы:

1. Поставщик схемы осуществлял аутентификацию продавца

2. Кошелек осуществлял аутентификацию продавца

3. Система авторизации осуществляла аутентификацию кошелька/платежного приложения

4. Кошелек осуществлял аутентификацию покупателя

Система Авторизации способна проверять, что:

- Покупатель был верифицирован кошельком

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

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

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

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

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

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

Этапы процесса являются следующими:

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

2. Схема транзакции доставляет (602) платежный токен продавцу.

3. Продавец использует (603) токен чтобы выполнять одну онлайновую транзакцию.

4. Схема онлайновой авторизации схемы транзакции проверяет (604) достоверность транзакции.

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

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

Подлинный Продавец является имеющим право принимать сертификат продавца. Этапы процесса являются следующими:

1. Схема транзакции назначает (701) уникальный идентификатор (здесь ID Аутентифицированного Акцептанта Mastercard или MAAID) продавцу, который успешно завершил процесс Подлинного Продавца.

- MAAID может быть уже определен независимо от токенизированной транзакции, выполняемой подлинным продавцом.

- В вариантах осуществления MAAID является 16-байтным Глобально Уникальным Идентификатором (GUID), чтобы гарантировать уникальность.

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

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

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

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

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

- Продавец может генерировать свою собственную пару ключей.

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

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

5. Услуги администрирования ключа схемы транзакции используют Центр Сертификации, чтобы генерировать (703) сертификат продавца. Отметим, что сертификат продавца должен включать в себя MAAID.

6. Схема транзакции затем генерирует (704) контейнер для продавца.

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

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

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

7. Схема транзакции доставляет (705) контейнер продавцу.

8. Продавец принимает контейнер.

9. Процесс аутентификации продавца завершается следующими постусловиями:

- Продавец имеет пару ключей (PKI)

- Продавец имеет сертификат продавца и связанную цепочку доверия

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

- Продавец имеет уникальный идентификатор продавца (MAAID)

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

Базовое описание данного процесса, как используемого для транзакции DSRP, является следующим:

1. Продавец генерирует непредсказуемое число (UN) как часть транзакции DSRP.

2. UN отправляется кошельку через API между продавцом и кошельком.

3. Кошелек содержит токен, либо внутри устройства аппаратного обеспечения внутри того же самого устройства, либо в качестве программного обеспечения внутри устройства или на сервере.

4. UN используется как часть генерирования криптограмм(ы).

5. Кошелек возвращает криптограмму(ы) продавцу.

6. Криптограмма(ы) отправляется как часть транзакции DSRP для онлайновой авторизации (используя поля DE55 или DE48, как определено в технических описаниях EMV).

Доставка аутентифицированного Непредсказуемого Числа (UN) криптографическим образом связывает доставку UN с ID Аутентифицированного Акцептанта Mastercard, ассоциированным с продавцом. Процесс доставки аутентифицированного Непредсказуемого Числа (UN) разбит на две части:

A. Операции, выполняемые Продавцом=Обработка Продавца

B. Операции, выполняемые Кошельком=Обработка Кошелька

Доставка Аутентифицированного UN - Обработка Продавца

Продавец должен доставить аутентифицированное Непредсказуемое Число (UN)

Этапы процесса являются следующими:

1. Продавец запрашивает (801) опознавательный сигнал, предоставляя MAAID

2. Кошелек принимает запрос и генерирует опознавательный сигнал (4 байта)

3. Кошелек сохраняет опознавательный сигнал и MAAID

4. Кошелек возвращает (802) опознавательный сигнал продавцу

5. Продавец генерирует (803) Непредсказуемое Число (UN)

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

MSG:= Непредсказуемое Число | Опознавательный сигнал | ID Аутентифицированного Акцептанта Mastercard

где | является операцией сочленения

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

8. Существует несколько опций для защиты сообщения

I. Подписание сообщения с восстановлением подписи

Отметим, что небольшой размер сообщения (24 байта, содержащие 4 байта UN, 4 байта опознавательного сигнала и 16-байтовое значение для MAAID) позволяет поместить информацию внутри модуля.

II. Подписание сообщения

III. Шифрование и подписание сообщения

9. Продавец доставляет (806) следующие элементы как часть запроса, отправленного Кошельку, чтобы сгенерировать криптограмму(ы) DSRP:

a. Данные (одна из следующих опций, как изложено в 8)

I. Подпись, сгенерированная с восстановлением сообщения

II. Сообщение и подпись

III. Зашифрованное сообщение и подпись

b. Сертификат продавца

Доставка Аутентифицированного UN - Обработка Кошелька

Кошелек должен осуществлять аутентификацию Непредсказуемого Числа (UN). В качестве предварительного условия кошелек должен иметь доступ к открытым ключам CA схемы транзакции и связанной цепочке доверия.

Этапы процесса являются следующими:

1. Кошелек принимает следующие элементы как часть запроса, отправленного продавцом (или любым шлюзом, используемым чтобы инициировать процесс DSRP):

a. Данные (как обсуждалось выше)

I. Подпись, сгенерированная с восстановлением сообщения

II. Сообщение и подпись

III. Зашифрованное сообщение и подпись

b. Сертификат продавца

2. Кошелек проверяет (807) достоверность сертификата продавца, используя Открытый Ключ схемы транзакции. Использование Списка Отозванных Сертификатов (CRL) или Онлайнового Протокола Статуса Сертификата (OCSP) является опциональным, поскольку любой отозванный продавец будет идентифицирован как часть онлайновой авторизации и связанный токен и/или MAAID будет отозван или приостановлен.

3. После успешной проверки достоверности сертификата продавца Кошелек проверяет достоверность подписи и восстанавливает (808) первоначальное сообщение, созданное продавцом:

MSG:= Непредсказуемое Число | Опознавательный сигнал | ID Аутентифицированного Акцептанта Mastercard

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

Таким образом кошелек может осуществлять доступ к значению Непредсказуемого Числа (UN), опознавательному сигналу и MAAID.

Заверение является неявным криптографическим подтверждением, которое становится явным, когда Непредсказуемое Число (UN) и MAAID используются платежным приложением (используемым кошельком), чтобы генерировать прикладную криптограмму(ы), как обсуждается дополнительно ниже.

4. Кошелек проверяет (809) значение MAAID, которое содержится в сообщении, по отношению к MAAID, который определен в сертификате продавца.

5. После успешной проверки достоверности MAAID кошелек может проверять (810) опознавательный сигнал.

6. После успешной проверки опознавательного сигнала (ассоциированного с MAAID для транзакции) кошелек может использовать аутентифицированное Непредсказуемое Число (UN) и MAAID для привязки канала, используя модель аутентификации, как обсуждается дополнительно ниже.

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

8. Процесс доставки Непредсказуемого Числа (UN) завершается следующими постусловиями:

- Доставка была выполнена в контексте опознавательного сигнала/процесса ответа (= актуализация)

- Кошелек имеет аутентифицированный Непредсказуемое Число (UN), сгенерированное продавцом

- Кошелек имеет MAAID продавца

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

Вновь примерный процесс будет описан как используемый в транзакции DSRP следующим образом:

1. Продавец генерирует непредсказуемое число (UN) как часть транзакции DSRP

2. UN отправляется кошельку и используется как часть генерирования прикладной криптограмм(ы)

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

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

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

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

4. Кошелек способен осуществлять аутентификацию покупателя, используя способ верификации держателя карты (CVM), такой как CDCVM (Способ Верификации Держателя Карты на Устройстве Покупателя), или любой эквивалентный способ, вновь в соответствии с техническими описаниями и процессами EMV.

Система авторизации способна проверять то, что покупатель был верифицирован кошельком, используя проверку достоверности криптограмм(ы), когда был выполнен CDCVM, и что это было успешным, используя информацию Результатов Верификации Карты (CVR) доступную из информации транзакции.

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

Данная модель аутентификации используется для привязки канала. Весь подход может быть рассмотрен в трех частях, причем каждая описывается более подробно ниже:

A. Операции, выполняемые кошельком/платежным приложением=Обработка Кошелька/Платежного Приложения

B. Операции, выполняемые продавцом=Обработка Продавца

C. Операция, выполняемая системой авторизации=Обработка Системы Авторизации

Привязка канала - Обработка Кошелька/Платежного Приложения

Кошелек использует платежное приложение, чтобы генерировать прикладную криптограмму(ы) в контексте транзакции DSRP. Платежное приложение связывает прикладную криптограмму(ы) с аутентифицированным Непредсказуемым Числом и MAAID.

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

Объект данных Размер (байт) Сумма, Авторизованный (Числовой) 6 Сумма, Другое (Числовой) 6 Код Страны Терминала 2 Результаты Верификации Терминала (TVR) 5 Код Валюты Транзакции 2 Дата Транзакции 3 Тип Транзакции 1 Непредсказуемое Число (UN) 4 Профиль Взаимообмена Приложения (AIP) 2 Счетчик Транзакция Приложения (ATC) 2 Результаты Верификации Карты (CVR) 6

Таблица 1 - Входные данные для транзакции DSRP

Этапы процесса являются следующими:

1. Кошелек отвечает за верификацию (901) покупателя. Опционально продавец может играть роль в восприятии пользователя кошелька посредством регулировки процесса верификации в соответствии с предпочтениями продавца, которые доставляются как часть информации, которая переносится в сертификате продавца, как описано выше.

2. Кошелек предоставляет итог верификации покупателя платежному приложению.

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

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

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

4. Кошелек может выполнять дополнительные операции (903), описываемые ниже в отношении Статуса Аутентификации Эмитента, перед доставкой ответа продавцу

5. Кошелек доставляет (904) данные DSRP (включающие в себя прикладную криптограмму(ы)) обратно продавцу. Когда аутентифицированный продавец использует токены, которые привязаны к продавцу, кошельку не требуется отправлять обратно MAAID продавцу.

Привязка Канала - Обработка Продавца

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

1. Продавец принимает данные DSRP как часть ответа, отправленного кошельком.

2. Продавец может выполнять дополнительные операции, описываемые ниже в отношении Аутентификации Эмитента, перед подачей транзакции для онлайновой авторизации.

3. Продавец подготавливает (905) информацию для онлайновой авторизации транзакции, включая:

a. Непредсказуемое Число, сгенерированное продавцом как часть процесса доставки аутентифицированного Непредсказуемого Числа.

b. Контент данных DSRP, принятых от кошелька.

4. Продавец доставляет данные транзакции системе Эквайринга для онлайновой авторизации.

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

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

Привязка Канала - Обработка Системы Авторизации

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

1. Система авторизации принимает (906) данные транзакции для проверки достоверности.

2. Система авторизации должна извлекать MAAID.

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

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

3. Система авторизации проверяет (907) достоверность того, что:

a. MAAID является подлинным для услуги (например, для привязки канала)

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

c. Токен является действительным и не был приостановлен

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

5. Успешная проверка достоверности криптограммы завершает процесс.

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

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

Как показано на Фигуре 10 продавец может управлять восприятием пользователя кошелька, при помощи нескольких способов, например:

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

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

Фигура 11 иллюстрирует процесс для предоставления статуса аутентификации эмитента в вариантах осуществления изобретения. Данный подход обеспечивает улучшения для поддержки аутентифицированных эмитентом транзакций DSRP (Цифровой Защищенный Дистанционный Платеж). В контексте токенизированных транзакций (например, для транзакций DSRP, происходящих при помощи токенов MDES), схема транзакции может использовать существующий бит в данных транзакции и использовать его для переноса дополнительной информации. Одним возможным решением является использование зарезервированного бита в объекте данных Профиля Взаимообмена Приложения (AIP), чтобы идентифицировать, выполнен ли токен с возможностью аутентификации эмитента. В контексте транзакция DSRP, это может быть реализовано следующим образом:

- AIP байт 2, бит 6, значение 1 может указывать то, что токен выполнен с возможностью Аутентифицированных Эмитентом транзакций DSRP

- AIP байт 2, бит 6, значение 0 может указывать то, что токен не выполнен с возможностью Аутентифицированных Эмитентом транзакций DSRP

Данное значение AIP является статическим значением, которое является частью профиля карты, ассоциированного с токеном.

При использовании существующих потоков транзакции продавец, желающий узнать, является или нет транзакция DSRP Аутентифицированной Эмитентом, должен извлечь значение AIP, учитывая, что процесс является зависимым от способа, использованного для доставки данных DSRP продавцу, используя либо DE55, либо DE48 (Универсальное Поле Аутентификации Держателя Карты - UCAF). Особые форматы UCAF могут быть определены поставщиками схемы транзакции. Как только значение AIP извлечено продавцом, последний может анализировать значение (2 байта) для того, чтобы извлечь AIP байт 2, бит 6.

При помощи вариантов осуществления изобретения Статус Аутентификации Эмитента может быть определен кошельком/платежным приложением на основании информации токена (используя флаг Аутентифицированной Эмитентом возможности, определяемый при помощи AIP байта 2, бита 6). Аутентифицированная Эмитентом транзакция означает то, что Эмитент участвовал или имел возможность проверки держателя карты. Статус Аутентификации Эмитента используется чтобы представлять отчет о том, что покупатель является держателем карты.

Администрирование Статуса Аутентификации Эмитента разбито на две части:

A. Операции, выполняемые (1101) кошельком/платежным Приложением=Обработка Кошелька/Платежного Приложения. Они содержат использование карты и цепочки доверия, чтобы получить Статус Аутентификации Эмитента, и чтобы сгенерировать и подписать надлежащее сообщение, с сообщением и картой и сертификатами эмитента, предоставленными для доставки продавцу.

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

Отметим, что введение Статуса Аутентификации Эмитента следует рассматривать в качестве дополнительной функции в сравнении с использованием AIP байта 2, бита 6. При использовании данного решения продавцу не требуется анализировать данные платежа для того, чтобы извлечь Статус Аутентификации Эмитента.

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

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

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

сторона принятия платежа предоставляет идентификационные данные продавца и данные начального значения транзакции стороне предложения платежа;

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

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

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

3. Способ по п. 2, в котором сертификат продавца определяет одну или более функций процесса транзакции на стороне предложения платежа.

4. Способ по п. 3, в котором упомянутая одна или более функций содержат способ верификации покупателя.

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

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

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

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

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

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

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