УПРАВЛЕНИЕ УНИКАЛЬНОСТЬЮ КЛИЕНТА В ТОКЕНИЗИРОВАННЫХ СИСТЕМАХ Российский патент 2019 года по МПК G06Q20/40 

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

По этой заявке испрашивается приоритет по дате подачи европейской патентной заявки №15181150.2, поданной 14 августа 2015, которая полностью включена в настоящее описание путем ссылки.

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

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

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

Традиционные модели платежа по карте позволяли идентифицировать источник финансирования электронных транзакций, поскольку имелось взаимно-однозначное соответствие между PAN (первичным учетным номером), отображаемым на кредитной или дебетовой карте, и счетом, из которого брались средства для транзакций с использованием упомянутой карты. В случае соответствия "много одному" (например, совместный счет), данные карты остаются исключительно в пределах контроля эмитента. Однако с появлением вторичных платежных устройств, таких как брелоки, наклейки и поддерживающие платежи мобильные устройства (смартфоны, планшеты, умные часы и т.д.), это взаимно-однозначное соответствие потенциально утрачивается, так как вторичные платежные устройства могут использовать PAN, отличающиеся от исходной карты. Вторичные платежные устройства, которые используют токенизированные PAN, теряют это взаимно-однозначное соответствие. Это происходит потому, что когда из соображений безопасности каждое новое вторичное платежное устройство настраивается для обеспечения функциональности платежей (например, посредством NFC, коммуникации ближнего поля, с платежными терминалами), оно обеспечивается уникальным токеном, известным как DPAN (PAN устройства), отличающимся от FPAN (PAN финансирования) на карте, связанной со счетом. DPAN является PAN, который устройство передает торговым терминалам для платежа. Торговые системы не знают, передаются ли им DPAN или FPAN; платежи обрабатываются одинаковым образом с их точки зрения. Однако это означает, что торгово-сервисное предприятие не может никаким образом узнать, что FPAN и один или более DPAN, используемых для совершения транзакций в их терминалах, финансируются с одного и того же счета.

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

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

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

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

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

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

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

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

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

DPAN и FSP могут быть приняты в виде подписанной или зашифрованной записи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упомянутые идентификационные данные любого из с первого по третий или с шестого по седьмой аспектов могут содержать одно или более из: PAN финансирования (FPAN), PAN устройства (DPAN), дату окончания срока и порядковый номер.

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

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

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

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

FSP любого из аспектов может быть кодом платежного счета (PAR), как это определяется спецификациями EMVCo.

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

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

фигура 1 показывает иллюстративную многостороннюю систему платежных транзакций;

фигура 2A изображает поток сообщений;

фигура 2B изображает другой поток сообщений;

фигура 3A изображает активацию возможности совершения платежей вторичным устройством;

фигура 3B изображает использование основного платежного устройства в платежном терминале;

фигура 3C изображает последующую попытку использования вторичного платежного устройства;

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

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ

Фигура 1 показывает иллюстративную многостороннюю систему 100 платежных транзакций для обеспечения оплаты картой или аналогичных транзакций клиентом 110 (например, владельцем карты, пользователем и т.п.) в торгово-сервисном предприятии 120 (например, транспортном агентстве). Эмитент 150, обычно финансовое учреждение, такое как банк, создает для клиента 110 счет 114 клиента, сохраняет и обновляет данные, связанные с этим счетом, например, в базе 152 данных. Эмитент 150 также предоставляет клиенту 110 платежное устройство 112, такое как кредитная, дебетовая, предварительно оплаченная или коммерческая карта и/или ее эквивалент, связанный со счетом 114 клиента.

Платежная транзакция инициируется, когда клиент 110 использует платежное устройство 112 для совершения оплаты за покупку у торгово-сервисного предприятия 120, обычно в терминале (не показан) торговой точки (POS). Затем необходимо совершить ряд обменов между сторонами, изображенными на фигуре 1, для завершения транзакции. В общем можно считать, что эти обмены проводятся в четыре стадии: (1) взаимодействие со считывателем карт, (2) авторизация, (3) клиринг и (4) погашение (где этапы (2) и (3) могут происходить одновременно).

