СИСТЕМЫ, АППАРАТ И СПОСОБЫ ДЛЯ УСОВЕРШЕНСТВОВАННОЙ АУТЕНТИФИКАЦИИ Российский патент 2018 года по МПК G06Q20/00 

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

Эта заявка испрашивает приоритет предварительной патентной заявке США, номер 61/913,670, поданной 9 декабря, 2013, содержимое которой этим включается сюда по ссылке для всех целей.

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

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

Эмитенты карт и другие финансовые организации сейчас предлагают или используют стандартизированные протоколы транзакций в сети Интернет, чтобы улучшать выполнение сетевых транзакций и чтобы ускорять рост электронной торговли. При некоторых стандартизированных протоколах эмитенты карт или банки-эмитенты могут аутентифицировать транзакции, тем самым уменьшая вероятность мошенничества и ассоциированных возвратных платежей, связанных с транзакциями, не авторизованными держателями карт. Одним примером такого стандартизированного протокола является протокол защиты 3-D. Наличие аутентифицированной транзакции может давать результатом то, что эмитент принимает ответственность за мошенничество, если оно произойдет, несмотря на усилия по аутентификации держателя карты во время сетевой покупки. Эмитенты карт или банки-эмитенты гарантируют торговцам, что они получат оплату за аутентифицированные эмитентами транзакции. Протокол защиты 3-D (3DS) является совместимым с и лежит в основе программ аутентификации, предлагаемых эмитентами карт (например, Verified by Visa или MasterCard SecureCode), чтобы аутентифицировать клиентов для торговцев во время удаленных транзакций, таких как транзакции, ассоциированные с сетью Интернет.

Протокол защиты 3-D усиливает существующие функциональные возможности шифрования уровня защищенных сокетов (SSL) и обеспечивает улучшенную защиту посредством "аутентификации" эмитентом держателя карты во время сеанса сетевых покупок. Часть программного обеспечения, называемая подключаемый модуль торговца (MPI), используется участвующими торговцами, чтобы осуществлять обмен сообщениями, передавать информацию и запрашивать участников, чтобы устанавливать сеанс аутентификации между держателем карты и их эмитентом карты во время сетевой покупки. Услуги протокола защиты 3-D, в общем, основываются на модели трех областей - области эмитента, области эквайера и взаимодействия. Эмитент является ответственным за управление регистрацией держателей карт в услуге и за аутентификацию держателей карт во время сетевых транзакций. Эквайер является ответственным за определение процедур, чтобы торговцы, участвующие в транзакциях в сети Интернет, работали согласно соглашению с эквайером, и за обеспечение внутренней обработки для аутентифицированных транзакций. Область взаимодействия обеспечивает обмен транзакциями между другими двумя областями с помощью общего протокола и совместно используемых услуг.

Держатели карт и их банки могут относиться к "области эмитента", торговцы и их банки могут относиться к "области эквайера". Связь между банками-эмитентами и банками-эквайерами или финансовыми организациями и инфраструктурой эмитентов карт может относиться к "области взаимодействия". При осуществлении транзакций с совместимыми с защитой 3-D банками и торговцами потребитель может иметь такой же опыт покупок в сети Интернет, как и ранее, за исключением того, что имеется отдельный элемент окна или i-фрейма аутентификации от банка держателя карты для определения того, является ли осуществляющая транзакцию сторона действительно зарегистрированным держателем карты. Поток транзакции для сетевой транзакции покупки в сети Интернет согласно протоколу может быть следующим:

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

(2) Торговец затем посылает сообщение посредством MPI в сервер или систему каталогов, который, в свою очередь, запрашивает эмитента карты установить, является ли клиент зарегистрированным в программе защиты 3-D.

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

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

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

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

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

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

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

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

Фиг. 1 является блок-схемой системы транзакций согласно одному варианту осуществления изобретения.

Фиг. 2-4 являются блок-схемами части системы транзакций в соответствии с некоторыми вариантами осуществления.

Фиг. 5А-6С являются диаграммами последовательности операций, иллюстрирующими обработки согласно некоторым вариантам осуществления.

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

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

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

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

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

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

