RU2752688C1

RU2752688C1 - Системы и способы для использования в аутентификации пользователей со счетами применительно к сетевым транзакциям

Info

Publication number: RU2752688C1
Application number: RU2020123929A
Authority: RU
Inventors: Аарон КИРБИ; Брэндон Крэйг БРАЙСОН
Original assignee: Мастеркард Интернэшнл Инкорпорейтед
Priority date: 2017-12-21
Filing date: 2018-11-15
Publication date: 2021-07-29
Also published as: WO2019125667A1; US20190197542A1; US20220108317A1; EP3729354A1; AU2018390713A1; CN111512331B; CN111512331A; US11188912B2; US11741472B2; EP3729354A4

Abstract

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

Description

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

По настоящей заявке испрашивается приоритет согласно патентной заявке США № 15/850,216, поданной 21 декабря 2017 г. Все раскрытие вышеупомянутой заявки включено в настоящий документ посредством ссылки.

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

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

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

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

Сетевые транзакции часто включают в себя пользователей, которые инициируют транзакции. Чтобы обеспечить достоверность пользователей, задействованных в транзакциях, обычно пользователи аутентифицируются для транзакций. Конкретно применительно к транзакциям с платежным счетом, конкретные субъекты (например, банковские учреждения и т. д.) полагаются на службы аутентификации, чтобы аутентифицировать пользователей, такие как, например, протокол 3-D Secure^TM, который полагается на плагины (подключаемые программные расширения) сервера торгово-сервисного предприятия, или MPI, у торгово-сервисного предприятия, задействованного в транзакциях, и сервера управления доступом, или ACS, связанные с эмитентом платежных счетов, используемых в транзакциях. Протокол 3-D Secure^TM известен как используемый для транзакций по сети, чтобы позволить владельцам карт аутентификацию, когда они физически не присутствуют у торгово-сервисного предприятия при выполнении транзакций (т. е. для транзакций без участия карты).

Применительно к этому, для транзакции без участия карты, инициированной потребителем у торгово-сервисного предприятия, запрос аутентификации обеспечивается от MPI, связанного с торгово-сервисным предприятием, серверу каталогов (например, связанному с платежной сетью и т. д.). В свою очередь сервер каталогов направляет запрос аутентификации к ACS, связанному с эмитентом платежного счета, используемого в транзакции (например, банку и т. д.). ACS связывается с потребителем, например, посредством интеллектуального телефона, чтобы запросить персональный идентификационный номер (PIN), биометрическую характеристику, пароль и/или одноразовый код доступа для аутентификации потребителя. После аутентификации ответ подтверждения передается обратно в MPI и серверу каталогов. Затем из ответа составляется запрос авторизации для транзакции, который передается от торгово-сервисного предприятия приобретателю, связанному с торгово-сервисным предприятием, и эмитенту (посредством платежной сети) для одобрения эмитентом, что является стандартным. Примерное осуществление протокола 3-D Secure^TM включает в себя службу SecureCode^TM от MasterCard^®.

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

ЧЕРТЕЖИ

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

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

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

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

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

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

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

Платежные счета широко используются пользователями для оплаты транзакций для продуктов (например, для товаров, услуг и т. д.) у торгово-сервисных предприятий. Чтобы избежать проблем, относящихся к мошенническим или другим неавторизованным транзакциям, частично, эмитенты, связанные с платежными счетами, и/или платежные сети, связанные с обработкой транзакций, накладывают конкретные методики аутентификации, чтобы удостовериться, что пользователи авторизованы инициировать транзакции с платежными счетами (например, посредством протокола 3-D Secure^TM и т. д.). Такие методики аутентификации обычно задействуют аутентификацию пользователей, например, посредством персональных идентификационных номеров (PIN), сравнения биометрических характеристик, подтверждения паролей и/или подтверждения одноразовых кодов доступа и т. д. Отдельным образом эмитенты, государства или другие субъекты могут обеспечивать услуги пользователям платежных счетов в форме приложений, веб-сайтов и т. д. (в широком смысле, сетевых приложений), посредством чего пользователям позволяется осуществить доступ к деталям счета для их счетов, изменить настройки счета, подать заявку для счета и т. д. через приложения, веб-сайты и т. д. после аутентификации.