На стадии взаимодействия со считывателем карт торгово-сервисное предприятие 120 получает (считывает, принимает и т.п.) данные платежного устройства от платежного устройства 112. Например, клиент 110 может коснуться его или ее бесконтактной платежной картой или мобильным платежным устройством с поддержкой NFC считывателя с поддержкой NFC терминала POS, чтобы позволить терминалу POS считать данные платежного устройства, в том числе информацию о клиентском счете, из микросхемы, защищенного элемента или доверенной среды выполнения (TEE), встроенной в платежное устройство 112, или из памяти устройства в случае серверной эмуляции карты (Host Card Emulation) (также известной как облачные платежи).

Во время стадии авторизации подтверждаются идентификационная информация о счете клиента, подлинность платежного устройства 112 и наличие средств на счете 114 клиента. Дополнительно, в некоторых торгово-сервисных предприятиях (в том числе некоторых транспортных торгово-сервисных предприятиях) терминал проверяет подпись CDA (комбинированную генерацию DDA/AC, где DDA означает динамическую аутентификацию данных, а AC означает криптограмму приложения). Торгово-сервисное предприятие 120 электронным образом передает часть или всю информацию, полученную от платежного устройства, генераторам обработки транзакций банка 130 торгово-сервисного предприятия (или эквайеру/банку-эквайеру) для запроса авторизации транзакции. Запрос также может включать в себя сумму транзакции, такую как сумму покупки.

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

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

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

Например, рассмотрим сценарий клиента 110, заходящего в транспортную систему путем касания платежного устройства 112 в точке входа в транспортную систему (такую как валидатор транспортного агентства, двери, терминал POS или любая другая подходящая точка входа). При условии, что платежное устройство 112 является допустимым и в настоящий момент не заблокировано транспортным агентством для совершения поездки (например, за предыдущий неплатеж), клиенту 110, как правило, разрешается совершить поездку до совершения транспортным агентством 120 запроса на авторизацию от эмитента 150. Такова природа транспортных служб, что большое количество пассажиров (регулярных пассажиров и т.п.) должно входить и выходить из транспортной системы в короткие промежутки времени. В то же время транспортные агентства часто не обладают высокоскоростной и/или надежной коммуникационной инфраструктурой (особенной острая проблема там, где клиент 110 должен валидировать себя в мобильной точке входа, например, в автобусе). Соответственно, для своевременного обслуживания потребительского спроса на транспортные услуги клиентам, как правило, разрешается совершить поездку до получения авторизации от эмитента 150.

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

Если транспортное агентство 120 принимает ответ на авторизацию, указывающий, что запрос агрегации был одобрен, транспортное агентство 120 теперь может принимать дальнейшие прикладывания к платежному устройству 112 в транзитной сети и вычислять платежи (тарифы), например, на основании того, где, когда и какой вид транспорта использовался клиентом 110. По истечении периода агрегации (например, некоторое количество платежей было накоплено клиентом 110, прошел некоторый период времени и т.д.) транспортное агентство 120 направляет одну транзакцию на сумму всех платежей, накопленных клиентом 110 в течение периода агрегации, для клиринга и погашения в соответствии со стандартными процедурами клиринга и погашения, установленными сетью 140 платежной системы. Альтернативно, некоторые местные правила могут позволять транспортному агентству направлять несколько клиринговых записей на одну хорошую авторизацию, до тех пор, пока не будет превышена пороговая сумма. Например, если торгово-сервисное предприятие является транспортным агентством, для поездок по карте клиринг может проводиться каждый день, когда карта используется (тем самым делая выписки из счетов клиентов более понятными), пока не будет превышен полный порог агрегации, после чего требуется новая авторизация, чтобы позволить беспрепятственное продолжение агрегации.

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

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

Фигура 2A изображает поток сообщений, когда клиент 210 использует основное платежное устройство, такое как дебетовая карта 212A, для получения доступа к транспортной системе. На этапе 201 клиент касается своей картой платежного терминала транспортного агентства 220. На этапе 202 (который может происходить несколько минут или более часов спустя, если транспортным агентством используется модель отложенного или агрегированного платежа) запрос транзакции передается банку 230 транспортного агентства. На этапе 203 запрос передается сети 240 платежной системы, а затем эмитенту 250 карты на этапе 204. Эмитент отклоняет транзакцию, и транспортное агентство узнает об этом через поток сообщений 205, 206, 207, после чего оно блокирует идентификационные данные платежного устройства для дальнейших поездок, например, путем добавления их в список отказа в обслуживании, хранящийся в каждом терминале, который проверяется каждый раз, когда используется платежный терминал транспортного агентства. Значение, добавленное в список отказа в обслуживании, может быть, например, кодом, сформированным путем хеширования PAN с датой окончания срока и порядковым номером для создания значения, уникального для каждого набора платежных идентификационных данных.