Признаки некоторых вариантов осуществления теперь будут описываться посредством ссылки на фиг. 1, где показана система 100 транзакций в соответствии с некоторыми вариантами осуществления. Система в соответствии с некоторыми вариантами осуществления включает в себя некоторое количество устройств и сущностей, взаимодействующих для проведения транзакции. Например, держатели платежных карт могут взаимодействовать с одним или более устройствами 102 потребителя, чтобы инициировать финансовые транзакции. Устройства 102 потребителя могут включать в себя, например, мобильные телефоны, компьютеры, приставки к телевизору или другие устройства (такие как игровые пульты или подобное). Транзакции являются транзакциями без присутствия карты (например, где никакая физическая карта не представляется торговцу во время транзакции). Варианты осуществления обеспечивают возможность выполнять такие транзакции без присутствия карты с более высоким уровнем аутентификации, чем в прошлом. Как здесь используется, устройства 102 потребителя упоминаются как являющиеся частью "области взаимодействия с потребителем" настоящего изобретения.

Каждое из устройств 102 потребителя может находиться в связи с одним или более устройствами в "области взаимодействия". Область взаимодействия может быть, по меньшей мере, частично составлена сетью 103 аутентификации. Сеть 103 аутентификации может включать в себя любое устройство или компьютер, которое задействуется в или обеспечивает принятие решений по отношению к тому, какой тип или типы обработки аутентификации должны использоваться для заданной транзакции. Сеть 103 аутентификации может включать в себя, например: (A) один или более серверов или устройств, обеспечивающих интерфейс 104 прикладного программирования ("API") интерфейса потребителя, (B) один или более серверов или устройств, обеспечивающих сервер 106 каталогов, и (C) один или более серверов или устройств, обеспечивающих услуги 108 по поручению (OBO).

Устройства и системы в "области взаимодействия" находятся в связи с одним или более устройствами или системами в "области эмитента", как, например, одним или более серверами 110 управления доступом и одним или более эмитентами 112.

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

В соответствии с некоторыми вариантами осуществления настоящее изобретение обеспечивает возможность улучшенного опыта клиента во взаимодействиях аутентификации для разных типов устройств потребителя, нежели предыдущие системы аутентификации. Например, в некоторых вариантах осуществления необходимость в подключаемом модуле торговца может уменьшаться или устраняться в некоторых ситуациях. Дополнительные варианты осуществления обеспечивают возможность торговцам поддерживать требуемые им впечатление и ощущение во время транзакций. В некоторых вариантах осуществления могут обеспечиваться характерные для контекста наборы сообщений, например транзакции снабжения маркерами могут обеспечиваться поддержкой аутентификации. В соответствии с некоторыми вариантами осуществления взаимодействие между устройством 102 потребителя и устройством в области взаимодействия может зависеть от выбора аутентификации, сделанного торговцем. Например, торговец может использовать стандартный MPI для аутентификации транзакций, использующих разные устройства 102 потребителя, и в таких вариантах осуществления взаимодействие между устройством 102 потребителя и устройством в области взаимодействия может включать в себя взаимодействие с сетью 103 аутентификации. Торговец может также (или вместо этого) выбирать использовать API для взаимодействия во время транзакций аутентификации, и в таких вариантах осуществления взаимодействие между устройством 102 потребителя и устройством в области взаимодействия может включать в себя взаимодействие с API 104 интерфейса потребителя. В каждом случае область взаимодействия также может вызываться, чтобы выполнять одну или более услуг по поручению посредством применения правил, ассоциированных с устройством 108 услуг по поручению. В соответствии с некоторыми вариантами осуществления, применение любых услуг 108 по поручению может основываться на информации, ассоциированной с платежной картой, используемой потребителем в устройстве 102 потребителя. Например, в некоторых вариантах осуществления то, должна ли какая-либо услуга по поручению (OBO) применяться в заданной транзакции, может основываться на правилах уровня BIN или счета, установленных эмитентом платежных карт. В дополнение к или вместо конфигурации обеспечения возможности принятия решения об услуге OBO эмитентом платежных карт, система 100 транзакций также может включать в себя конфигурацию такого принятия решения держателем карты/пользователем платежной карты. В некоторых вариантах осуществления, когда влияние имеют как сконфигурированные эмитентом, так и сконфигурированные пользователем правила, может устанавливаться подходящая иерархия правил, чтобы определять, какое правило или правила применять в заданном случае. В некоторых вариантах осуществления иерархия правил может устанавливаться посредством или в соответствии с эмитентом, чтобы размещать одно или более сконфигурированных пользователем правил. В некоторых вариантах осуществления иерархия правил может работать, чтобы замещать сконфигурированное пользователем правило в пользу противоположного правила, установленного в соответствии с вводом конфигурации эмитента.

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

