СИСТЕМЫ И СПОСОБЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В АУТЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЕЙ ПРИМЕНИТЕЛЬНО К СЕТЕВЫМ ТРАНЗАКЦИЯМ

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

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

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

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

[0003] Транзакции по платежным счетам обычно вовлекают платежные счета, связанные с потребителем, при этом платежные счета используются для оплаты покупок одного или более продуктов. В связи с этим, часто обеспечиваются различные механизмы для препятствования и/или предотвращения мошеннических или несанкционированных транзакций. Например, используется технология EMV, согласно которой микросхемы, включенные в платежные карты, используемые для осуществления транзакций по платежному счету, взаимодействуют с кассовым (point-of-sale, POS) терминалом для генерирования криптограмм для транзакций, достоверность которых затем проверяется до одобрения транзакций эмитентами соответствующих платежных счетов (или сторонами от имени эмитентов). Несмотря на то, что традиционно разработана для транзакций с предъявлением карты, технология EMV также подходит для использования в онлайн транзакциях.

[0004] В дополнение к вышесказанному, платежные сети также зачастую предоставляют усовершенствованные методики аутентификации, совместно называемые протоколом 3-D Secure™, который опирается на программные расширения (плагины) торгово-сервисных предприятий (merchant plug-in, MPI) у торгово-сервисных предприятий, вовлеченных в транзакции по платежным счетам, и на серверы управления доступом (access control server, ACS), связанные с эмитентами. Протокол 3-D Secure™ совместно используется для онлайн транзакций для предоставления держателям карты возможности аутентифицировать себя, когда они физически не присутствуют в торгово-сервисных предприятиях, при осуществлении транзакций. В качестве примера, Mastercard® обеспечивает службу Mastercard SecureCode™, которая основана на протоколе 3-D Secure™. В пределах данной услуги, значения аутентификации (например, значения аутентификации держателя счета (accountholder authentication value, AAV) и т.д.) генерируются эмитентами карт и включают в себя результаты аутентификации. Эти значения затем помещаются в конкретное поле в сообщениях авторизации для исходных транзакций, известное в качестве универсального поля аутентификации держателя карты (universal cardholder authentication field, UCAF). В свою очередь, данная информация передается для обеспечения эмитентов запросами авторизации платежей и представления явных доказательств того, что аутентификация была выполнена эмитентами. Другие платежные сети используют схожие службы аутентификации, которые в целом основаны на протоколе 3-D Secure™. И каждая из этих служб обычно требует от эквайеров (или банков) торгово-сервисных предприятий добавления результирующих значений аутентификации в свои стандартные сообщения авторизации.

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

[0005] Чертежи, описанные в данном документе, предназначены только для целей иллюстрации выбранных вариантов осуществления, а не всех возможных вариантов реализации, и не предназначены ограничивать объем настоящего раскрытия:

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

[0007] На Фиг. 2 показана блок-схема примерного вычислительного устройства, которое может использоваться в системе с Фиг. 1;

[0008] На Фиг. 3 показан примерный способ, который может быть реализован через систему с Фиг. 1 для использования в предоставлении полного AAV, включающего в себя значение аутентификации эмитента (IAV), для транзакции, на основе аутентификации потребителя; и

[0009] На Фиг. 4 показана блок-схема примерного формата полного AAV, включающего в себя IAV, который может использоваться применительно к системе с Фиг. 1 и/или способу с Фиг. 3.

[0010] Соответствующие ссылочные позиции указывают на соответствующие части повсюду на нескольких видах чертежей.

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

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

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

[0013] Согласно вышесказанному системы и способы в данном документе уникально предоставляют возможность использования различных дополнительных методик аутентификации и проверки достоверности для транзакций электронной коммерции, которые в более общем смысле являются транзакциями без предъявления карты (card-not-present, CNP). В частности, в данном документе, когда запрос аутентификации принимается на сервере каталогов для конкретной транзакции, сервер каталогов предоставляет токен и (в качестве необязательной возможности) криптограмму, в качестве включенных в запрос, на сервер цифровых служб (digital service server, DSS), который отображает (привязывает) токен в первичный идентификатор счета (primary account number, PAN), связанный с соответствующим платежным счетом, используемым в транзакции, и дополнительно либо проверяет достоверность криптограммы, либо хранит ее защищенным образом для более поздней проверки ее достоверности, и генерирует код проверки достоверности. Сервер каталогов затем передает запрос (с PAN) на сервер управления доступом (access control server, ACS), который предоставляет код Значение Аутентификации Эмитента (Issuer Authentication Value, IAV) для транзакции после аутентификации потребителя, инициировавшего транзакцию. IAV затем формируется в полное значение аутентификации держателя счета (accountholder authentication value, AAV) для транзакции, наряду с другой криптограммой (например, кодом аутентификации сообщения (message authentication code, MAC) и т.д.), и предоставляется торгово-сервисному предприятию для включения в запрос авторизации для транзакции в конкретном местоположении там (например, в универсальном поле аутентификации держателя карты (universal cardholder authentication field, UCAF) запроса авторизации и т.д.). Применительно к запросу авторизации платежная сеть проверяет достоверность криптограммы в AAV и на основе такой проверки достоверности предоставляет возможность либо продолжения транзакции, либо нет. Таким образом, как усовершенствованная аутентификация, предоставленная через ACS, так и защита, предоставляемая криптограммой, внедряются в заданную транзакцию сервером каталогов (например, в качестве части платежной сети, вовлеченной в проверку достоверности криптограммы и т.д.).