Фигура 2B изображает почти идентичный поток сообщений, когда клиент 210 использует вторичное платежное устройство, такое как смартфон 212B с поддержкой NFC-платежей, позволяющий платить с того же самого счета, что и карта 212A, для получения доступа к транспортной системе. Единственная разница между потоками сообщений на фигурах 2A и 2B заключается в том, что платежные идентификационные данные, содержащиеся в сообщениях, относятся к основному платежному устройству на фигуре 2A (например, содержат FPAN карты) и вторичному платежному устройству на фигуре 2B (например, содержат DPAN смартфона). Потоки сообщений на фигурах 2A и 2B могут выполняться в любом порядке и могут предваряться, сопровождаться или включать один или более дополнительных аналогичных потоков сообщений, содержащих идентификационные данные, относящиеся к дополнительным платежным устройствам того же самого клиента 210, например, DPAN планшета, и/или умных часов, и/или NFC-наклейки и/или NFC-брелока.

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

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

Как показано на фигуре 3A, когда вторичному платежному устройству 312B предоставляется возможность совершения платежей, оно принимает подготовительные полезные данные от сети 340 платежной системы. Традиционно эти полезные данные содержали бы все идентификационные данные, необходимые для совершения платежей; например, DPAN, дату окончания срока, номер выпуска и т.д. Однако в способе на фигуре 3A полезные данные содержат FSP в дополнение к обычным идентификационным данным.

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

Фигура 3B иллюстрирует использованием основного платежного устройства 312A в платежном терминале. После получения идентификационных данных от любого платежного устройства терминал 320 торгово-сервисного предприятия проверяет, содержат ли эти идентификационные данные FSP. Если нет, как в показанном случае, то FSP вычисляется по идентификационным данным. Если транзакция позже отклоняется, этот FSP добавляется в список отказа в обслуживании. (Список отказа в обслуживании является списком идентификационных данных карт, как правило хранящихся в хешированном формате, использование которых торгово-сервисное предприятие будет блокировать.)

После такого добавления в список отказа в обслуживании клиент 310 может предпринять попытку использовать вторичное платежное устройство 312B для совершения платежа тому же самому торгово-сервисному предприятию 320. Однако терминал затем автоматически проверяет на FSP и, когда он найден, сверяет его с записями в списке отказа в обслуживании. При обнаружении совпадения платежный терминал предотвращает получение клиентом 310 продукта или услуги, к которой он пытался получить доступ. Это может происходить, например, в виде предупреждения для оператора терминала или в виде закрытых дверей к транспортной услуге.

Процессы, показанные на фигурах 3B и 3C, могут выполняться в любом порядке и/или с повторением одного или обоих из них; клиент 310 в любом случае не может использовать один и тот же счет для получения более чем одной "бесплатной поездки".

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

Реализация таких процедур FSP не требует никакого изменения текущих систем выпуска чип-карт; каждый раз, когда пластиковая карта предъявляется считывателю, будет вычисляться FSP, поскольку это 'основной' набор идентификационных данных. Всякий раз, когда устройство подготавливается, для устройства всегда персонализируется FSP, таким образом когда оно будет предъявлено терминалу, FSP будет найден и сверен со списком отказа в обслуживании. Логика авторизации может оставаться неизменной (то есть нет необходимости изменять логику FPAN/DPAN), изменяется только логика считывателя.

Фигура 3D является блок-схемой последовательности операций, изображающей задействованный логический процесс. На этапе 301 платежное устройство предъявляется платежному терминалу. На этапе 302 терминал считывает идентификационные данные, принятые от платежного устройства. На этапе 303 терминал проверяет на наличие FSP среди идентификационных данных. Если он не найден, то тогда на этапе 303A генерируется FSP по идентификационным данным. Когда FSP был найден или сгенерирован, на этапе 304 он сверяется со списком отказа в обслуживании.