В соответствии с некоторыми вариантами осуществления связь между областью взаимодействия и областью эмитента может включать в себя одно или более взаимодействий (в отличие от предыдущих решений аутентификации). Например, взаимодействие аутентификации может включать в себя связь между устройством 102 потребителя, API 104 интерфейса потребителя и эмитентом 112. Таким образом, эмитенты, торговцы и потребители могут участвовать в системе аутентификации настоящего изобретения без необходимости взаимодействовать с ACS или без необходимости использовать MPI. Такие взаимодействия также могут вызывать применение одной или более услуг 108 по поручению. В соответствии с некоторыми вариантами осуществления использование API 104 интерфейса потребителя обеспечивает возможность обеспечения веб-услуг аутентификации для широкого многообразия устройств. Дополнительно, услуги по поручению могут делаться доступными для всех эмитентов, обеспечивая возможность опыта улучшенных транзакций. Например, эмитент может выбирать использовать принятие решений на основе рисков (или "RBD"), и услуга RBD может применяться к транзакциям, ассоциированным с этим эмитентом (или предварительно определенным поднабором счетов, ассоциированных с эмитентом). В соответствии с некоторыми вариантами осуществления сеть 103 аутентификации может быть конфигурируемой для каждого эмитента 112, обеспечивая возможность уникальной маршрутизации в расчете на тип сообщения и в расчете на диапазон BIN (или номеров счетов). Например, некоторые элитные карты могут быть сконфигурированы с возможностью использовать услугу по поручению, обеспечивающую RBD, и все другие типы карт от этого эмитента могут посылаться в ACS для обработки аутентификации. В некоторых вариантах осуществления использование API 104 интерфейса потребителя обеспечивает возможность ACS 110 и/или эмитенту 112 взаимодействовать с устройством 102 потребителя посредством защищенного канала.

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

В потоке аутентификации из фиг. 2 может осуществляться снабжение маркерами (то есть с использованием маркера платежа при использовании в, по меньшей мере, части потока транзакции вместо PAN (первичного номера счета)). По этой причине устройство 102 потребителя может взаимодействовать с сервером 202 модуля запроса маркеров так же, как провайдером 114 услуг торговца. В примере, показанном на фиг. 2, взаимодействие между устройством 102 потребителя и модулем 202 запроса маркеров и между устройством 102 потребителя и провайдером 114 услуг торговца может осуществляться посредством API. Аналогично, любое необходимое взаимодействие между ACS 110 и эмитентом 112 (с одной стороны) и устройством 102 потребителя (с другой стороны) также может осуществляться посредством API. Связь между сетью 103 аутентификации, провайдером 114 услуг торговца и модулем 202 запроса маркеров может быть основанной на Веб, посредством XML (расширяемого языка разметки), JSON (формата обмена данными объектов JavaScript) или другого формата связи.

На фиг. 3, изображен один вариант осуществления, где устройство 102 потребителя может использоваться либо в транзакции электронной торговли - блок 302 (посредством связи API с сетью 103 аутентификации) так же, как в транзакции идентификации и верификации ("ID&V") - блок 304 (посредством связи API с сетью 103 аутентификации). В некоторых транзакциях сеть 103 аутентификации находится в связи с ACS 110, и в других сеть 103 аутентификации находится в связи с эмитентом 112.

На фиг. 4, изображен один вариант осуществления с различными этапами передачи сообщений, идентифицированными и показывающими использование API настоящего изобретения совместно с транзакцией снабжения маркерами. На S402, держатель карты/пользователь инициирует обработку ID&V посредством управления устройством 102 потребителя. На S404, модуль 202 запроса маркеров посылает PAN и всю применимую информацию устройства посредством API в сеть 103 аутентификации.