Уникальным образом, системы и способы здесь применяют прошлые аутентификации пользователей (например, через сетевые приложения, такие как виртуальные кошельки и т. д.), чтобы обеспечить усовершенствованную аутентификацию тех же самых пользователей применительно к прошлым аутентификациям и/или для конкретных транзакций (например, транзакций без участия карты и т. д.), инициированных пользователями. В частности здесь, когда пользователь взаимодействует с одним или более приложениями, веб-сайтами и т. д., предлагаемыми от или вместо эмитента счета, государства или другого субъекта применительно к осуществлению доступа к платежному счету, связанному с пользователем, от пользователя может требоваться аутентификация перед осуществлением доступа к деталям счета для платежного счета или другим использованием приложений, веб-сайтов и т. д. Аутентификация может быть, например, биометрической аутентификацией или другой аутентификацией, как описано здесь. В моменты, или позже, или в пределах другого интервала выполнения такой аутентификации потребитель может инициировать транзакцию с торгово-сервисным предприятием, которая должна быть финансирована платежным счетом (где платежный счет также зарегистрирован в усовершенствованной аутентификации). В ответ плагин сервера торгово-сервисного предприятия (MPI), связанный с торгово-сервисным предприятием, изначально требует аутентификацию пользователя через сервер каталогов. В ответ вместо маршрутизации запроса аутентификации к серверу управления доступом (ACS), связанному с эмитентом платежного счета, сервер каталогов распознает прошлую аутентификацию и передает запрос оценки аутентификации непосредственно эмитенту, государству или другому субъекту, связанному с платежным счетом. В зависимости от последней прошлой или недавней аутентификацией пользователя в приложении, на веб-сайте и т. д. от или вместо эмитента (или государства, или другого субъекта), эмитент (или государство, или другой субъект) может одобрять аутентификацию с сервером каталогов, тем самым разрешая транзакцию, чтобы избежать дублированной аутентификации с ACS. Таким образом, сервер каталогов взаимодействует непосредственно с эмитентом, чтобы применить прошлую аутентификацию пользователя (потенциально задействующую ACS), чтобы избежать дублированной аутентификации пользователя в последующей транзакции. Таким образом, более эффективный и более своевременный процесс аутентификации обеспечен, который отклоняется от стандартной аутентификации (включая стандартную аутентификацию посредством протокола 3-D Secure^TM) и уменьшает неудобство и/или прерывание ощущений пользователей как покупателей. Более того, это может осуществляться при сохранении персональной идентифицирующей информации для пользователя, например, без того, что эмитент и/или ACS раскрывает какую-либо индивидуальную для пользователя информацию серверу каталогов, связанной платежной сети и т. д.

Фиг.1 изображает примерную систему 100 для осуществления процесса, который может задействоваться для усовершенствованной аутентификации потребителя 102 (в широком смысле, пользователя) применительно к транзакции потребителя 102 и который соответствует протоколу 3-D Secure^TM, например. Однако следует понимать, что не все подробности протокола 3-D Secure^TM рассматриваются здесь, поскольку полное подробное раскрытие такой информации может быть легко понято в общем случае посредством ссылки на протокол 3-D Secure^TM. Дополнительно, иллюстрируемая система 100 включает в себя множество субъектов, которые взаимодействуют друг с другом путем обмена множеством конкретным образом форматируемых сообщений по защищенным каналам связи (например, как задано в протоколе 3-D Secure^TM и т. д.).

В иллюстрируемом варианте осуществления потребитель 102 связан с платежным счетом. Платежный счет выдается потребителю 102 эмитентом 104 и имеет возможность использования потребителем 102, чтобы оплачивать транзакции покупки с одним или более торгово-сервисными предприятиями (например, торгово-сервисным предприятием 106 и т. д.). Потребитель 102 также связан с вычислительным устройством 108. Вычислительное устройство 108 может включать в себя, например, планшет, интеллектуальный телефон, ноутбук, настольный компьютер или другое устройство, которое обеспечивает возможность потребителю 102 взаимодействовать и/или осуществлять связь с одним или более торгово-сервисными предприятиями, включающими в себя торгово-сервисного предприятия 106 (например, посредством веб-сайтов и/или сетевых приложений, обеспеченных торгово-сервисным предприятием 106, и т. д.). Детали вычислительного устройства 108 и других вычислительных устройств, идентифицированных здесь (например, серверов и т. д.), описаны более полно ниже со ссылками на фиг.2. Хотя иллюстрируется только одно вычислительное устройство 108, следует понимать, что потребитель 102 может быть связан с множеством таких вычислительных устройств, включающих в себя, например, вычислительное устройство 108, интеллектуальный телефон, планшет, компьютер-ноутбук и т. д.

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

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