FSP также могут быть полезны для других целей, помимо блокирования транзакций "бесплатных поездок". Для торгово-сервисного предприятия в общем полезно иметь возможность идентифицировать повторных покупателей, независимо от платежного устройства, которое они решили использовать для конкретной транзакции, например, для улучшения услуги, предоставляемой клиенту, и/или для сбора данных об индивидуальных или демографических особенностях, которые могут анализироваться для разработки стратегий для увеличения дохода, уменьшения затрат и т.д. Таким образом, этап 304 на фигуре 3D может относиться вместо сверки FSP со списком отказа в обслуживании к сверке со списком зарегистрированных клиентов. Если FSP найден в таком списке, то запись, в которой он найден, может быть обновлена с помощью данных, относящихся к настоящей транзакции. Кроме того, может использоваться другая информация, сохраненная в записи с FSP, для определения, можно ли что-нибудь сделать в это время для повышения степени удовлетворенности клиента. Например, клиенту можно сообщить о полученных баллах лояльности, ваучере или бесплатном подарке, право на который он получил в соответствии со схемой поощрений.

Фигура 4 является блок-схемой последовательности операций способа 400 идентификации платежным терминалом источника финансирования электронной транзакции. На этапе 410 терминал принимает запрос транзакции, содержащий один или более элементов идентификационных данных от платежного устройства. На этапе 420 терминал определяет, содержат ли упомянутые идентификационные данные FSP, и если не содержат, на этапе 430 генерирует FSP по одному или более элементам упомянутых идентификационных данных в соответствии с предварительно определенным алгоритмом, сохраненным в терминале, FSP получают по FPAN источника финансирования платежного устройства.

Фигура 5 является блок-схемой последовательности операций способа 500 обработки платежным терминалом электронной транзакции. На этапе 510 терминал принимает запрос транзакции, содержащий один или более элементов идентификационных данных, от платежного устройства. На этапе 520 терминал определяет, содержат ли упомянутые идентификационные данные FSP и, если не содержат, на этапе 530 генерирует FSP по одному или более элементам упомянутых идентификационных данных в соответствии с предварительно определенным алгоритмом, сохраненным в терминале, FSP получается из FPAN источника финансирования платежного устройства. На этапе 540 терминал определяет, присутствует ли FSP в списке отказа в обслуживании. Если присутствует, то на этапе 550A терминал отклоняет запрос транзакции, а если нет, то на этапе 550B терминал авторизует запрос транзакции.

Фигура 6A является блок-схемой последовательности операций способа 600A. На этапе 601A вторичное платежное устройство принимает DPAN и FSP, полученный по FPAN источника финансирования в соответствии с предварительно определенным алгоритмом. На этапе 602A вторичное платежное устройство передает первый запрос транзакции, содержащий упомянутый DPAN и упомянутый FSP, платежному терминалу. На этапе 603A платежный терминал принимает первый запрос транзакции. В ответ на него на этапе 605A терминал проверяет, присутствует ли FSP в списке отказа в обслуживании. Если присутствует, то на этапе 606A терминал отклоняет первый запрос транзакции. Если нет, то на этапе 607A терминал авторизует первый запрос транзакции. Затем на этапе 608A терминал посылает запрос, содержащий DPAN, к платежной сети для погашения транзакции. Позже на этапе 609A платежный терминал принимает сообщение о невыполнении транзакции, содержащее DPAN (или некоторые другие данные, идентифицирующие невыполненную транзакцию или источник финансирования) от платежной сети. В ответ на это на этапе 610A терминал добавляет FSP в список отказа в обслуживании. Впоследствии терминал принимает второй запрос транзакции, содержащий FPAN, на этапе 611A. В ответ на это на этапе 612A терминал генерирует FSP по принятому FPAN в соответствии с упомянутым предварительно определенным алгоритмом, который хранится в терминале. На этапе 613A терминал определяет, что FSP присутствует в списке отказа в обслуживании, и отклоняет второй запрос транзакции.

Фигура 6B является блок-схемой последовательности операций способа 600B. На этапе 603B платежный терминал принимает первый запрос транзакции, содержащий FPAN источника финансирования. В ответ на это на этапе 604B терминал генерирует FSP из упомянутого FPAN в соответствии с предварительно определенным алгоритмом, хранящимся в терминале. На этапе 605B терминал проверяет, присутствует ли FSP в списке отказа в обслуживании. Если присутствует, то на этапе 606B терминал отклоняет запрос транзакции. Если нет, на этапе 607B терминал авторизует запрос транзакции. Затем на этапе 608B терминал посылает запрос, содержащий FPAN, к платежной сети для погашения транзакции. Позже на этапе 609B терминал принимает сообщение о невыполнении транзакции, содержащее FPAN (или некоторые другие данные, идентифицирующие невыполненную транзакцию или источник финансирования) от платежной сети. В ответ на это на этапе 610B терминал добавляет FSP в список отказа в обслуживании. Позже на этапе 611B терминал принимает дальнейший запрос транзакции, содержащий DPAN и FSP. На этапе 613B терминал определяет, что FSP присутствует в списке отказа в обслуживании, и отклоняет запрос транзакции.