На S406, сеть 103 аутентификации принимает запрос и определяет, что применимый поток обработки предназначен для ID&V. Как часть этого этапа, сеть 103 аутентификации ищет соответствующий интерфейс эмитента и посылает запрос ID&V через интерфейс эмитенту 112. (Если никакой соответствующий интерфейс эмитента не является доступным, сервер аутентификации отвечает соответствующим образом модулю 202 запроса маркеров, и обработка завершается в этой точке.)

На S408, эмитент 112 отвечает сети 103 аутентификации, чтобы подтвердить поток обработки ID&V.

На S410, сеть 103 аутентификации пересылает ответ эмитента и ссылку API эмитента назад в модуль 202 запроса маркеров.

На S412, модуль 202 запроса маркеров посылает запрос подтверждения ID&V в веб-услугу эмитента 112 через устройство 102 потребителя.

На S414, эмитент 112 принимает запрос подтверждения ID&V.

На S416, эмитент 112 проверяет на действительность запрос и затем ACS (фиг. 1, на фиг. 4 не показан) создает сообщение ответа ID&V.

На S418, эмитент 112 возвращает ответ ID&V в модуль 202 запроса маркеров через устройства 102 потребителя. (В дополнение, эмитент 112 может посылать выбранные записи транзакций ID&V в сервер истории, который не показан.)

На S420, модуль 202 запроса маркеров принимает ответ ID&V.

На S422, модуль 202 запроса маркеров проверяет на действительность ответ ID&V.

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

Иллюстративные примеры потоков транзакций, которые включают в себя признаки услуг по поручению настоящего изобретения, показаны на фиг. 5А-6С. На фиг. 5А-6С, показано использование подключаемого модуля торговца ("MPI") - однако варианты осуществления могут включать в себя потоки без MPI (например, когда связь между устройством 102 потребителя и уровнем взаимодействия осуществляется посредством API или другого соединения). В иллюстративном варианте осуществления из фиг. 5A/5B, показан первый сценарий, где одна или более услуг по поручению применяются к транзакции во время обработки. В обработке из фиг. 5A, держатель карты/пользователь взаимодействует (этап 502, фиг. 5A) с устройством 102 потребителя, чтобы провести транзакцию с торговцем; это может включать в себя то, что пользователь вводит данные счета платежной карты на странице оформления заказа торговца электронной торговли. Торговец предписывает передачу данных платежного счета, ассоциированных с держателем карты, (этап 504) в область взаимодействия (например, в вышеупомянутый MPI; это может происходить посредством вызова API или программного вызова, например).

На этапе 506, MPI может генерировать и передавать соответствующее сообщение в сеть 103 аутентификации (фиг. 1). Ссылаясь снова на фиг. 5A, на этапе 508 принятия решения, сеть 103 аутентификации (например, посредством сервера 106 каталогов) осуществляет определение маршрутизации на основе данных платежного счета (например, на основе BIN платежного счета). На основе определения маршрутизации, может осуществляться определение (на этапе 510 принятия решения) того, что должны применяться некоторые услуги по поручению (например, на основе информации, обеспеченной эмитентом платежного счета). Снова это определение может осуществляться сетью 103 аутентификации (возможно посредством сервера 106 каталогов).

На этапе 512, сеть 103 аутентификации/сервер 106 каталогов затем предписывает передачу сообщения (такого как, например, сообщение XML или подобное) в услуги 108 по поручению для обработки. На этапе 514 принятия решения, услуга 108 OBO может определять, что соответствующее приложение, которое она содержит, приняло сообщение, указанное выше по отношению этапу 512. В иллюстративном примере, показанном на фиг. 5A, обработка 108 услуг по поручению определяет (этап 516 принятия решения), что держатель карты является держателем карты низкого риска (например, с использованием услуги принятия решений на основе рисков) и ответ передается (этап 518) от услуги 108 OBO в сеть 103 аутентификации с ответом аутентификации. Когда аутентификация считается успешной, как здесь предполагается, то ответ может включать в себя криптограмму транзакции или другой маркер, такой как "AAV" (значение аутентификации счета). Данные, обеспеченные услугой 108 OBO, пересылаются (этап 520, фиг. 5B) из сети 103 аутентификации в MPI. Затем, как указано на 522 на фиг. 5B, MPI может завершать транзакцию 3DS и передавать требуемые элементы данных торговцу 114 (фиг. 1), чтобы обеспечивать возможность торговцу продолжать (этап 524) с тем, что может быть, по существу, стандартным запросом авторизации к эквайеру (не показан). Транзакция затем может завершаться в соответствии со стандартными практиками для транзакций электронной торговли.