В свою очередь, торгово-сервисное предприятие 106 передает информацию, собранную для потребителя 102, плагину 110 сервера торгово-сервисного предприятия (MPI), связанному с торгово-сервисным предприятием 106, чтобы изначально аутентифицировать потребителя 102. MPI 110 в общем случае включает в себя программный модуль, исполняемый у торгово-сервисного предприятия 106. MPI 110 в ответ на прием различной информации потребителя от торгово-сервисного предприятия 106 выполнен с возможностью составлять запрос аутентификации (или верифицированный запрос регистрации, называемый здесь "VEreq") для транзакции и передавать VEreq серверу 112 каталогов по пути B. При приеме VEreq от MPI 110 сервер 112 каталогов выполнен с возможностью определять, зарегистрирован ли платежный счет потребителя для служб усовершенствованной аутентификации и т. д. Например, сервер 112 каталогов может быть выполнен с возможностью идентифицировать учетные данные платежного счета, включенные в VEreq, и определять на основе диапазона учетных данных, или диапазона банковских идентификационных номеров (BIN), или номеров первичного счета (PAN) для учетных данных и т. д., зарегистрирован ли платежный счет потребителя в службах усовершенствованной аутентификации. Сервер 112 каталогов затем выполнен с возможностью, в этом примерном варианте осуществления, передавать запрос подтверждения аутентификации непосредственно эмитенту 104 платежного счета потребителя (в отличие от сервера 114 управления доступом (ACS), связанного с эмитентом 104), когда платежный счет (и эмитент 104) зарегистрирован в службе усовершенствованной аутентификации, чтобы определять, связан ли потребитель 102 (и/или платежный счет потребителя) с какими-либо прошлыми успешными аутентификациями, о которых эмитент 104 может быть осведомлен (для того, чтобы обходить стандартный поток такой аутентификации к ACS 114). Запрос подтверждения аутентификации передается сервером 112 каталогов по пути C на фиг.1.

Дополнительно в системе 100, или в качестве альтернативы, при приеме VEreq для транзакции от MPI 110 сервер 112 каталогов может быть выполнен с возможностью определять, имеет ли транзакция тип транзакции без участия карты, или другие параметры, связанные с транзакцией (например, сумму, торгово-сервисного предприятия и т. д.). Сервер 112 каталогов может быть выполнен с возможностью затем полагаться на такую дополнительную информацию (и конкретные условия, удовлетворяемые или не удовлетворяемые информацией), передавая или не передавая запрос подтверждения аутентификации эмитенту 104.

В любом случае при приеме запроса подтверждения аутентификации от сервера 112 эмитент 104 выполнен с возможностью определять, правомочен ли потребитель 102 для подтверждения аутентификации снова, на основе любых прошлых аутентификаций, о которых эмитент 104 осведомлен, и/или одного или нескольких других параметров (например, временных параметров, связанных с прошлыми аутентификациями, параметров идентификации, связанных с индивидом в прошлой аутентификации, и т. д.). Конкретным образом, когда потребитель 102 был аутентифицирован с приложением, связанным с эмитентом 104 (например, приложением виртуального кошелька и т. д.), т. е. была прошлая аутентификация, эмитент 104 может быть выполнен с возможностью одобрять аутентификацию потребителя 102 (в ответ на запрос подтверждения аутентификации от сервера 112 каталогов) на основе прошлой аутентификации потребителя 102 с приложением эмитента, и, потенциально, когда прошлая аутентификация находится в пределах последних десяти минут, пятнадцати минут, тридцати минут, одного или нескольких интервалов больше или меньше (в широком смысле, в пределах заданного интервала или продолжительности времени). Более того, эмитент 104 может быть выполнен с возможностью дополнительно полагаться на одно или несколько других условий прошлой аутентификации (например, формы аутентификации, надежности аутентификации и т. д.), текущей транзакции (например, суммы транзакции и т. д.) или платежного счета потребителя (например, были ли подозрительные транзакции ранее сделаны на платежный счет и т. д.) и т. д., чтобы определить, правомочен ли потребитель 102 для подтверждения аутентификации. Следует понимать, что прошлая аутентификация может быть индивидуальной для платежного счета потребителя (независимо от того, была ли прошлая аутентификация для потребителя 102 или для другого авторизованного пользователя платежного счета), или она может быть индивидуальной для потребителя 102 (например, индивидуальной для потребителя 102, аутентифицированного со своим платежным счетом, используемым в данной транзакции (и никого другого, даже при авторизации для использования платежного счета)), или она может относиться к потребителю 102, который просто был ранее аутентифицирован любым образом и/или к любому платежному счету вообще, и причем эта аутентификация известна эмитенту 104 и/или ACS 114 (например, в зависимости от модели риска, используемой эмитентом 104 и/или ACS 114, и т. д.). В одном примере прошлая аутентификация может включать в себя пользователя, успешно осуществившего доступ (например, осуществившего вход в систему, и т. д.) к своему платежному счету через приложение мобильного банкинга, обеспеченное эмитентом 104, чтобы проверить баланс своего первичного текущего счета.

Затем в системе 100, когда эмитент 104 определяет, что потребитель 102 правомочен для подтверждения аутентификации, эмитент 104 выполнен с возможностью обеспечивать одобрение (или подтверждение аутентификации) серверу 112 каталогов в ответ на запрос подтверждения аутентификации обратно по пути C на фиг.1. Одобрение может включать в себя множество различных элементов информации, включающих в себя, например, значение аутентификации владельца счета (AAV) для запроса аутентификации. Отдельно от того, является ли потребитель 102 правомочным для подтверждения аутентификации, эмитент 104 может дополнительно быть выполнен с возможностью непосредственно обеспечивать инструкцию отклонения для базовой транзакции серверу 112 каталогов, снова по пути C, потенциально на основе прошлой аутентификации (например, если прошлая аутентификация является или кажется мошеннической; и т. д.) и/или одного или нескольких условий (посредством чего инструкция отклонения может затем быть передана сервером 112 каталогов торгово-сервисному предприятию 106 посредством MPI 110 так, что транзакция может быть прекращена и/или прервана).