[0014] На Фиг. 1 показана примерная система 100 для реализации процесса, который может быть использован для аутентификации и верификации потребителя применительно к транзакции, совершаемой потребителем, и которая совместима, например, с протоколом/спецификацией 3-D Secure™ EMV®. Следует понимать, однако, что не все подробности протокола/спецификации 3-D Secure™ EMV® обсуждаются в данном документе, так как полное и подробное раскрытие этой информации может быть с легкостью понято при обращении к протоколу/спецификации 3-D Secure™ EMV® и или его/ее обсуждениям. Кроме того, изображенная система 100 включает в себя множество субъектов, которые взаимодействуют друг с другом посредством обмена множеством специально форматированных сообщений по защищенным каналам связи (например, определенных в протоколе/спецификации 3-D Secure™ EMV® (см., например, https://www.emvco.com/emv-technologies/3d-secure/) и т.д.). Соответственно, как может быть понятно, аутентификация, изображенная на Фиг. 1, является сложной при необходимом количестве и степени вовлеченных субъектов, сообщений и других требований.

[0015] В изображенном варианте осуществления система 100 включает в себя потребителя 102, связанного с платежным счетом, где платежный счет эмитируется потребителю 102 эмитентом 104 и применим потребителем 102 для оплаты транзакций за покупки у одного или более торгово-сервисных предприятий (например, торгово-сервисного предприятия 106 и т.д.). Потребитель 102 также связан с вычислительным устройством 108, которое выполнено с возможностью осуществлять доступ к одному или более виртуальным местоположениям торгово-сервисного предприятия. Вычислительное устройство 108 может включать в себя, например, планшет, смартфон, ноутбук, настольный компьютер или другое устройство, которое предоставляет возможность потребителю 102 взаимодействовать и/или осуществлять связь с упомянутым одним или более торгово-сервисными предприятиями (например, через веб-странички и/или функционирующие по сети приложения, предоставленные торгово-сервисными предприятиями и т.д.). Кроме того, вычислительное устройство 108 включает в себя являющееся кошельком приложение (не изображено), которое выполнено с возможностью предоставлять реквизиты платежного счета для платежного счета потребителя, например, применительно к транзакциям по платежному счету. В данном варианте осуществления являющееся кошельком приложение включает в себя являющееся виртуальным кошельком приложение, которое может включать в себя, без ограничений, Masterpass® от Mastercard®, Apple Pay® от Apple®, Visa Checkout® и т.д. После установки и/или активации являющемуся кошельком приложению, и в более общем смысле, вычислительному устройству 108 обеспечивается и/или предоставляется пара открытого/закрытого ключей либо один или более симметричных ключей, для использования, как описано ниже, при генерировании криптограммы из расчета на транзакцию, выполняемую потребителем 102 с использованием своего платежного счета (через являющееся кошельком приложение). Эти ключи могут быть предоставлены сервером цифровых служб (digital service server, DSS) (например, DSS 110 и т.д.) или платежной сетью (например, платежной сетью 136, и т.д.), или иным образом, и т.д. Подробности вычислительного устройства 108 и других вычислительных устройств, упоминаемых в данном документе (например, серверов и т.д.), описаны более полно ниже со ссылкой на Фиг. 2.

[0016] Торгово-сервисное предприятие 106 в системе 100 включает в себя, в данном примерном варианте осуществления, виртуальное торгово-сервисное предприятие, имеющее виртуальное местоположение торгово-сервисного предприятия, такое как, например, веб-страничка, функционирующее через сеть приложение и т.д., которое доступно потребителю 102 через вычислительное устройство 108. Виртуальным местоположением торгово-сервисного предприятия может управляться и/или предоставляться непосредственно торгово-сервисным предприятием 106 или другим субъектом от имени торгово-сервисного предприятия 106 и т.д.

[0017] В целом, в системе 100 потребитель 102 предварительно осуществил доступ к торгово-сервисному предприятию 106 и/или взаимодействие с ним в виртуальном местоположении торгово-сервисного предприятия, посредством чего торгово-сервисное предприятие 106 включает в себя профиль для потребителя 102, который включает в себя платежные реквизиты для платежного счета потребителя. В связи с этим, торгово-сервисное предприятие 106, или другой субъект, выполнено с возможностью запрашивать токен у DSS 110 (например, который может быть воплощен в поставщике токенизированных служб (token service provider, TSP) и/или включать в себя его и т.д.) применительно к генерированию профиля для потребителя 102, например, для последующего использования применительно к транзакции по платежному счету потребителем 102 в торгово-сервисном предприятии 106. DSS 110 включает в себя, в данном примерном варианте осуществления, сервер Службы Внедрения Цифровых Технологий Mastercard™ (Mastercard™ Digital Enablement Service, MDES), но также может включать в себя один или более других серверов в других вариантах осуществления и т.д. В любом случае, в ответ на такой зарос токена DSS 110 генерирует индивидуальный токен для платежного счета потребителя и отображает токен в первичный идентификатор счета (primary account number, PAN) для платежного счета (например, в структуре данных, связанной с DSS 110 и т.д.). DSS 110 впоследствии возвращает токен торгово-сервисному предприятию 106, непосредственно или через являющееся виртуальным кошельком приложение в вычислительном устройстве 108, посредством чего торгово-сервисное предприятие 106 затем сохраняет токен в привязке к профилю потребителя для последующего использования потребителем 102 в будущих транзакциях с торгово-сервисным предприятием 106 (например, «в файле» и т.д.). Для последующих транзакций с потребителем 102 торгово-сервисное предприятие 106 может затем использовать токен для идентификации платежного счета для оплаты транзакции.

[0018] Альтернативно, DSS 110 может генерировать и предоставлять токен для являющегося виртуальным кошельком приложения в вычислительном устройстве 108, которое в свою очередь, сохраняет токен у себя. Затем, для последующей транзакции являющееся виртуальным кошельком приложение предоставляет токен, в качестве хранящегося у себя, вместо того, чтобы использовать токен «в файле» в торгово-сервисном предприятии 106. Дополнительно, для последующих транзакций потребитель 102, или являющееся виртуальным кошельком приложение в вычислительном устройстве 108, может непосредственно предоставить идентификатор счета (например, PAN и т.д.) для оплаты дальнейшей транзакции, вместо использования токена «в файле» в торгово-сервисном предприятии 106 или токена, предоставленного являющемуся виртуальным кошельком приложению.

[0019] Также, транзакции между потребителем 102 и торгово-сервисным предприятием 106 могут включать в себя один или более токенов, или идентификатор счета (например, PAN и т.д.), предоставленный потребителем 102. Каждый тип транзакции обрабатывается так, как описано ниже, хотя и несколько по-другому, как указано.

[0020] В частности, в системе 100, когда потребитель 102 просматривает через браузер один или более продуктов (например, товары, услуги и т.д.) в торгово-сервисном предприятии 106, через вычислительное устройство 108 и в виртуальном местоположении торгово-сервисного предприятия, потребитель 102 может выбрать покупку продукта и дополнительно предоставить сведения, относящиеся к транзакции, и ввод в вычислительном устройстве 108 для дальнейшей проверки, через тракт 112. Проверочные сведения и ввод, принятые от потребителя 102, могут включать в себя, например, выбор платежного счета, соответствующего токену, уже принятому и хранящемуся в торгово-сервисном предприятии 106. Либо, проверочные сведения и ввод могут включать в себя предоставление потребителем 102 токена, идентификатора счета для того же самого платежного счета (для которого уже и был принят упомянутый токен), или идентификатора счета для другого платежного счета, и/или другие сведения транзакции.

[0021] В ответ на проверочный ввод (и/или сведения, предоставленные совместно с ним) торгово-сервисное предприятие 106 выполнено с возможностью взаимодействия с вычислительным устройством 108, посредством чего вычислительное устройство 108, будучи выполненным с являющимся кошельком приложением (не изображено), генерирует криптограмму на основе пары открытого и закрытого ключей или на основе симметричного ключа (например, секретного ключа, сгенерированного посредством симметричного алгоритма и т.д.), которые связаны с платежным счетом потребителя и являющегося кошельком приложением (и известны или совместно используются с DSS 110, например). Криптограмма может быть сгенерирована являющимся виртуальным кошельком приложением, локально в вычислительном устройстве 108 (например, цифровой защищенный дистанционный платеж (digital secure remote payment, DSRP), сгенерированный кошельком), или она может быть сгенерирована на основе одного или более взаимодействий с другими системами (например, службой цифрового защищенного дистанционного платежа (DSRP), содержащейся в DSS 110, или другой системой(ами) и т.д.) (например, через службу(ы) в облаке, и т.д.) и предоставлена торгово-сервисному предприятию 106 через являющееся виртуальным кошельком приложение. В данном примерном варианте осуществления криптограмма является криптограммой токена и, в частности, является криптограммой DSRP. Тем не менее, следует понимать, что другие криптограммы токена могут быть сгенерированы и/или использоваться в других вариантах осуществления системы.

[0022] Вычислительное устройство 108, будучи выполненное с являющимся кошельком приложением, затем передает криптограмму DSRP торгово-сервисному предприятию 106.

[0023] Кроме того, являющееся кошельком приложение (либо локально на вычислительном устройстве 108, либо на одном или более серверах обработки баз данных) поддерживает счетчик транзакций приложения (application transaction count, ATC) и увеличивает на единицу ATC для каждой криптограммы DSRP, сгенерированной для платежного счета потребителя (то есть либо индивидуальным для токена для платежного счета, либо нет). В изображенном варианте осуществления ATC является индивидуальным для токена, посредством чего, даже когда платежный счет имеет множество токенов, каждый из токенов будет связан с отдельно взятым ATC, например, для препятствования ответных атак, связанных с этим.

[0024] Когда криптограмма DSRP принимается в торгово-сервисном предприятии 106, серверное программное расширение (плагин) 114 торгово-сервисного предприятия (merchant plug-in, MPI), связанное с торгово-сервисным предприятием 106 выполнено с возможностью формировать запрос аутентификации (AReq) для транзакции. Когда транзакция вовлекает токен, предоставленный торгово-сервисному предприятию 106, AReq включает в себя по меньшей мере упомянутый токен и криптограмму DSRP, принятую от вычислительного устройства 108. В качестве альтернативной возможности, когда транзакция не включает в себя упомянутый токен (или другой токен), то AReq включает в себя по меньшей мере идентификатор счета для платежного счета потребителя, такой как, например, PAN и т.д., и криптограмму DSRP. MPI 114 выполнен с возможностью передавать затем AReq, через тракт 116, на сервер 118 каталогов, включенный в систему 100. Несмотря на то, что примерная система 100 включает в себя MPI 114, следует понимать, что MPI 114 может быть одним или более другими серверами, и/или службами, подходящими для конкретной усовершенствованной аутентификации, включенной здесь (например, посредством чего MPI 114 может упоминаться в качестве сервера 3DS (для спецификации 3DS EMV) и т.д.), или чем-либо иным.

[0025] В данном примерном варианте осуществления, когда AReq включает в себя токен, предоставленный торгово-сервисному предприятию 106, сервер 118 каталогов выполнен с возможностью принимать AReq и передавать токен и криптограмму DSRP, из AReq, в DSS 110, через тракт 120.

[0026] DSS 110, в свою очередь, выполнен с возможностью отображать принятый токен в идентификатор счета (например, PAN и т.д.) для платежного счета потребителя и генерировать случайное значение сервера каталогов (directory server nonce, DSN). DSN может включать в себя число, например, непредсказуемое число, используемое для обеспечения энтропии в AAV, и/или значение аутентификации эмитента (issuer authentication value, IAV), с ним связанное. Кроме того, DSS 110 выполнен с возможностью проверять достоверность принятой криптограммы DSRP для транзакции (то есть выполнять проверку достоверности криптографического ключа). В частности, DSS 110 выполнен с возможностью вычленять главный ключ из главного симметричного ключа эмитента (например, ключа, сгенерированный в DSS 110, для эмитента 104 и т.д.) и затем вычленять один или более сеансовых ключей из главного ключа (например, на основе ATC, поддерживаемого в DSS 110, и т.д.). DSS 110 выполнен с возможностью использования сеансового(ых) ключа(ей) для проверки достоверности криптограммы DSRP, принятой от сервера 118 каталогов. Дополнительно, когда достоверность криптограммы подтверждена, DSS 110 выполнен с возможностью приращения ATC, например, посредством записи значения ATC в качестве используемого значения (тем самым потенциально предотвращающая его повторное использование) и т.д. Дополнительно, или альтернативно, когда достоверность криптограммы DSRP не подтверждена, DSS 110 выполнен с возможностью хранения данных DSRP в запоминающем устройстве в привязке к ATC и/или DSN (посредством чего достоверность криптограммы DSRP проверится позже, как описано ниже).

[0027] DSS 110 также выполнен с возможностью возвращения идентификатора счета и DSN обратно на сервер 118 каталогов, снова через тракт 120. По меньшей мере в одном варианте осуществления, например, когда AReq не включает в себя ни токена, ни криптограммы, то сервер 118 каталогов может генерировать DSN вместо того, чтобы принять DSN от DSS 110.

[0028] После этого, когда сервер 118 каталогов принимает идентификатор счета от DSS 110, или когда исходный AReq включает в себя идентификатор счета, сервер 118 каталогов может быть выполнен с возможностью осуществлять сжатие некоторых данных, связанных с транзакцией. Например, сервер 118 каталогов может быть выполнен с возможностью определения логарифма суммы транзакции (то есть логарифма суммы), тем самым осуществляя сжатие данных, используемых для представления суммы (например, шести байтовое значение для суммы может кодироваться в двух байтах с возможной ошибкой менее +/-0,02% и т.д.). Сервер 118 каталогов может дополнительно быть выполнен с возможностью определять усеченное хеш-значение идентификатора торгово-сервисного предприятия для торгово-сервисного предприятия 106, снова, тем самым осуществляя сжатие данных, используемых для представления идентификатора (ID) торгово-сервисного предприятия. После вышесказанного следует понимать, что сервер 118 каталогов может быть выполнен с возможностью применения одной или более других методик для осуществления сжатия данных, которые будут использоваться в данном случае или нет, в других вариантах осуществления.

[0029] Затем сервер 118 каталогов выполнен с возможностью предоставления, например, AReq, с идентификатором счета, DSN, логарифмом суммы и усеченным хеш-значением идентификатора торгово-сервисного предприятия, через тракт 122, на сервер 124 управления доступом (access control server, ACS) системы 100. ACS 124 является сервером, управляемым эмитентом 104, либо от имени эмитента 104, как определено в спецификации 3-D Secure™, реализуемой в данном примерном варианте осуществления.

[0030] Таким образом, ACS 124 выполнен с возможностью оценивать риск транзакции (например, на основе суммы транзакции, типе вовлеченного торгово-сервисного предприятия, потребителя 102, информации об устройстве потребителя (например, повторяющемся устройстве и т.д.) и т.д.). Если риск не является приемлемым (на основе вышеупомянутого анализа/аутентификации), то ACS 124 может быть выполнен с возможностью дополнительного предоставления контрольного вопроса, в соответствии с традиционными методиками, для аутентификации потребителя 102, отклонения транзакции или иного продолжения, и т.д. Когда потребитель 102 аутентифицирован, посредством вышеупомянутой основанной на риске оценки или посредством дополнительного контрольного вопроса, или иным образом, то затем ACS 124 выполнен с возможностью генерировать IAV на основе ключа(ей), совместно используемого(ых) с эмитентом 104, криптографической методики (например, функции (HMAC) хеширования по ключу, и т.д.), и одного или более из идентификатора счета, DSN, логарифма суммы и усеченного хеш-значения идентификатора торгово-сервисного предприятия или других данных, и т.д. Таким образом, например, IAV является индивидуальным для потребителя 102, торгово-сервисного предприятия 106, а также транзакции (например, посредством логарифма суммы и т.д.), тем самым препятствуя, в целом, генерированию IAV для одной транзакции и предоставления в запросе авторизации для другой транзакции тому же самому или другому торгово-сервисному предприятию.

[0031] ACS 124 выполнен с возможностью передавать затем IAV на сервер 118 каталогов, снова, через тракт 122, в качестве ответа аутентификации (ARes).

[0032] В качестве необязательной возможности, ACS 124 может дополнительно аутентифицировать потребителя 102 через контрольный вопрос, когда основанная на риске аутентификация предлагает это. В частности, как указано пунктирными трактами на Фиг. 1, ACS 124 может быть выполнен с возможностью отвечать с помощью ARes на сервер 118 каталогов, по тракту 126, где ARes дополнительно включает в себя контрольный указатель (например, сетевой адрес, который должен быть вызван торгово-сервисным предприятием 106 и т.д.). В данном примере сервер 118 каталогов может быть выполнен с возможностью принимать затем ARes от ACS 124 и передавать ARes в торгово-сервисное предприятие 106 (через MPI 114 или сервер 3DS и т.д.), через тракт 128. В свою очередь, торгово-сервисное предприятие 106 и, в частности, виртуальное местоположение торгово-сервисного предприятия (например, веб-страничка и т.д.) может идентифицировать контрольный указатель и вызвать или иным образом задействовать контрольную процедуру, тем самым предоставляя взаимодействие, через тракт 130, между вычислительным устройством 108 потребителя и ACS 124. Взаимодействие, в целом, включает в себя представление контрольного вопроса (например, «Введите свой личный код» и т.д.), после чего потребитель 102 предоставляет ответ, через тракт 130. И ACS 124 выполнен с возможностью подтверждения ответа потребителя 102. После этого, при подтверждении, ACS 124 выполнен, в соответствии с вышеупомянутым, с возможностью генерировать IAV и затем генерировать ответ, включающий в себя IAV, и передавать ответ на сервер 118 каталогов, через тракт 126.

[0033] По получении IAV от ACS 124 сервер 118 каталогов выполнен с возможностью генерировать код аутентификации сообщения (message authentication code, MAC) для полного AAV (то есть данные, которые должны быть включены в AAV (например, DSN, логарифм суммы, усеченное хеш-значение идентификатора торгово-сервисного предприятия, код валюты, идентификатор ключа и т.д.), и затем формировать полное AAV. Полное AAV включает в себя IAV, DSN, сумму и информацию о торгово-сервисном предприятии, и информацию подписи (например, идентификатор ключа и MAC), и т.д. Следует понимать, что данные, включенные в полное AAV, могут изменяться на основе конкретного варианта реализации этого, посредством чего полное AAV может включать в себя больше или меньше данных, но будет, в целом, включать в себя IAV от ACS 124.

[0034] После этого, сервер 118 каталогов выполнен с возможностью предоставления полного AAV в MPI 114 (или сервер 3DS), снова через тракт 116.

[0035] В свою очередь, торгово-сервисное предприятие 106 выполнено с возможностью формировать запрос авторизации для транзакции, который включает в себя токен или идентификатор счета для платежного счета потребителя, по необходимости, и также полное AAV. Торгово-сервисное предприятие 106 выполнено с возможностью передавать затем запрос авторизации эквайеру 132, через тракт 134. Эквайер 132, в свою очередь, выполнен с возможностью передавать запрос авторизации в платежную сеть 136, через тракт 138.

[0036] По получении запроса авторизации платежная сеть 136 может быть выполнена с возможностью взаимодействия с DSS 110, через тракт 140 (несмотря на то, что это не обязательно во всех вариантах осуществления (например, где платежной сети 136 известен подходящий(ие) ключ(и) и т.д.)). В частности, платежная сеть 136 может быть выполнена с возможностью проверять достоверность MAC, включенного в полное AAV, и/или полное AAV непосредственно. Платежная сеть 136 может дополнительно быть выполнена с возможностью иным образом проверять достоверность и/или подтверждать полное AAV, или его часть, например, на основе информации о версии, включенной в полное AAV.

[0037] После того, как достоверность подтверждена, платежная сеть 136 выполнена с возможностью предоставления запроса авторизации, или его части, в DSS 110. DSS 110 выполнен с возможностью подтверждения достоверности криптограммы DSRP на основе DSN, когда достоверность криптограммы DSRP была предварительно подтверждена в DSS 110. Наоборот, DSS 110 выполнен с возможностью определять местоположение данных DSRP для транзакции, при помощи DSN (или ATC, включенного там), и проверять достоверность данных DSRP, как описано выше. Кроме того, DSS 110 также выполнен с возможностью отображать токен, включенный в запрос авторизации, при наличии такового, в соответствующий идентификатор счета (например, PAN и т.д.).

[0038] DSS 110 выполнен с возможностью возвращать затем идентификатор счета и результат проверки достоверности в платежную сеть 136, через тракт 140. Применительно к вышесказанному платежная сеть 136 и/или DSS 110 могут быть дополнительно выполнены с возможностью предоставления дополнительных служб для транзакции на основе платежного счета и/или потребителя 102. Например, DSS 110 может быть выполнен с возможностью определять, удовлетворены ли одно или более требований использования токена (например, токену предоставлена возможность использоваться в электронной коммерции и т.д.), или, в качестве необязательной возможности, проверять сумму транзакции, название торгово-сервисного предприятия и валюту, и т.д.

[0039] После этого, платежная сеть 136 выполнена с возможностью предоставления запроса авторизации (включающего в себя идентификатор счета и результат проверки достоверности) эмитенту 104, по тракту 142.

[0040] Затем, эмитент 104 выполнен с возможностью определять, должна ли транзакция быть одобрена или отклонена, и отвечать соответственно, через платежную сеть 136. Чтобы сделать так, эмитент 104 выполнен с возможностью проверять достоверность IAV на основе одного или более совместно используемого(ых) ключа(ей) с ACS 124. Достоверность IAV, более конкретно, может быть проверена точно таким же образом, как оно было сгенерировано выше, например, на основе секретного ключа, той же самой криптографической методики, используемой в ACS 124, и идентификатора счета, DSN, логарифма суммы и усеченного хеш-значения идентификатора торгово-сервисного предприятия, или других данных, и т.д. Дополнительно, или альтернативно, эмитент 104 может быть выполнен с возможностью усиления одной или более сетевых служб (посредством платежной сети 136, например), которая уже проверила достоверность AAV (как указано результатом проверки достоверности), для одобрения транзакции. К тому же, эмитент 104 может быть выполнен с возможностью проверять достоверность суммы транзакции (то есть суммы, указанной в запросе авторизации) на основе логарифма суммы из AAV (или, в качестве необязательной возможности, несжатой суммы), а также торгово-сервисного предприятия транзакции (то есть торгово-сервисное предприятие, указанное в запросе авторизации) на основе усеченного хеш-значения идентификатора торгово-сервисного предприятия из AAV и т.д. Как только определение сделано, эмитент 104 выполнен с возможностью передавать ответ авторизации (включающий в себя идентификатор счета потребителя) обратно в платежную сеть 136, по тракту 142. В свою очередь, платежная сеть 136 выполнена с возможностью направления ответа авторизации (включающего в себя токен или идентификатор счета) обратно эквайеру 132, через тракт 138. Эквайер 132, в свою очередь, выполнен с возможностью предоставления ответа авторизации (включающего в себя токен или идентификатор счета) обратно торгово-сервисному предприятию 106, непосредственно или через MPI 114, по тракту 134.

[0041] В данном месте транзакция одобряется (в данном примере), и торгово-сервисное предприятие 106 может направить выбранный продукт, который будет доставлен потребителю 102.

[0042] Следует понимать, что каждый из эмитента 104, торгово-сервисного предприятия 106, вычислительного устройства 108, DSS 110, MPI 114, сервера 118 каталогов, ACS 124, эквайера 132 и платежной сети 136, и т.д., реализованы в данном документе в одном или более вычислительных устройствах, таких как вычислительное устройство 200, изображенное на Фиг. 2. В связи с этим, каждое из упомянутых одного или более вычислительных устройств выполнено с возможностью осуществления связи с одним или более другими субъектами через по меньшей мере одну сеть. В целом, каждый из трактов, включенных на Фиг. 1, по которому, или через который, осуществляется обмен сообщениями в описании выше, представляют собой сеть(и). Сеть(и) может(могут) включать в себя, без ограничений, одну или более местных сетей (local area network, LAN), глобальных сетей (wide area network, WAN) (например, Интернет, и т.д.), сети мобильной связи, виртуальные сети, другие сети, описываемые в данном документе, и/или другие подходящие общедоступные и/или частные сети, выполненные с возможностью поддержки связи между двумя или более из изображенных частей, или даже их сочетаний. В одном примере сеть включает в себя множество сетей, где разные сети из множества сетей доступны для других из изображенных компонентов на Фиг. 1. В частности, платежная сеть 136 и DSS 110 могут быть соединены через частную сеть, и, по отдельности, торгово-сервисное предприятие 106 и вычислительное устройство 108 могут быть соединены через общедоступную сеть, такую как Интернет.

[0043] На Фиг. 2 показано примерное вычислительное устройство 200, которое может включать в себя, например, один или более серверов, рабочих станций, персональных компьютеров, ноутбуков, планшетов, смартфонов, других подходящих вычислительных устройств и т.д. Кроме того, вычислительное устройство 200 может включать в себя одно вычислительное устройство, или оно может включать в себя множество вычислительных устройств, расположенных в непосредственной близости, или множество вычислительных устройств, распределенных по географической области, пока такие вычислительные устройства специально выполнены с возможностью функционировать так, как описано в данном документе. По меньшей мере в одном варианте осуществления к вычислительному устройству 200 осуществляется доступ (для использования, как описано в данном документе) в качестве вычислительного устройства по типу «облачных», «туманных и/или дымчатых» (осуществляющихся через Интернет вещей) вычислений. В связи с вышесказанным систему 100 не следует рассматривать в качестве ограниченной вычислительным устройством 200, как описано ниже, поскольку могут использоваться другие вычислительные устройства и/или компоновки вычислительных устройств. Кроме того, другие компоненты и/или компоновки компонентов могут использоваться в других вычислительных устройствах.

[0044] Как показано на Фиг. 2, примерное вычислительное устройство 200 включает в себя процессор 202 и запоминающее устройство 204, соединенное с (и выполненное с возможностью осуществления связи с) процессором 202. Процессор 202 может включать в себя один или более блоков обработки (например, многоядерную конфигурацию и т.д.). Например, процессор 202 может включать в себя, без ограничений, центральный блок обработки (CPU), микроконтроллер, процессор компьютера с сокращенной системой команд (RISC), специализированную интегральную схему (ASIC), программируемое логическое устройство (PLD), вентильную матрицу и/или любую другую схему или процессор с поддержкой функций, описанных в данном документе.

[0045] Запоминающее устройство 204, описанное в данном документе, является одним или более устройствами, которое предоставляет возможность сохранения в себе и извлечения из себя данных, инструкций и т.д. Запоминающее устройство 204 может включать в себя один или более машиночитаемых носителей хранения информации, таких как, без ограничений, динамическое запоминающее устройство с произвольным доступом (DRAM), статическое запоминающее устройство с произвольным доступом (SRAM), постоянное запоминающее устройство (ROM), стираемое программируемое постоянное запоминающее устройство (EPROM), твердотельные устройства, флэш-накопители, CD-ROM, карты флэш-памяти, гибкие диски, ленты, жесткие диски и/или любой другой тип физического или материального машиночитаемого носителя кратковременного или долговременного хранения. Запоминающее устройство 204 может быть выполнено с возможностью хранения, без ограничений, значений IAV, значений AAV, запросов аутентификации, ключей, кодов MAC, криптограмм DSRP, токенов, идентификаторов счетов (например, PAN, и т.д.), и/или других типов данных (и/или структур данных), подходящих для использования, описанного в данном документе. Кроме того, в различных вариантах осуществления, машиноисполняемые инструкции могут быть сохранены в запоминающем устройстве 204 для исполнения процессором 202 с целью предписания процессору 202 выполнять одну или более из функций, описанных в данном документе, так что запоминающее устройство 204 является физическим, материальным и долговременным машиночитаемым носителем хранения информации. Такие инструкции зачастую повышают эффективность и/или производительность процессора 202 и/или других компонентов вычислительной системы, выполненных с возможностью выполнения одного или более из различных действий (операций) в данном документе. Следует понимать, что запоминающее устройство 204 может включать в себя множество различных запоминающих устройств, каждое из которых реализовано в одной или более из функций или процессов, описанных в данном документе.

[0046] В примерном варианте осуществления вычислительное устройство 200 также включает в себя устройство 206 вывода, которое соединено с (и то есть выполнено с возможностью осуществления связи с) процессором 202. Устройство 206 вывода выводит информацию, такую как подтверждения покупок, контрольные вопросы и т.д., например, визуально потребителю 102 или другую информацию другим пользователям, связанным с любым из субъектов, изображенных на Фиг. 1, в соответственном вычислительном устройстве, и т.д. Устройство 206 вывода может включать в себя, без ограничений, дисплей на жидких кристаллах (дисплей LCD), светодиодный (LED) дисплей, дисплей на органических светодиодах (дисплей OLED), дисплей на основе «электронных чернил», громкоговорители и т.д. В некоторых вариантах осуществления устройство 206 вывода может включать в себя множество устройств.

[0047] Кроме того, вычислительное устройство 200 включает в себя устройство 208 ввода, которое принимает ввод от пользователя (то есть, пользовательский ввод), такой как, например, ответы на контрольные вопросы, проверочный ввод, реквизиты платежного счета и т.д., от потребителя 102 или другую информацию от других пользователей в системе, и т.д. Устройство 208 ввода может включать в себя одно устройство ввода или множество устройств ввода. Устройство 208 ввода соединено с (и выполнено с возможностью осуществления связи с) процессором 202, и может включать в себя, например, одно или более из клавиатуры, координатно-указательного устройства, компьютерной мыши, чувствительной к прикосновению панели (например, сенсорной контактной панели или сенсорный экран и т.д.), другое вычислительное устройство и/или устройство звукового ввода. Дополнительно, в различных примерных вариантах осуществления сенсорный экран, в частности, который включен в планшет, смартфон или подобное устройство, может функционировать в качестве как устройства 206 вывода, так и устройства 208 ввода.

[0048] Дополнительно, изображенное вычислительное устройство 200 также включает в себя сетевой интерфейс 210, соединенный с (и выполненный с возможностью осуществления связи с) процессором 202 и запоминающим устройством 204. Сетевой интерфейс 210 может включать в себя, без ограничений, адаптер проводной сети, адаптер беспроводной сети, адаптер сети мобильной связи или другое устройство с поддержкой связи с одной или более других сетей и/или одним или более другими вычислительными устройствами в данном документе.

[0049] На Фиг. 3 показан примерный способ 300 для предоставления услуг для потребителя применительно к транзакции, осуществляемой потребителем в торгово-сервисном предприятии, и дополнительно совместно с усовершенствованной аутентификацией потребителя. Примерный способ 300 описан (со ссылкой на Фиг.1) в качестве, в целом, реализованного в DSS 110, сервере 118 каталогов и платежной сети 136 системы 100, и с дополнительной ссылкой на вычислительное устройство 200. Как должно быть понятно, однако, способы в данном документе не следует считать ограниченными примерной системой 100 или примерным вычислительным устройством 200, и системы и вычислительные устройства в данном документе не следует считать ограниченными примерным способом 300.

[0050] В изображенном способе 300, для транзакции, инициированной потребителем 102 с торгово-сервисным предприятием 106, сервер 118 каталогов первоначально принимает, на этапе 302, AReq от MPI 114 (или от сервера 3DS), связанного с торгово-сервисным предприятием 106. AReq включает в себя токен, в данном примерном варианте осуществления, для платежного счета потребителя 102 (используемого в транзакции), а также криптограмму DSRP (называемую «крипто» (англ. «crypto») на Фиг. 3) для транзакции. В ответ сервер 118 каталогов передает, на этапе 304, токен и криптограмму DSRP в DSS 110. Сервер 118 каталогов поступает так, в данном примере, потому что токен находится внутри диапазона токенов (или диапазона BIN (идентификатора банка) для PAN), связанного со способами, описанными в данном документе.

[0051] DSS 110, в свою очередь, отображает токен в идентификатор счета для платежного счета потребителя, то есть, в PAN в данном примере, на этапе 306. И DSS 110 также (в качестве необязательной возможности) проверяет достоверность криптограммы DSRP, на этапе 308. Проверка достоверности криптограммы DSRP, в данном варианте осуществления, основана на симметричном ключе, который совместно используется между платежным счетом потребителя и/или являющимся кошельком приложением, которому предоставлен токен для платежного счета, и DSS 110. Более подробно, DSS 110 вычленяет главный ключ из главного симметричного ключа эмитента (например, сгенерированного в DSS 110 для эмитента 104, и т.д.) и затем вычленяет один или более сеансовых ключей из главного ключа (например, на основе ATC, поддерживаемого в DSS 110 и т.д.). DSS 110 затем использует сеансовый(ые) ключ(и) для проверки достоверности криптограммы DSRP.

[0052] Альтернативно, вместо проверки достоверности криптограммы DSRP, DSS 110 может сохранить криптограмму DSRP в запоминающем устройстве (например, запоминающем устройстве 204 и т.д.) для повторного вызова, как описано ниже (например, на основе DSN и т.д.).

[0053] Когда достоверность криптограммы DSRP не подтверждена, то DSS 110 отвечает серверу 118 каталогов сообщением отказа в транзакции, которое, в свою очередь, может быть предоставлено обратно торгово-сервисному предприятию 106 и/или MPI 114 (или серверу 3DS) (посредством чего транзакция может быть остановлена), или обработано иначе по указанию от эмитента 104 (например, эмитент 104 может предоставить возможность продолжения транзакции без проверки достоверности и т.д.). Наоборот, когда достоверность криптограммы DSRP успешно подтверждена, DSS 110 генерирует, на этапе 310, DSN. DSN включает в себя, например, связку из ATC, или его части (например, младший значащий байт и т.д.) и непредсказуемое значение (например, произвольно сгенерированное значение, хеш-функцию на основе закрытого ключа DSS 110, или вычисление MAC на основе закрытого ключа, или другое подходящее значение и т.д.). Несмотря на то, что DSN может иметь любую подходящую длину и/или формат, в примерном варианте осуществления на Фиг. 3 DSN включает в себя четырехбайтовый формат (то есть, 32 бита) (например, младший значащий байт у ATC и три байта произвольно сгенерированного значения, и т.д.). Несмотря на вышесказанное, в качестве необязательной возможности, DSS 110 может генерировать DSN, на этапе 310, когда криптограмма DSRP сохраняется, а не проверяется ее достоверность, на этапе 308, в способе 300.

[0054] Когда достоверность криптограммы DSRP подтверждена, на этапе 308, DSS 110 дополнительно обозначает ATC, какой используется или «на лету», посредством чего он может использоваться при продвижении вперед в способе 300 в дальнейшем запросе авторизации, как предусмотрено ниже, но не для какой-либо другой цели (например, препятствует другому AReq с той же самой криптограммой DSRP и т.д.). Затем в способе 300, DSS 110 передает DSN и идентификатор счета, связанный с токеном, на этапе 312, на сервер 118 каталогов.

[0055] На этапе 314, сервер 118 каталогов вычисляет логарифм суммы транзакции (то есть, логарифм суммы) и, на этапе 316, также вычисляет усеченное хеш-значение идентификатора торгово-сервисного предприятия (например, название и/или местоположение и т.д.). Несмотря на то, что вычисляется логарифм суммы (например, тем самым уменьшая 4-6 байтов, представляющих сумму, до 2 байтов в логарифме суммы и т.д.), следует понимать, что в других вариантах осуществления могут использоваться другие методики для сжатия суммы или нет. Аналогично, идентификатор торгово-сервисного предприятия может быть сжат в других вариантах осуществления, или нет, посредством одной или более методик, выходящих за усечение и/или хеширование или отличающихся от них. В целом, однако, сжатая сумма и идентификатор торгово-сервисного предприятия, если таковые вообще имеются, обеспечат сокращение данных (или пространства) над предоставлением несжатой суммы и/или несжатого идентификатора торгово-сервисного предприятия.

[0056] После этого, сервер 118 каталогов передает AReq, включающий в себя идентификатор счета для платежного счета потребителя, DSN, вычисленный логарифм суммы и усеченное хеш-значение идентификатора торгово-сервисного предприятия в ACS 124, на этапе 318. Таким образом, сервер 118 каталогов идентифицирует конкретный ACS 124 на основе идентификатора счета потребителя и, в частности, на основе BIN идентификатора счета, находящегося внутри конкретного диапазона, или на основе других указателей, включенных в весь AReq или в его часть. В других вариантах осуществления AReq может дополнительно включать в себя флаг детокенизации, указывающий в ACS 124 то, что AReq включает в себя идентификатор счета (преобразованный в DSS 110 из токена).

[0057] ACS 124, как описано выше, в свою очередь выполнит основанную на риске финансовую оценку для транзакции, посредством чего ACS 124 будет аутентифицировать или не аутентифицировать потребителя 102. В качестве необязательной возможности, как это традиционно делается, ACS 124 может использовать сервер 118 каталогов для инициирования контрольного вопроса потребителю 102, посредством чего потребитель 102 аутентифицируется через взаимодействие с ACS 124. Затем, как только потребитель 102 аутентифицирован, независимо от того, было ли это основанной на риске оценкой, контрольным вопросом или чем-либо иным, ACS 124 генерирует, на этапе 320, IAV для транзакции, которое включает в себя, например, логарифм или несжатую сумму, усеченное хеш-значение идентификатора торгово-сервисного предприятия и код валюты для транзакции, и т.д. В целом, в данном примерном варианте осуществления, IAV будет содержать 4 байта значения, содержащего криптографически сгенерированное значение HMAC. Однако следует понимать, что в других вариантах осуществления для генерирования IAV могут использоваться другие криптографические методики. И IAV затем передается, посредством ACS 124, на сервер 118 каталогов, на этапе 322 (посредством чего сервер 118 каталогов принимает IAV).

[0058] Наоборот, если аутентификация потребителя 102 неуспешна, то ACS 124 сообщает об отказе в аутентификации на сервер 118 каталогов (или, возможно, отвечает иначе, как предписано эмитентом 104, например), который передается в MPI 114 (или сервер 3DS) и торгово-сервисное предприятие 106 (посредством чего торгово-сервисное предприятие 106 может остановить или отклонить транзакцию и т.д.).

[0059] Затем, сервер 118 каталогов генерирует, на этапе 324, MAC и формирует, на этапе 326, полное AAV для транзакции. В частности, в данном примерном варианте осуществления, сервер 118 каталогов объединяет IAV (принятый от ACS 124), DSN, логарифм суммы, код валюты и усеченное хеш-значение идентификатора торгово-сервисного предприятия (и возможно другие данные управления), и затем генерирует MAC (например, на основе вышеупомянутых данных, симметричного ключа и криптографической функции, и т.д.), и т.д. Сервер 118 каталогов формирует из вышеупомянутых данных и MAC полное AAV. На Фиг. 4 показана блок-схема примерного полного AAV 400, который включает в себя 21 байт двоичных данных. В частности, IAV включает в себя 4 байта, DSN включает в себя 4 байта, логарифм суммы включает в себя 2 байта, усеченное хеш-значение идентификатора торгово-сервисного предприятия включает в себя 4 байта, код валюты включает в себя 1,5 байта, идентификатор ключа (то есть, идентификатор совместно используемого ключа, используемого для генерирования MAC), включает в себя 0,5 байта, и MAC включает в себя 3 байта. Полное AAV 400 дополнительно включает в себя 2 байта информации о версии, которая указывает, например, тип IAV при аутентификации полностью, попытку торгово-сервисного предприятия и формат, или что-либо иное, и т.д. В связи с вышесказанным следует понимать, что полное AAV 400 может включать в себя одни и те же или другие данные в других вариантах осуществления, в одном или более различных форматах и/или в одном или более различных размерах, но будет в целом включать в себя по меньшей мере IAV и DSN для содействия дальнейшим этапам (как описано ниже).

[0060] Сервер 118 каталогов затем передает, на этапе 328, полное AAV торгово-сервисному предприятию 106 и, в частности, в MPI 114 (или серверу 3DS).

[0061] В свою очередь, несмотря на то, что не изображено на Фиг. 3, торгово-сервисное предприятие 106 формирует и передает запрос авторизации для транзакции эквайеру 132, с полным AAV, включенным в этот запрос. В одном конкретном примере полное AAV включено в UCAF, который находится в элементе данных (DE) 48 запроса авторизации согласно стандарту ISO 8583. Сформированный запрос авторизации в целом включает в себя другие данные, традиционно присутствующие в запросе авторизации (например, идентификатор торгово-сервисного предприятия, имя потребителя, сумма транзакции, реквизит(ы) платежного счета и т.д.). Запрос авторизации затем передается от эквайера 132 и принимается в платежной сети 136, на этапе 330.

[0062] По получении запроса авторизации платежная сеть 136 проверяет достоверность, на этапе 332, полного AAV, в частности, посредством проверки достоверности MAC, включенного в полное AAV. В частности, платежная сеть 136 определяет местоположение совместно используемого ключа, по которому MAC был сгенерирован сервером 118 каталогов, на основе идентификатора ключа в полном AAV. Платежная сеть 136 затем генерирует MAC на основе совместно используемого ключа и данных, включенных в полное AAV (в соответствии с данными, которые использует сервер 118 каталогов для генерирования MAC на этапе 324). После генерирования платежная сеть 136 сопоставляет этот MAC с MAC, включенным в полное AAV, тем самым проверяя достоверность MAC и/или полного AAV. Достоверность MAC проверяется, в данном варианте осуществления, перед предоставлением возможности передачи запроса авторизации эмитенту 104. Однако следует понимать, что дальнейшая проверка достоверности и/или тестирование полного AAV могут быть включены здесь в других вариантах осуществления (например, на основе информации о версии в полном AAV и т.д.).

[0063] После подтверждения достоверности платежная сеть 136 передает запрос авторизации, включающий в себя токен (или идентификатор счета, по необходимости) и DSN, или в качестве необязательной возможности, полное AAV, в DSS 110, на этапе 334. По получению DSS 110 либо подтверждает проверку достоверности криптограммы DSRP, на основе DSN (при подтверждении достоверности на этапе 308), или проверяет достоверность криптограммы DSRP, на основе данных DSRP, содержащихся в запоминающем устройстве (например, в запоминающем устройстве 204, и т.д.) и расположенных на основе DSN, на этапе 336. Кроме того, DSS 110 отображает токен, включенный в запросе авторизации, в связанный идентификатор счета (например, PAN и т.д.) на этапе 338. После этого, DSS 110 возвращает идентификатор счета и результат проверки достоверности в платежную сеть 136, на этапе 340. В свою очередь, платежная сеть 136 отправляет запрос авторизации эмитенту 104, на этапе 342, включающий в себя по меньшей мере идентификатор счета, подтверждение достоверности криптограммы DSRP и данные из полного AAV, включающие IAV.

[0064] В ответ эмитент 104 проверяет достоверность IAV на основе совместно используемого ключа между эмитентом 104 и ACS 124 (то есть ключа, используемого для генерирования IAV) и, возможно, выполняет одну или более финансовых оценок для транзакции, на этапе 344. Дополнительные финансовые оценки могут быть выполнены на любой традиционной или другой базе (например, на основе того, находится ли платежный счет потребителя в хорошем состоянии, включает ли платежный счет в себя достаточно денежных/кредитных средств, показателе мошенничества и т.д.). Как только достоверность транзакция подтверждена и/или транзакция одобрена, эмитент 104 формирует ответ авторизации для транзакции и передает ответ авторизации, на этапе 346, обратно в платежную сеть 136. Платежная сеть 136 затем передает, на этапе 348, ответ авторизации торгово-сервисному предприятию 106, через эквайера 132. Наоборот, если достоверность транзакции не подтверждена, эмитент 104 может принять решение по учету риска и продолжить транзакцию, через подходящий ответ авторизации, или отклонить транзакцию, снова, посредством ответа авторизации, переданного обратно торгово-сервисному предприятию 106, как описано выше.

[0065] Несмотря на то, что способ 300 описан со ссылкой на использование токена в транзакции, следует понимать, что способ 300 также применим к транзакциям, в которых запрос авторизации включает в себя PAN или другой идентификатор счета вместо токена, посредством чего могут быть опущены некоторые этапы, относящиеся в частности к обработке токена и/или отображению токена в счет в способе 300. К тому же, когда токен является неизвестным или незарегистрированным на сервере 118 каталогов и/или DSS 110, тем самым исключая отображение токена в идентификатора счета, вместо этого эмитент 104 и/или ACS 124 может обработать токен. В данном варианте, несмотря на в целом соответствие описанию выше, как только предоставлена криптограмма, ACS 124 осуществит связь с другим DSS, связанным с заданным токеном (не изображено), для выполнения проверки достоверности криптограммы и других токенизированных служб. Кроме того, ACS 124 может генерировать DSN (вместо того, чтобы полагаться на сервер 118 каталогов), которое затем возвращается на сервер 118 каталогов наряду с IAV, для использования так, как это описано в данном документе.

[0066] Ввиду вышесказанного, системы и способы данного документа предоставляют проверку достоверности на двух различных сторонах через полное AAV. В частности, например, AAV разделяется на IAV, которое генерируется и чья достоверность проверяется на стороне ACS/эмитента, и на другие данные, которые генерируются и чья достоверность проверяется на стороне платежной сети. Посредством разделения AAV таким образом, системы и способы в данном документе предоставляют возможность эмитенту 104 и ACS 124 препятствовать мошенническим транзакциям через IAV, что является независимым от операций, выполняемых для генерирования и проверки достоверности других данных, связанных с AAV. Как таковые, платежная сеть 136, сервер 118 каталогов и/или DSS 110 могут быть изменены для изменения и/или улучшения защиты и/или функциональности в данном документе, в целом, не влияя на функционирование и/или взаимодействие эмитента 104 и ACS 124 (например, изолируя IAV от изменения формата или других частей UCAF и т.д.). К тому же, платежная сеть 136 способна обеспечивать проверку достоверности транзакций, как описано выше, и предоставлять такую проверку достоверности эмитенту 104 в качестве дополнительных данных, связанных с одобрением или отклонением транзакций.

[0067] Следует понимать, что вышесказанное является отходом от традиционного AAV, где ACS 124 генерирует весь AAV, достоверность которого затем может быть проверена только эмитентом 104 (поскольку ACS использовал ключи эмитента для такого генерирования). Кроме того, как очевидно из описания выше, не требуется, чтобы совместно используемый(ые) ключ(и), используемый(ые) для генерирования и проверки достоверности IAV (то есть ключи эмитента и ACS), совместно использовался(ись) с сервером 118 каталогов (или платежной сетью 136), и наоборот, не нужно, чтобы ключ(и), используемый(ые) сервером 118 каталогов и/или платежной сетью 136 для генерирования и проверки достоверности MAC, совместно использовался(ись) с ACS 124 и/или эмитентом 104. По такому принципу, управление ключами в системах и способах в данном документе оптимизировано и упрощено.

[0068] Снова, и как описано ранее, следует понимать, что функции, описанные в данном документе, в некоторых вариантах осуществления, могут быть описаны в машиноисполняемых инструкциях, хранящихся на машиночитаемом носителе, и исполняемы одним или более процессорами. Машиночитаемый носитель является долговременным машиночитаемым носителем хранения информации. В качестве примера, а не ограничения, такой машиночитаемый носитель может включать в себя RAM, ROM, EEPROM, CD-ROM или другое хранилище на оптических дисках, запоминающее устройство на магнитных дисках или другие магнитные устройства хранения, или любой другой носитель, который может использоваться для переноса или хранения необходимого программного кода в виде инструкций или структур данных, и к которому может осуществлять доступ компьютер. Сочетания вышесказанного должны также быть включены в объем машиночитаемого носителя.

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

[0070] Как должно быть понятно на основе предшествующего описания, вышеописанные варианты осуществления раскрытия могут быть реализованы с использованием методик компьютерного программирования или проектирования, включающих в себя программное обеспечение, встроенное микропрограммное обеспечение, аппаратное обеспечение или любое их сочетание или поднабор, при этом технический результат может быть достигнут посредством выполнения по меньшей мере одного из упомянутых следующих этапов: (a) прием, посредством по меньшей мере одного вычислительного устройства, запроса аутентификации транзакции, связанной с платежным счетом, причем запрос аутентификации включает в себя токен, связанный с платежным счетом, и криптограмму; (b) отображение, посредством по меньшей мере одного вычислительного устройства, токена в первичный идентификатор счета (PAN) для платежного счета; (c) проверка достоверности, посредством по меньшей мере одного вычислительного устройства, криптограммы; (d) генерирование, посредством по меньшей мере одного вычислительного устройства, случайного значения сервера каталогов (DSN) для упомянутого запроса аутентификации; (e) передача, посредством по меньшей мере одного вычислительного устройства, DSN и идентификатора счета на сервер управления доступом (ACS), связанный с эмитентом платежного счета; (f) в ответ на значение аутентификации эмитента (IAV), формирование, посредством по меньшей мере одного вычислительного устройства, значения аутентификации держателя счета (AAV), причем AAV включает в себя IAV, DSN и сумму транзакции; (g) передача AAV одному из торгово-сервисного предприятия и сервера, тем самым предоставляя возможность торгово-сервисному предприятию формировать и передавать запрос авторизации для транзакции, включающий в себя AAV, и предоставляя возможность эмитенту проверить достоверность IAV до одобрения транзакции; (h) осуществление сжатия по меньшей мере одного из суммы транзакции и идентификатора торгово-сервисного предприятия, связанного с торгово-сервисным предприятием; (i) генерирование, посредством по меньшей мере одного вычислительного устройства, кода аутентификации сообщения (MAC), причем AAV включает в себя MAC; (j) проверка достоверности MAC в ответ на запрос авторизации, включающий в себя AAV; (k) отображение токена в PAN после проверки достоверности MAC и передача запроса авторизации с PAN и результатом проверки достоверности эмитенту платежного счета; (l) генерирование, посредством ACS, IAV на основе ключа и по меньшей мере PAN и DSN; и (m) проверка достоверности, посредством вычислительного устройства эмитента, IAV на основе совместно используемого ключа и по меньшей мере PAN и DSN.

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

[0072] Терминология, используемая в данном документе, предназначена только для описания конкретных примерных вариантов осуществления и не носит ограничительного характера. Предполагается, что используемые в данном документе формы единственного числа также включают в себя формы множественного числа, пока контекст ясно не укажет иное. Термины «содержит», «содержащий», «включающий в себя» и «имеющий» являются инклюзивными и поэтому указывают присутствие изложенных признаков, целых чисел, этапов, операций, элементов и/или компонентов, но не исключают наличия или добавления одного или более других признаков, целых чисел, этапов, операций, элементов, компонентов и/или их групп. Не следует полагать, что этапы способа, процессы и операции, описанные в данном документе, обязательно необходимо выполнять в конкретном порядке обсуждения или изображения, если порядок выполнения специально не указан. Нужно также понимать, что могут использоваться дополнительные или альтернативные этапы.

[0073] Когда признак упоминается в качестве находящегося «на», «входящим в зацепление с», «подключенным к», «соединенным с», «связанным с», «включенным с» или «выполненным с возможностью осуществления связи с» другим признаком, то он может непосредственно находиться на, входить в зацепление, подключаться, соединяться, связываться, включаться или осуществлять связь с или к другому признаку, либо могут присутствовать промежуточные признаки. Используемый в данном документе термин «и/или» включает в себя любое и все сочетания одного или более из связанных перечисленных элементов.

[0074] Несмотря на то, что термины первый, второй, третий и т.д. могут использоваться в данном документе для описания различных признаков, эти признаки не должны быть ограничены этими терминами. Эти термины могут быть использованы только для отличия одного признака от другого. Такие термины как «первый», «второй» и другие числительные термины при использовании в данном документе не подразумевают последовательности или порядка следования, если это явно не указано контекстом. Таким образом, первый признак, описанный в данном документе, можно назвать вторым признаком без отступления от замыслов примерных вариантов осуществления.

[0075] Ни один из элементов, изложенных в формуле изобретения, не подразумевается в качестве элемента «средство плюс функция» в пределах значения 112 (f) 35 U.S.C., если элемент явно не изложен с использованием фразы «средство для», или в случае пункта со способом в формуле изобретения с использованием фразы «операция для» или «этап для».

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