В некоторых вариантах осуществления обработка посредством области взаимодействия может включать в себя определение того, что для транзакции может требоваться некоторая "расширенная" или увеличенная аутентификация. Такой пример показан в диаграмме последовательности операций, сформированной посредством фиг. 6A/6B/6C, где услуга 108 по поручению определяет, что держатель карты или транзакция требует способ (способы) дополнительной аутентификации и предписывает некоторую дополнительную обработку для выполнения потребителем и/или торговцем, чтобы завершать транзакцию. Таким образом, варианты осуществления обеспечивают возможность выполнения улучшенной обработки аутентификации. Эмитенты способны обеспечивать "расширенные" или дополнительные услуги, которые могут легко применяться к транзакциям.

Вышеизложенное описание, относящееся к этапам 502-514 из фиг. 5A, является также применимым к этапам 602-614 из фиг. 6A. В иллюстративном примере, показанном на фиг. 6A, обработка 108 услуги OBO определяет (этап 616 принятия решения), что держатель карты не имеет достаточно низкий риск, чтобы пропускать расширенную обработку. Другими словами, на основе принятия решений на основе рисков (RBD), обработка 108 услуги OBO определяет, что требуется расширение. Следовательно, как показано на этапе 618 на фиг. 6B, обработка 108 услуги OBO может инициировать вызов к держателю карты/пользователю через устройство 102 потребителя и/или согласно любому способу или способам, которые эмитент счета карты установил для осуществления контакта с держателем карты для расширенной обработки. Как показано на этапе 620, держатель карты принимает запрос авторизации, который может включать в себя один или более из маркера одиночного использования, ссылку электронной почты, извещающего уведомления, запроса обеспечить биометрическую аутентификацию и т.д.

Совместно с этапами обработки, показанными на 618 и 620, обработка 108 услуги OBO передает (этап 622) ответ в сеть 103 аутентификации, где ответ может быть сообщением с установленным флагом расширения, чтобы указывать, что должна выполняться расширенная обработка. Сеть 103 аутентификации, в свою очередь, может формулировать и передавать (этап 624) ответ в MPI, где ответ имеет установленный флаг расширения. MPI затем инициирует (этап 626) вызов расширения в канал интерфейса представления посредством отправки через устройство 102 потребителя. Держатель карты/пользователь затем вовлекается (этап 628) посредством управления устройством 102 потребителя, чтобы открыть интерфейс расширения в окне в устройстве 102 потребителя посредством использования интерфейса представления.

На этапе 630, сеть 103 аутентификации, посредством интерфейса представления, загружает веб-контент (то есть HTML, Javascript и подобное) в веб-браузер посредством i-фрейма, перенаправления страницы и т.д., или взаимодействует с пакетом средств разработки программного обеспечения (SDK), в устройстве 102 потребителя, и вызывает ACS 110 посредством XML с ответом расширения на основе ввода/ответа держателя карты на требование (требования) расширенной обработки.

На этапе 632 принятия решения, обработка 108 услуги OBO может принимать результирующее сообщение и определять, является ли ответ держателя карты действительным. Затем, на этапе 634 (фиг. 6C), обработка 108 услуги OBO может формулировать и посылать в сеть 103 аутентификации/интерфейс представления ответ аутентификации. Когда аутентификация считается успешной, как здесь предполагается, то ответ может включать в себя криптограмму транзакции или другой маркер, такой как "AAV" (значение аутентификации счета).