В ответ на одобрение от эмитента 104 сервер 112 каталогов (например, генератор AAV (или дополнительные функциональные возможности), связанный с сервером 112 каталогов, и т. д.) выполнен с возможностью предоставлять одобрение (например, включающее в себя AAV и т. д.) в MPI 110, обратно по пути B (посредством чего особое AAV создается в потоке авторизации так, что эмитент 104 осведомлен, что аутентификация для потребителя 102 была подтверждена). После этого торгово-сервисное предприятие 106, по приему одобрения от MPI 110, выполнен с возможностью составлять сообщение авторизации (т. е. запрос авторизации) для данной транзакции (включающее в себя AAV или другое одобрение, принятое от эмитента 104) и передавать сообщение авторизации приобретателю 116, связанному с торгово-сервисным предприятием 106. Приобретатель 116 в свою очередь передает сообщение авторизации с эмитентом 104 через платежную сеть 118, связанную с платежным счетом потребителя (посредством сети 120), для авторизация транзакции. Эмитент 104 затем определяет, имеет ли платежный счет потребителя хорошую репутацию и связан ли достаточный кредит/средства для завершения транзакции с платежным счетом. Дополнительно, эмитент 104 выполнен с возможностью удостоверять AAV или другое одобрение, включенное в сообщение авторизации (обеспеченное через сервер 112 каталогов и MPI 110). Если эмитент 104 одобряет/принимает транзакцию, другое сообщение авторизации (т. е. ответ авторизации) обеспечивается обратно торгово-сервисному предприятию 106, авторизуя транзакцию. Транзакция затем проводится и урегулируется у и между торгово-сервисным предприятием 106 и приобретателем 116 (в соответствии с соглашением урегулирования и т. д.) и у и между приобретателем 116 и эмитентом 104 (в соответствии с другим соглашением урегулирования и т. д.).

В противном случае, когда эмитент 104 не обеспечивает одобрение (т. е. когда потребитель 102 не правомочен для подтверждения аутентификации), сервер 112 каталогов выполнен с возможностью требовать аутентификацию потребителя 102 стандартным образом (например, в соответствии с протоколом 3-D Secure^TM и т. д.) через ACS 114, связанный с эмитентом 104 (где ACS 114 оперирует от лица или, потенциально, в качестве представителя эмитента 104, предполагая, что эмитент 104 зарегистрирован в службах ACS), по пути D на фиг.1. Применительно к этому, сервер 112 каталогов контактирует с ACS 114, и ACS 114 выполняет аутентификацию, например, изначально удостоверяясь в регистрации платежного счета потребителя и/или эмитента 104 с ACS 114 (для желаемых служб аутентификации) и, когда такая регистрация подтверждается, аутентифицируя потребителя 102. Применительно к последнему, ACS 114 выполнен с возможностью обеспечивать сетевой адрес (например, URL и т. д.) виртуальному местоположению торгово-сервисного предприятия 106, через сервер 112 каталогов и MPI 110. Торгово-сервисное предприятие 106 затем в свою очередь вызывает сетевой адрес. Это позволяет ACS 114 взаимодействовать с потребителем 102 через вычислительное устройство 108 потребителя, как указано путем E на фиг.1. В рамках взаимодействия, ACS 114 может запросить PIN, биометрическую характеристику или другую информацию от потребителя 102, подходящую, чтобы аутентифицировать потребителя 102. При аутентификации потребителя, ACS 114 отвечает MPI 110 одобрением (например, AAV и т. д.), или ACS 114 отвечает MPI 110 другим сообщением, когда аутентификация потребителя оказалась безуспешной. После этого MPI 110 и торгово-сервисное предприятие 106 продолжают операцию, как описано выше (например, с сообщением авторизации для транзакции и т. д.).