Фигура 7 изображает пример системы 700, которая обеспечивает обработку платежных транзакций в платежных терминалах. Система 700 включает в себя систему 710 обработки, содержащую процессор(ы) 712, память 714 и запоминающее устройство(а) 716. Кроме того, система 710 обработки соединена с устройством(ами) 720 ввода, таким как клавиатура, мышь, сенсорный экран, микрофон и т.д. и устройством(ами) 725 вывода, таким как дисплей, громкоговоритель, световой индикатор и т.д. Запоминающее устройство(а) 716 хранит операционную систему 717, приложение(я) 718 и данные 719.

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

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

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

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

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

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

Изобретение относится к средствам авторизации электронной транзакции. Техническим результатом является повышение эффективности авторизации электронных транзакций. Способ авторизации электронной транзакции, выполняемый посредством платежного терминала, содержит этапы: принимают запрос транзакции от первичного платежного устройства; определяют, включает ли запрос транзакции источник финансирования заменитель (FSP), полученный из первичного учетного номера финансирования (FPAN) источника финансирования в соответствии с предварительно определенным алгоритмом; определяют, что FSP не присутствует в списке отказа в обслуживании, сохраненном в платежном терминале, и в ответ на это авторизуют запрос транзакции, принятый от первичного устройства, если запрос принят от вторичного платежного устройства, содержащего учетный номер устройства (DPAN) и упомянутый FSP, определяют, что FSP не присутствует в списке отказа в обслуживании, сохраненном в платежном терминале; и в ответ на это авторизируют запрос транзакции вторичного платежного устройства. Платежный терминал выполнен с возможностью реализации данного способа. 2 н. и 3 з.п. ф-лы, 12 ил.

1. Способ авторизации электронной транзакции, при этом способ выполняется посредством платежного терминала и содержит этапы, на которых:

принимают запрос транзакции;

если запрос транзакции принят от первичного платежного устройства,

определяют, включает ли в себя запрос транзакции источник финансирования заменитель (FSP),

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

определяют, что FSP не присутствует в списке отказа в обслуживании, сохраненном в платежном терминале, и

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

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

определяют, что FSP не присутствует в упомянутом списке отказа в обслуживании, и

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

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

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

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

в ответ на это добавляют FSP в список отказа в обслуживании;

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

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

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

в ответ на это отклоняют упомянутый запрос транзакции первичного устройства.

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

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

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

впоследствии либо:

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

в ответ на это генерируют FSP из принятого FPAN в соответствии с упомянутым предварительно определенным алгоритмом, причем данный предварительно определенный алгоритм сохранен в платежном терминале,

в ответ на это определяют, что сгенерированный FSP не присутствует в списке отказа в обслуживании, и

в ответ на это авторизуют упомянутый запрос транзакции первичного устройства;

либо:

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

в ответ на это генерируют FSP из принятого FPAN в соответствии с упомянутым предварительно определенным алгоритмом, причем данный предварительно определенный алгоритм сохранен в платежном терминале,

в ответ на это определяют, что сгенерированный FSP не присутствует в списке отказа в обслуживании,

в ответ на это авторизуют упомянутый запрос транзакции первичного устройства,

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

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

в ответ на это добавляют FSP в список отказа в обслуживании.

4. Способ по п. 2 или 3, который, если запрос транзакции принят от первичного платежного устройства, дополнительно содержит этапы, на которых:

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

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

5. Платежный терминал, выполненный с возможностью авторизации электронных транзакций, при этом платежный терминал содержит:

приемник, выполненный с возможностью приема запроса транзакции;

память, хранящую список отказа в обслуживании; и

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

если запрос транзакции принят от первичного платежного устройства,

определять, включает ли в себя запрос транзакции источник финансирования заменитель (FSP),

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

определять, что FSP не присутствует в списке отказа в обслуживании, и

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

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

определять, что FSP не присутствует в списке отказа в обслуживании, и

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