На этапе 636, сеть 103 аутентификации/интерфейс представления может завершать сеанс с держателем карты посредством устройства 102 потребителя и посылать ответ с MPI. Затем, как указано на 638 на фиг. 6C, MPI может завершать транзакцию 3DS и передавать требуемые элементы данных торговцу 114 (фиг. 1), чтобы обеспечивать возможность торговцу продолжать (этап 640) с тем, что может быть, по существу, стандартным запросом авторизации к эквайеру (не показан). Транзакция затем может завершаться в соответствии со стандартными практиками для транзакций электронной торговли.

Фиг. 7 является блок-схемой компьютерной системы/компьютерной архитектуры, которая может составлять один или более компонентов системы 100 транзакций из фиг. 1. Например, компьютерная система 702, изображенная на фиг. 7, может осуществлять одно или более из сервера 106 каталогов и/или компьютера 108 услуг OBO и/или другого компонента сети 103 аутентификации. Как описано дополнительно ниже, компьютерная система 702 может быть запрограммирована в соответствии с аспектами настоящего изобретения, чтобы обеспечивать одну или более из функций, здесь описанных.

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

Компьютерная система 702 может включать в себя компьютерный процессор 700, функционально соединенный с устройством 701 связи, запоминающим устройством 704, устройством 706 ввода и устройством 708 вывода.

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

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

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

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

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

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

Программы, сохраненные запоминающим устройством 704, могут включать в себя, например, прикладную программу 710 обработки транзакций. Прикладная программа 710 обработки транзакций может управлять процессором 700, чтобы обеспечивать возможность компьютерной системе 702 выполнять одну или более из относящихся к транзакциям функций, описанных в этом раскрытии. Например, это может включать в себя, по меньшей мере, частично, определение того, какой тип или типы услуги (услуг) аутентификации должны выполняться для заданной транзакции на основе относящейся к счету информации, такой как номер счета, ассоциированный со счетом, вовлеченным в текущую транзакцию. Транзакции, обрабатываемые компьютерной системой 702, могут включать в себя платежные транзакции и транзакции ID&V (снабжения маркерами).

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

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

Запоминающее устройство 704 также может хранить, и компьютерная система 702 также может исполнять другие программы, которые не показаны. Например, такие программы могут включать в себя приложение обеспечения докладов, которое может отвечать на запросы от системных администраторов на доклады о действиях, выполненных компьютерной системой 702. Другие программы также могут включать в себя, например, программы хостинга веб-сайтов, программы управления базами данных, драйверы устройств и т.д.

Запоминающее устройство 704 также может хранить одну или более баз 716 данных, требуемых для работы компьютерной системы 702.

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

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

В некоторых вариантах осуществления правила аутентификации также могут подвергаться конфигурированию торговцами в, по меньшей мере, некоторых случаях. Например, когда торговец имеет сохраненную информацию счета клиента (и/или маркер платежа) и торговец хорошо знает клиента (и/или выполнил свою собственную оценку риска для клиента с удовлетворительным результатом), торговец может предпочесть пропустить RBD/возможное расширение посредством сети 103 аутентификации. Таким образом, для заданного номера счета/маркера платежа и заданного торговца транзакция может обрабатываться системой 100 транзакций/сетью 103 аутентификации таким образом, что обработка аутентификации может определяться в соответствии с вводом конфигурационных данных от торговца. Согласно другому иллюстративному варианту осуществления торговец может конфигурировать принятие решений в отношении аутентификации таким образом, что транзакция не будет выполняться, если эмитент счета не поддержит аутентификацию в соответствии с моделью 3DS. Сеть 103 аутентификации может осуществлять определение в отношении этого момента на основе BIN для представленного номера счета.

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

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

Фиг. 8 и 9 иллюстрируют иллюстративные обработки для выполнения ID&V (идентификации и верификации) в соответствии с аспектами настоящего изобретения. Как следует понимать специалистам в данной области техники, ID&V может выполняться совместно с операциями снабжения маркерами.