Хотя система 100 включает в себя только одного потребителя 102, одного эмитента 104, одного торгово-сервисного предприятия 106, один MPI 110, один сервер 112 каталогов, один ACS 114, одного приобретателя 116 и одну платежную сеть 118, следует понимать, что другое количество этих субъектов может быть включено в других вариантах осуществления системы. Кроме того, хотя описание здесь представляется со ссылками на эмитента 104 для простоты ссылок, следует понимать, что государственная организация, или другой субъект, может быть включена вместо эмитента 104 и/или дополнительно к эмитенту 104 (и/или в ассоциации с эмитентом 104) для операции, по меньшей мере частично, в соответствии с эмитентом 104. Например, государственная организация (не показана) может включать в себя место эмитента 104 и/или ассоциацию с эмитентом 104 и т. д. Например, в Индии номер Aadhaar гражданина может быть привязан к одному или нескольким из его номеров платежного счета. Таким образом, аутентификация гражданина Индии на основе настоящего раскрытия применительно к транзакции у торгово-сервисного предприятия (например, для транзакции без участия карты и т. д.) может использовать номер платежного счета гражданина Индии в качестве основы (или в качестве ссылки), чтобы понять, был ли гражданин Индии за последнее время аутентифицирован с использованием своего номера Aadhaar. Если так, одобрение подтверждения для гражданина Индии может быть обеспечено эмитентом 104/государственной организацией серверу 112 каталогов (как описано выше). В другом примере государственная организация может захватывать аутентификацию потребителя 102 и других пользователей (в качестве прошлых аутентификаций) и перенаправлять эту информацию эмитенту 104, тем самым обеспечивая возможность (или полагаясь на) эмитенту 104 реагировать на запрос подтверждения аутентификации, описанный выше, на основе прошлой аутентификации(й). В еще одном примере государственная организация может быть адресатом запроса подтверждения аутентификации от сервера 112 каталогов и может отвечать за ответы на них подобно описанному выше со ссылками на эмитента 104.

Как изображено на фиг.1, система 100 также включает в себя сеть 120. Все из эмитента 104, торгово-сервисного предприятия 106, вычислительного устройства 108 потребителя, MPI 110, сервера 112 каталогов, ACS 114, приобретателя 116 и платежной сети 118 соединены и/или осуществляют связь с сетью 120, чтобы обеспечивать связь между ними. Сеть 120 может включать в себя, без ограничения, локальную сеть (LAN), широкомасштабную сеть (WAN) (например, Интернет и т. д.), мобильную сеть, виртуальную сеть и/или другую подходящую общедоступную и/или частную сеть с возможностью поддержки между двумя или более частями, изображенными на фиг.1, или любую их комбинацию. Например, сеть 120 может включать в себя множество различных сетей, таких как частная сеть платежных транзакций, сделанная доступной для MPI 110, сервера 112 каталогов и ACS 114, и, отдельно, общедоступный Интернет, который доступен желаемым образом вычислительному устройству 108, эмитенту 104 и ACS 114, и т. д.

В вышеприведенном описании системы 100 применительно к определению, правомочен ли потребитель 102 для подтверждения аутентификации, сервер 112 каталогов передает запрос подтверждения аутентификации эмитенту 104 (посредством чего эмитент 104 затем определяет, правомочен ли потребитель 102 для подтверждения аутентификации). В качестве альтернативы, сервер 112 каталогов может передавать запрос подтверждения аутентификации к ACS 114, где ACS 114 выполнен с возможностью затем оперировать, как описано (например, вместо эмитента 104, в качестве представителя для эмитента 104 и т. д.) выше, чтобы определять, правомочен ли потребитель 102 для подтверждения аутентификации. В обоих случаях два цикла, стандартно выполняемых в аутентификации потребителя 102 (например, удостоверение в регистрации платежного счета потребителя для усовершенствованной аутентификации и аутентификация потребителя 102 и т. д.), комбинируются в одиночную операцию, в которой сервер 112 каталогов передает запрос подтверждения аутентификации к эмитенту 104 или к ACS 114 (где эмитент 104 и/или ACS 114 отвечает соответствующим подтверждением, или нет, а не просто результатом регистрации). Более того, в обоих случаях сервер 112 каталогов передает запрос подтверждения аутентификации, посредством чего различные прошлые успешные аутентификации потребителя 102 и/или платежного счета потребителя могут быть использованы, чтобы впоследствии аутентифицировать потребителя 102 применительно к более поздней транзакции. Здесь сервер 112 каталогов может использовать прошлую успешную аутентификацию потребителя 102, чтобы уменьшать сложность, связанную с последующей аутентификацией потребителя 102 в более поздней транзакции без участия карты, например.

Фиг.2 изображает примерное вычислительное устройство 200, которое может включать в себя, например, один или несколько серверов, рабочих станций, персональных компьютеров, ноутбуков, планшетов, интеллектуальных телефонов, других подходящих вычислительных устройств и т. д. Дополнительно, вычислительное устройство 200 может включать в себя единственное вычислительное устройство или оно может включать в себя множество вычислительных устройств, расположенных в непосредственной близости, или множество вычислительных устройств, распределенных по географической области, при условии, что вычислительные устройства конкретным образом выполнены с возможностью функционировать, как описано здесь. В системе 100 эмитент 104, торгово-сервисное предприятие 106, MPI 110, сервер 112 каталогов, ACS 114, приобретатель 116 и платежная сеть 118 могут пониматься как вычислительные устройства в соответствии с, в целом или частично, вычислительным устройством 200 (посредством чего, например, процессор, включенный в соответствующее вычислительное устройство 200, в частности, выполнен посредством исполняемых инструкций, чтобы оперировать, как описано для данной части системы 100). Более того, вычислительное устройство 108, связанное с потребителем 102, может пониматься как соответствующее вычислительному устройству 200. При этом система 100 не должна рассматриваться как ограниченная вычислительным устройством 200, как описано ниже, поскольку другие вычислительные устройства и/или компоновки вычислительных устройств могут быть использованы. Дополнительно, различные компоненты и/или компоновки компонентов могут быть использованы в других вычислительных устройствах.

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

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

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

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

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

Фиг.3 изображает примерный способ 300 аутентификации пользователя со счетом применительно к сетевой транзакции на основе по меньшей мере прошлой аутентификации пользователя и/или счета. Примерный способ 300 описан (со ссылками на фиг.1) как в общем случае осуществляемый в MPI 110, сервере 112 каталогов, эмитенте 104 и ACS 114 системы 100 и с дополнительной ссылкой на вычислительное устройство 200. Однако следует понимать, что способы здесь не должны пониматься как ограниченные примерной системой 100 или примерным вычислительным устройством 200, и системы и вычислительные устройства здесь не должны пониматься как ограниченные примерным способом 300.

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

В ответ на ввод от потребителя 102, чтобы купить данный продукт(ы), в виртуальном местоположении торгово-сервисного предприятия, торгово-сервисное предприятие 106 обеспечивает учетные данные платежного счета для платежного счета потребителя (например, принятые от потребителя 102 или посредством приложения виртуального кошелька потребителя и т. д.) и дополнительную информацию, связанную с транзакцией (например, сумму транзакции, описание продукта и т. д.) в MPI 110 (как в общем случае описано выше в системе 100). MPI 110 затем составляет VEreq для транзакции и передает VEreq серверу 112 каталогов, на 302, чтобы определить, зарегистрирован ли платежный счет потребителя в службе усовершенствованной аутентификации (например, службе усовершенствованной аутентификации в соответствии с протоколом 3-D Secure^TM и т. д.) и аутентифицирован ли потребитель. Применительно к этому, VEreq может быть криптографически подписан и может включать в себя, например, информацию, принятую от торгово-сервисного предприятия 106, касающуюся потребителя 102 и/или базовой транзакции (например, учетные данные платежного счета для платежного счета потребителя, такие как номер счета и т. д.; информацию, связанную с транзакцией, такую как сумма транзакции, информация, касающаяся торгово-сервисного предприятия 106, и т. д.; и т. д.).

В свою очередь в способе 300 сервер 112 каталогов изначально определяет, на 304, зарегистрирован ли платежный счет потребителя в службе усовершенствованной аутентификации. Конкретным образом, различные эмитенты могут предлагать различные услуги потребителям, где услуги связаны со счетами, выданными потребителям. Для того чтобы применить применимую услугу, счета могут быть организованы в два диапазона счетов (например, по BIN или PAN и т. д.), где конкретные диапазоны счетов регистрируются в конкретных службах. Здесь эмитент 104 назначил номер счета потребителю 102 для его платежного счета, который находится в пределах диапазона, связанного со службой усовершенствованной аутентификации. Таким образом, в этом примере сервер 112 каталогов определяет, что BIN, связанный с платежным счетом потребителя, зарегистрирован в службе усовершенствованной аутентификации, на основе диапазона счетов, в который включен BIN для платежного счета потребителя.

После этого, когда счет зарегистрирован для службы усовершенствованной аутентификации, сервер 112 каталогов определяет, на 306, доступен ли потребитель 102 и/или платежный счет потребителя для усовершенствованной аутентификации, как описано здесь. Применительно к этому сервер 112 каталогов передает, на 308, запрос подтверждения аутентификации эмитенту 104. Запрос подтверждения аутентификации может включать в себя, например, VEreq и его связанное содержимое, в целом или частично, вместе с дополнительной информацией или без. При приеме эмитент 104 определяет, на 310, правомочен ли потребитель 102 для подтверждения аутентификации на основе, по меньшей мере частично, прошлой аутентификации потребителя 102, произошедшей в течение заданного интервала текущего времени (как в общем случае описано здесь). Заданным интервалом может быть пять минут, пятнадцать минут, двадцать минут, тридцать минут, час, или больше, или меньше и т. д. В этом примере заданный интервал равен пятнадцати минутам. Таким образом, принимая в расчет то, что потребитель 102 ранее был аутентифицирован эмитентом 104 около четырех минут до инициирования текущей транзакции, применительно к тому, что потребитель 102 осуществляет доступ к финансовому приложению, обеспеченному эмитентом 104 и установленному на вычислительном устройстве 108 потребителя, эмитент 104 определяет, что потребитель 102 правомочен для подтверждения аутентификации, поскольку прошлая аутентификация, около четырех минут до немедленной транзакции, находится внутри пятнадцатиминутного заданного интервала.