В сценарии из фиг. 8, ID&V выполняется без расширения. На этапе 802 на фиг. 8, модуль 202 запроса маркеров (фиг. 2) посылает запрос ID&V в сеть 103 аутентификации. Продолжая ссылаться на фиг. 8, на этапе 804 принятия решения, сеть 103 аутентификации (например, посредством сервера 106 каталогов, фиг. 1) осуществляет определение маршрутизации на основе данных платежного счета (например, на основе BIN платежного счета). На этапе 806, сеть 103 аутентификации формулирует и посылает сообщение, которое включает в себя запрос на аутентификацию. Это сообщение может посылаться в ACS 110 эмитента (фиг. 1), с конкретным определенным ACS и/или контентом сообщения/запроса, определенным на этапе 804.

На этапе 808 принятия решения, ACS 110 эмитента выбирает требуемый тип обработки аутентификации. На этапе 810 принятия решения, ACS 110 эмитента определяет идентификационную информацию держателя карты и/или определяет, до какой степени имеется риск, связанный с текущим запросом аутентификации. В иллюстративном примере, показанном на фиг. 8, ACS 110 эмитента определяет, что запрос имеет низкий риск, и передает (этап 812) ответ назад в сеть 103 аутентификации с состоянием аутентификации. Когда аутентификация считается успешной, как здесь предполагается, то ответ может включать в себя криптограмму или другой маркер, такой как "AAV" (значение аутентификации счета).

На этапе 814, сеть 103 аутентификации может формулировать и посылать ответ в модуль 202 запроса маркеров, чтобы указывать состояние аутентификации. Затем, на этапе 816, модуль 202 запроса маркеров может продолжать обработку снабжения маркерами.

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

Вышеизложенное описание этапов 802-806 совместно с фиг. 8 является также применимым к этапам 902-906, показанным на фиг. 9. На этапе 908 принятия решения на фиг. 9, ACS 110 эмитента выбирает требуемый тип обработки аутентификации. В этом иллюстративном примере предполагается, что ACS 110 эмитента определяет (например, в соответствии с RBD), что должно требоваться расширение. Оно может включать в себя процесс аутентификации пользователя (этап 910), который может влечь за собой взаимодействие держателя карты/пользователя с устройством 102 потребителя, чтобы выполнять функцию, такую как процедура осуществления входа в систему для клиента банка, проверка действительности маркеров и т.д.

На этапе 912 принятия решения, ACS 110 эмитента может учитывать результат/ответ пользователя, обеспеченный на этапе 910, и на этой основе может определять идентификационную информацию держателя карты и/или определять, до какой степени имеется риск, связанный с текущим запросом аутентификации. В иллюстративном примере, показанном на фиг. 9, ACS 110 эмитента определяет, что запрос имеет низкий риск, и передает (этап 914) ответ назад в сеть 103 аутентификации с состоянием аутентификации. Когда аутентификация считается успешной, как здесь предполагается, то ответ может включать в себя криптограмму или другой маркер, такой как "AAV" (значение аутентификации счета).

На этапе 916, сеть 103 аутентификации может формулировать и посылать ответ в модуль 202 запроса маркеров, чтобы указывать состояние аутентификации. Затем, на этапе 918, модуль 202 запроса маркеров может продолжать обработку снабжения маркерами.

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

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

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

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

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

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

1. Способ аутентификации держателя карты, содержащий:

прием, в компьютере сети аутентификации, запроса аутентификации, использующего счет;

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

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

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

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

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

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

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

6. Способ аутентификации держателя карты по п. 1, дополнительно содержащий:

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

7. Способ аутентификации держателя карты по п. 1, дополнительно содержащий:

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

8. Устройство аутентификации карты, содержащее:

процессор; и

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

прием запроса аутентификации, использующего счет;

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

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

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

9. Устройство по п. 8, в котором упомянутое определение упомянутой услуги аутентификации включает в себя определение того, что требуется аутентификация.

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

11. Устройство по п. 8, в котором процессор является компонентом компьютера сети аутентификации.

12. Устройство по п. 11, в котором компьютер сети аутентификации является сервером каталогов.

13. Устройство по п. 11, в котором компьютер сети аутентификации является компьютером услуг по поручению.

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

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

16. Способ аутентификации держателя карты, содержащий:

прием, в компьютере сети аутентификации, запроса аутентификации, использующего счет;

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

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

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

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

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

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

20. Способ аутентификации держателя карты по п. 16, дополнительно содержащий:

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