Другие параметры и/или условия, которые могут быть задействованы эмитентом 104, чтобы определить правомочность потребителя 102 для подтверждения аутентификации, могут включать в себя, например, надежность и/или тип прошлой аутентификации (например, биометрическая аутентификация, аутентификация с одноразовым кодом доступа, аутентификация с паролем, аутентификация с PIN и т. д.) (обеспеченные в общем порядке надежности), сумму транзакции, торгово-сервисного предприятия 106, задействованного в транзакции, прошлые подозрительные транзакции со счетом потребителя и т. д. В общем, например, комбинации вышеперечисленного могут задействоваться, чтобы варьировать требования для аутентификации между эмитентами. Например, один эмитент может требовать биометрической аутентификации в течение последнего дня. В то время как другие могут требовать аутентификацию с паролем или кодом доступа в течение последних двух или трех дней. И дополнительные эмитенты могут требовать биометрическую аутентификацию в течение трех дней или пароли в течение шести часов. Следует понимать, что определение правомочности потребителя 102 для подтверждения аутентификации может основываться на любом подходящем параметре(ах) или условии(ях), связанных с транзакцией, прошлой аутентификацией, счетом и т. д.

Когда эмитент 104 определяет, что потребитель 102 правомочен для подтверждения аутентификации, эмитент 104 аутентифицирует потребителя 102, на 312, и обеспечивает подтверждение аутентификации (или одобрение), на 314, серверу 112 каталогов. Подтверждение аутентификации будет включать в себя информацию, которая индивидуальна для транзакции, но лишена персональной идентифицирующей информации, относящейся к потребителю 102. Здесь подтверждение аутентификации обеспечено в виде AAV (которое является зашифрованным значением, которое сервер 112 каталогов не может дешифровать или интерпретировать), но может включать в себя другую информацию или коды и т. д. в других вариантах осуществления. В свою очередь, сервер 112 каталогов обеспечивает подтверждение аутентификации обратно в MPI 110, на 316. Подтверждение аутентификации включает в себя AAV (или другую подходящую информацию), принятое от эмитента 104 применительно к выполнению усовершенствованной аутентификации потребителя 102 и/или платежного счета потребителя.

Однако когда эмитент 104 определяет, что потребитель 102 не правомочен для подтверждения аутентификации (на 310), эмитент 104 вместо этого обеспечивает инструкцию серверу 112 каталогов, на 318, указывающую, что никакое подтверждение не доступно для потребителя 102 и что необходимо потребовать стандартную аутентификацию потребителя 102 и/или платежный счет потребителя (как указано ниже линии AA на фиг.3). Применительно к этому, сервер 112 каталогов контактирует с ACS 114, на 320, и ACS 114 выполняет аутентификацию. Например, ACS 114 изначально удостоверяется, на 322, в регистрации платежного счета потребителя и/или эмитента 104 с ACS 114 (для желаемой службы аутентификации). Затем, когда такая регистрация подтверждается, ACS 114 аутентифицирует потребителя 102, на 324. Применительно к последнему, ACS 114 обеспечивает сетевой адрес (например, URL и т. д.) обратно виртуальному местоположению торгово-сервисного предприятия 106 через сервер 112 каталогов и MPI 110. Торгово-сервисное предприятие 106 затем в свою очередь вызывает сетевой адрес. Это позволяет ACS 114 взаимодействовать с потребителем 102 через вычислительное устройство 108 потребителя, посредством чего ACS 114 может запросить персональный идентификационный номер (PIN), биометрическую характеристику или другую информацию от потребителя 102, подходящую, чтобы аутентифицировать потребителя 102 (например, удостовериться посредством ссылочных данных, включенных в ACS 114 или в платежной сети 118 и т. д.). При аутентификации потребителя ACS 114 отвечает MPI 110, на 326, подтверждением (например, AAV и т. д.), или ACS 114 отвечает MPI 110 другим сообщением, когда аутентификация потребителя оказалась безуспешной (например, подтверждением, несмотря на отказ, указанием отказа, ответом отсутствия аутентификации и т. д.).

Затем в способе 300, независимо от того, обеспечено ли подтверждение аутентификации от эмитента 104 или ACS 114, торгово-сервисное предприятие 106 составляет запрос авторизации транзакции и отправляет его для одобрения эмитентом 104, как описано выше в системе 100.

Опционально, как указано ниже линии BB на фиг.3, эмитент 104 в определении, правомочен ли потребитель для подтверждения аутентификации (на 310), может определять, что транзакция должна быть отклонена полностью (без дополнительно попыток аутентифицировать потребителя 102 посредством ACS 114). Например, платежная карта, используемая в транзакции, может быть связана с платежным счетом, для которого платежная карта была заявлена как потерянная или украденная (в широком смысле, на основе условия мошенничества), в случае чего эмитент 104 может принять решение отклонить все транзакции для платежного счета. Кроме того, эмитент 104 может задействовать один или несколько факторов риска, чтобы определить, что транзакция должна быть отклонена, таких как, например, фактор, связанный с суммой транзакции, существование подозрительных структур расходов для платежного счета, скоростных атак, связанных с платежным счетом, и т. д. В таких случаях эмитент 104 обеспечивает, на 328, инструкцию отклонения серверу 112 каталогов. В ответ сервер 112 каталогов обеспечивает инструкцию отклонения для транзакции, на 330, в MPI 110 (и к торгово-сервисному предприятию 106, который может затем отклонить транзакцию с потребителем 102).

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

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

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

Как будет понятно на основе вышеприведенного технического описания, вышеописанные варианты осуществления раскрытия могут осуществляться с использованием методик компьютерного программирования или инжинерии, включающих в себя компьютерные программные средства, программно-аппаратные средства, аппаратные средства или любую их комбинацию или подмножество, причем технический эффект может достигаться путем выполнения по меньшей мере одной из следующих операций, на которых: (a) принимают, в сервере каталогов, запрос аутентификации, связанный с транзакцией, от плагина сервера торгово-сервисного предприятия (MPI), причем запрос аутентификации включает в себя учетные данные платежного счета, связанные со счетом; (b) передают, посредством сервера каталогов, запрос подтверждения аутентификации субъекту, связанному со счетом, отличному от сервера управления доступом (ACS), связанного с эмитентом счета; (c) обеспечивают, посредством сервера каталогов, подтверждение аутентификации в MPI, в ответ на запрос аутентификации, когда субъект, связанный со счетом, обеспечивает подтверждение аутентификации для транзакции на основе прошлой аутентификации пользователя, посредством чего разрешается продолжение транзакции на основе подтверждения аутентификации и без аутентификации, индивидуальной для транзакции; (d) требуют аутентификацию пользователя на основе запроса аутентификации, от ACS, когда субъект обеспечивает инструкцию требовать аутентификацию пользователя или не отвечает на запрос подтверждения аутентификации; (e) принимают, в вычислительном устройстве, запрос подтверждения аутентификации от сервера каталогов, причем запрос подтверждения аутентификации связан со счетом потребителя и зарегистрирован в службе усовершенствованной аутентификации; (f) определяют, правомочен ли потребитель для подтверждения аутентификации на основе, по меньшей мере частично, прошлой аутентификации потребителя; (g) обеспечивают подтверждение аутентификации для транзакции серверу каталогов, когда потребитель правомочен для подтверждения аутентификации, посредством чего транзакция, направленная на счет, зарегистрированный в службе усовершенствованной аутентификации, разрешается без аутентификации, индивидуальной для транзакции; и (h) обеспечивают указание требовать аутентификацию потребителя, когда потребитель не правомочен для подтверждения аутентификации.

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

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

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

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

Ни один из элементов, перечисленных в формуле изобретения, не подразумевается как элемент "средство-плюс-функция" в рамках значения 35 U.S.C. §112(f), если элемент в явной форме не упомянут с использованием словосочетания "средство для" или, в случае пункта формулы способа, не используется словосочетание "операция для" или "этап для".

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

Claims

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

сервер каталогов, соединенный с возможностью осуществлять связь с плагином сервера торгово-сервисного предприятия (MPI), связанным с торгово-сервисным предприятием, и осуществлять связь с эмитентом счета, связанного с пользователем;

причем сервер каталогов выполнен с возможностью:

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

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

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

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

требовать аутентификацию пользователя на основе упомянутого запроса аутентификации, от ACS, когда никакое подтверждение аутентификации не принимается от эмитента в ответ на запрос подтверждения аутентификации.

2. Система по п.1, при этом запрос подтверждения аутентификации включает в себя запрос аутентификации; подтверждение аутентификации включает в себя значение аутентификации владельца счета (AAV); и одобрение аутентификации включает в себя AAV из подтверждения аутентификации.

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

4. Система по п.3, при этом упомянутое по меньшей мере одно условие включает в себя сумму транзакции и/или торгово-сервисное предприятие, задействованное в транзакции.

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

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

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

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

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

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

9. Система по п.1, в которой персональная идентифицирующая информация (PII) опускается из запроса подтверждения аутентификации и подтверждения аутентификации.

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

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

передают посредством сервера каталогов запрос подтверждения аутентификации субъекту, связанному со счетом, отличному от сервера управления доступом (ACS), связанного с эмитентом счета;

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

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

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

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

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

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

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

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

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

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

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

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

17. Способ по п.15, в котором подтверждение аутентификации включает в себя значение аутентификации владельца счета (AAV), индивидуальное для транзакции, но лишено персональной идентифицирующей информации (PII) потребителя.

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