СПОСОБ И СИСТЕМА ДЛЯ СБОРА И ФОРМИРОВАНИЯ ОТЧЕТНОСТИ АУТЕНТИФИКАЦИОННЫХ ДАННЫХ Российский патент 2019 года по МПК G06Q20/40 

Перекрестные ссылки на родственные заявки

Эта заявка испрашивает приоритет по отношению и преимущество даты регистрации заявки США порядковый № 14/871,444, поданной 30 сентября 2015 года, которая, таким образом, содержится по ссылке в своей полноте.

Уровень техники

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

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

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

Краткое описание чертежей

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

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

Фиг. 2 - это иллюстративное изображение системы согласно некоторым вариантам осуществления в данном документе;

Фиг. 3 - это блок-схема последовательности операций процесса, в соответствии с некоторыми вариантами осуществления в данном документе;

Фиг. 4 - это иллюстративное изображение системы согласно некоторым вариантам осуществления в данном документе;

Фиг. 5 - это иллюстративное изображение системы согласно некоторым вариантам осуществления в данном документе;

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

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

Подробное описание изобретения

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

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

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

Множество способов, систем и решений было предложено, чтобы обеспечивать процесс аутентификации держателя карты. Одним решением является MasterCard® SecureCode™, распространяемый заявителем настоящего патентного документа, который определяет и обеспечивает уровень безопасности, относящейся к процессу аутентификации держателя карты. MasterCard® SecureCode™ процесс содержит аспекты основных функций спецификации протокола 3-D Secure™, версия 1.0.2, вступил в силу 17 апреля 2006 года. Эта конкретная реализация 3-D Secure™ (также называемого в данном документе "3DS") включает в себя поддержку для SPA (приложения безопасной оплаты) алгоритма и универсального поля аутентификации держателя карты (UCAF) без изменения спецификации, сообщений или протокола 3-D Secure™. В то время как некоторые аспекты в данном документе могут быть построены на, полагаться на и эффективно использовать различные аспекты спецификации 3-D Secure™, процессы и системы в данном документе не ограничиваются протоколом безопасности аутентификации или процессом, придерживающимся этой спецификации, или даже последовательностями аутентификации, которые могут соответствовать протоколу 3DS. Даже в некоторых случаях в данном документе, когда некоторые варианты осуществления могут быть описаны в контексте системы и процесса, взаимодействующего, по меньшей мере, с некоторыми аспектами спецификации 3-D Secure™, другие или альтернативные протоколы безопасности аутентификации могут быть использованы взамен без какой-либо потери общности, включая в себя те, которые теперь известны, и те, которые могут быть разработаны в будущем.

Фиг. 1 - это иллюстративная схема системы 100 для реализации процесса, который может быть использован для подтверждения владения счетом держателя карты (т.е., аутентификации держателя карты) в соответствии со спецификацией 3-D Secure™. По существу, фиг. 1 предоставляет, отчасти, общее представление системы и процесса аутентификации держателя карты в соответствии со спецификацией 3-D Secure™. Однако, все детали спецификации не обсуждаются в данном документе, поскольку полное подробное описание такой информации может стать понятным путем непосредственного обращения к спецификации 3-D Secure™ и/или ее обсуждению. Кроме того, поскольку концепции и детали, раскрытые в данном документе, не ограничиваются конкретным протоколом аутентификации, таким как 3DS, исчерпывающая детализация 3DS не является необходимым условием для полного понимания текущего описания изобретения.

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

Система 100 включает в себя держателя 105 карты, который взаимодействует с онлайн представительством торгово-сервисного предприятия. Типично, держатель 105 карты посещает веб-сайт торгово-сервисного предприятия с помощью браузера на своем устройстве по выбору и выбирает предметы (например, товары и/или услуги) для покупки. Как часть процесса онлайн-заказа, держатель 105 карты оформляет получение и заканчивает транзакцию покупки, предоставляя учетные данные для оплаты торгово-сервисному предприятию. Учетные данные для оплаты могут включать в себя, по меньшей мере, первичный идентификатор счета (PAN), представляющий счет, который должен быть использован в качестве источника финансовых средств в транзакции, дату истечения срока действия, ассоциированную с PAN, и информацию об адресе (для выставления счетов) держателя карты. PAN и другая информация предоставляется в подключаемую программу сервера торгово-сервисного предприятия (MPI) 110 у торгово-сервисного предприятия, где MPI является программным модулем, исполняемым от имени торгово-сервисного предприятия. MPI 110 функционирует, чтобы определять, является ли доступной аутентификация оплаты для PAN, принятого от держателя карты. MPI форматирует и отправляет сообщение запроса подтверждения регистрации (VEReq), включающее в себя PAN, серверу каталогов (DS) 115, где DS является компьютерным сервером, который может определять, находится ли PAN в диапазоне множества PAN, зарегистрированных в службе аутентификации, предоставляемой системой 100. DS может содержать компьютер, имеющий, по меньшей мере, один процессор, память, чтобы хранить программные инструкции и данные, и интерфейс связи для взаимодействия с другими устройствами.

При приеме VEReq DS 115 запрашивает устройство сервера управления доступом (ACS) 120, где адрес ACS указывается в VEReq. Адрес ACS может быть указан с помощью URL (унифицированного указателя ресурса) веб-адреса для ACS. Указанный ACS может быть эмитентом счета, представленного посредством PAN. В некоторых вариантах осуществления ACS может действовать от имени эмитента PAN, и точно определенный URL указывает на веб-адрес, отличный от веб-адреса эмитента. ACS 120 может отвечать на запрос, предоставляя указание того, доступна ли аутентификация для PAN, включенного в VEReq. Если торгово-сервисное предприятие является участвующим эквайером, и торгово-сервисное предприятие является действующим торгово-сервисным предприятием, тогда ACS 120 может отвечать с помощью ответного сообщения подтверждения регистрации (VERes), которое указывает, что аутентификация является доступной для PAN, включенного в сообщение VEReq. ACS 120 использует PAN из VEReq, чтобы определять, зарегистрирован ли держатель карты в службе аутентификации.

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

В некоторых аспектах VERes может включать в себя флаг, что аутентификация является доступной для PAN (например, поле доступной аутентификации PAN может быть установлено в "Y", указывая, что аутентификация является доступной). Наоборот, ACS 120 может отвечать с помощью VERes, которое указывает, что аутентификация не является доступной для PAN (например, BIN эквайера и/или PAN не зарегистрированы, ACS не реагирует на запрос, и т.д.). В некоторых аспектах VERes может включать в себя флаг, что аутентификация не является доступной для PAN (например, поле доступной аутентификации PAN может быть установлено в "N", указывая, что аутентификация не является доступной, или "U", указывая, что аутентификация является недействительной). В случае, когда VERes включает в себя флаг, значение в его поле или другой механизм, чтобы указывать, что аутентификация не является доступной для PAN, процесс аутентификации, предоставляемый системой 100, может быть завершен или прекращен.

ACS 120 дополнительно отправляет VERes, включающее в себя указание того, является ли аутентификация доступной, в DS 115. DS 115 будет затем пересылать VERes в MPI 110. Это может заключаться в участии DS в аутентификации транзакции, но процесс аутентификации далек от завершения. При приеме VERes MPI 110 считывает ответ, чтобы увидеть, доступна ли аутентификация для PAN транзакции. Если аутентификация является доступной, тогда MPI 110 отправляет сообщение, включающее в себя сообщение запроса аутентификации плательщика (PAReq), в ACS 120 через браузер держателя карты с помощью URL ACS, включенного в VERes. Сообщение PAReq запрашивает ACS эмитента, чтобы аутентифицировать его держателя карты. PAReq может включать в себя держателя карты, торгово-сервисное предприятие и характерную для транзакции информацию. Информация о держателе карты может включать в себя секретную информацию, известную только держателю карты и эмитенту. Отметим, что сообщение PAReq не используется совместно с торгово-сервисным предприятием (или MPI).

ACS 120 принимает PAReq и может переходить к подтверждению достоверности принятого сообщения, чтобы гарантировать, что оно правильно отформатировано и включает в себя необходимую информацию, включающую в себя, например, цифровые сертификаты и правильный флаг доступной аутентификации PAN (например, "Y"). ACS 120 может дополнительно определять, предоставлять ли аутентификацию держателя карты. ACS 120 может предоставлять указание такого определения, предоставляя состояние для транзакции. Значения для состояния могут включать в себя, в соответствии с 3-D Secure™, "Y", означающее, что клиент полностью аутентифицирован, "N", означающее, что клиент не прошел или отменил аутентификацию (т.е., транзакция запрещена), "U", означающее, что аутентификация может не быть завершена (например, технические проблемы, такие как обрывы связи, тайм-ауты и т.д.), и "A", которое предоставляет доказательство, что была попытка аутентификации.

Сообщение отправляется от ACS 120 к MPI 110, которое включает в себя состояние транзакции, которое определено посредством ACS 120. Сообщение может содержать ответное сообщение аутентификации плательщика, PARes. В случае, когда состояние транзакции определяется как "Y", тогда PARes будет включать в себя маркер аутентификации, AAV, который отправляется в MPI 110. PARes может быть цифровым образом подписан, чтобы предлагать уровень безопасности относительно подлинности самого сообщения. PARes принимается в MPI 110 через браузер держателя карты. При приеме PARes, MPI 110 может функционировать, чтобы признавать достоверной сигнатуру PARes и определять, авторизовать ли транзакцию, на основе, по меньшей мере, частично, значений, содержащих VERes.

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

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

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

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

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

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

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

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

В некоторых вариантах осуществления отмечается, что приложение 205 выполняет запрос аутентификации с помощью единственного API-вызова серверу 210 предприятия. Наоборот, сервер предприятия может предоставлять ответ приложению 205 с помощью единственного API-ответа. Таким образом, значение аутентификации может быть получено в эффективном процессе посредством запроса и приема значения или маркера аутентификации с помощью единственного API-вызова из приложения. В некоторых аспектах это контрастирует с некоторыми вариантами осуществления процессов, раскрытых со ссылкой, например, на фиг. 1, которые затрагивают множество различных сущностей-объектов, которые обязательно обмениваются информацией друг с другом в конкретной последовательности(ях) во время обмена специальными сообщениями, соблюдающими специальные форматы сообщений и требования сеанса связи, по каждому конкретному протоколу безопасности.

Обращаясь к процессу 300, изображенному на фиг. 3, увидим, что программное приложение 205 выполняет API-вызов серверу 210 предприятия на этапе 305. С точки зрения сервера 210 предприятия, API-вызов, запрашивающий значение аутентификации, принимается сервером предприятия на этапе 305. В некоторых случаях API-вызов может содержать SOAP (простой протокол доступа к объектам) сообщение, хотя другие протоколы передачи данных могут быть использованы без потери общности.

На этапе 310 сервер 310 предприятия может определять, включает ли в себя запрос значения аутентификации указание о том, что запрос содержит первый тип транзакции. Первый тип транзакции может быть указан посредством значения, флага, поля данных или другого механизма, включенного в или ассоциированного с принятым API-вызовом. В одном варианте осуществления API-вызов может содержать сообщение конкретного формата, которое включает в себя параметр в поле данных сообщения, где конкретное значение для этого параметра указывает, что API-вызов должен быть обработан в соответствии с последующими этапами 315 и 320 процесса 300. В одном варианте осуществления указание о том, что запрос содержит первый тип транзакции, предоставляется посредством самого API-вызова. Т.е., вариант осуществления системы или устройства, реализующего процесс 300, может логически определять, что, после того как сервер предприятия принимает API-вызов, запрашивающий значение аутентификации, как противоположность неприему API-вызова или приему некоторого другого типа сообщения или запроса, затем API-вызов может быть дополнительно обработан в соответствии с процессом 300.

В некоторых вариантах осуществления сервер 215 безопасности, изображенный на фиг. 2, может включать в себя ACS или т.п., когда сервер 210 предприятия размещается перед сервером со средствами защиты. В случае, когда сообщение, принимаемое сервером 210 предприятия, является сообщением безопасности, соответствующим протоколу безопасности (например, SPA, 3DS и другим последовательностям аутентификации, включающим в себя те, которые конкретно не перечисляются в данном документе), тогда сообщение может быть маршрутизировано серверу 215 безопасности (т.е., ACS) и обработано согласно применимому протоколу безопасности. В этом случае сообщение, принятое сервером 210 предприятия, будет принято от одной из сущностей-объектов, указанных посредством протокола безопасности, такой как, например, торгово-сервисное предприятие, MPI и держатель карты (например, включаемое окно браузера и т.д.), в конкретном формате и включающее в себя данные, указанные конкретным протоколом аутентификации. В некоторых вариантах осуществления сервер 210 предприятия может маршрутизировать некоторое сообщение(я) конкретного типа в ACS для обработки посредством ACS в соответствии с одним или более протоколами безопасности аутентификации.

Возвращаясь к фиг. 3, процесс 300 переходит к этапу 315, когда, в ответ на определение, что запрос значения аутентификации включает в себя указание первого типа транзакции, сервер предприятия формирует значение аутентификации для транзакции, ассоциированной с API-вызовом, принятым на этапе 305. В некоторых вариантах осуществления формирование значения или маркера аутентификации может включать в себя сервер 210 предприятия, преобразующий API-вызов, принятый от программного приложения, в сообщение запроса подтверждения (например, VEReq) или другое сообщение(я) в зависимости от используемого протокола аутентификации. Запрос подтверждения или другой тип сообщения может быть передан серверной системе обработки протокола безопасности (например, системе безопасности аутентификации, включающей в себя ACS). Сервер 210 предприятия может принимать, в ответ на сообщение запроса подтверждения, сообщение ответа подтверждения (например, VERes) или другое сообщение(я) в зависимости от используемого протокола аутентификации. В некоторых случаях запрос подтверждения или другой тип сообщения и ответ подтверждения или другой тип сообщения могут быть переданы в течение одного и того же сеанса связи (например, HTTP). При приеме ответа подтверждения или другого типа сообщения сервер 210 предприятия может формировать или иначе формулировать сообщение запроса аутентификации плательщика (например, PAReq) или другое сообщение(я) в зависимости от используемого протокола аутентификации, которое впоследствии передается серверной системе обработки протокола аутентификации (например, ACS эмитента) для обработки. Сервер 210 предприятия может принимать, в ответ на сообщение запроса аутентификации плательщика, ответ аутентификации плательщика (например, PARes) или другое сообщение(я) в зависимости от используемого протокола аутентификации. В некоторых случаях запрос аутентификации плательщика или другой тип сообщения и ответ аутентификации плательщика или другой тип сообщения могут быть переданы в течение одного и того же сеанса связи (например, HTTP). Значение или маркер аутентификации может быть сформировано на основе ответа аутентификации плательщика или другого типа сообщения.

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

В некоторых аспектах API-вызов и API-ответ в ответ на него являются внутренними по отношению к конкретной фирме, системе, организации или другой вычислительной среде. В некоторых отношениях, контекст, такой как этот, где данные, обмениваемые через API-вызовы и API-ответ, не раскрываются внешне, может, по меньшей мере, по этой причине, выходить за пределы области действия одного или более протоколов безопасности. В некоторых вариантах осуществления один способ приема результатов аутентификации существует через определенные способы и сообщения протокола аутентификации, которые предназначаются, чтобы предоставлять точные результаты транзакции, так что транзакция может быть позднее повторно вызвана с целью, например, разрешения спора о возврате оплаты. Предоставляя точный непрерывный учет транзакций, платежные сети могут обеспечивать определение того, где может лежать ответственность за мошенничество в случае мошенничества. Непрерывная запись транзакции совершается в некоторых вариантах осуществления посредством ACS эмитента (на фиг. 2 ACS 215), отправляющего особые сообщения, называемые запросом аутентификации плательщика транзакции (PATrans Request), или другие сообщения по другому протоколу аутентификации серверу истории аутентификации (на фиг. 2 ACS 220). Данные, содержащиеся в этом сообщении, могут быть сохранены и синхронизированы с банком данных (например, на фиг. 2, ACS 225). В некоторых аспектах, по меньшей мере, часть набора данных, сохраненного в банке данных, содержит первоначальную транзакцию от торгово-сервисного предприятия, которая принята от сервера каталогов (DS) или другой сущности-объекта в зависимости от контекста или сценария использования. После того как действия аутентификации, задокументированные в PATrans Request (или другом подобном сообщении), и первоначальные данные транзакции объединяются и анализируются, полезные данные, включающие аналитическую информацию в полный запрос аутентификации, могут быть определены.

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

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

Название торгово-сервисного предприятия Код страны торгово-сервисного предприятия URL торгово-сервисного предприятия ID торгово-сервисного предприятия BIN эквайера Дата покупки Идентификатор транзакции Объем покупки Валюта покупки Экспонента валюты Данные о регулярном платеже Данные о платеже в рассрочку PAN Дата истечения срока действия карты Идентификатор счета Время транзакции Состояние транзакции Значения аутентификации Указатель транзакции IP-адрес клиента Использованный способ аутентификации

Таблица 1

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

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

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

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

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

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

Обращаясь к фиг. 2, увидим, что в некоторых вариантах осуществления сервер 215 безопасности может пересылать запись или представление значения или маркера аутентификации, сформированное сервером 210 предприятия, серверу 220 истории. Сервер 220 истории может дополнительно отправлять детали транзакции в базу данных 225. Детали транзакции могут быть использованы в дальнейшей обработке, формировании отчетности и аналитике.

Обращаясь к фиг. 4, увидим, что показано иллюстративное изображение системы 400 согласно некоторым вариантам осуществления в данном документе. В некоторых отношениях, фиг. 4 раскрывает логические аспекты платформы аутентификации, включающей в себя сервер истории, который может записывать и регистрировать непрерывную последовательность транзакции каждого запроса аутентификации процесса аутентификации (например, включающую в себя 3-D Secure™, но не ограничиваясь им). Соответственно, фактические системы могут включать в себя меньше, больше или другие устройства и сущности-объекты в конфигурациях, явно не показанных на фиг. 4, без какой-либо потери общности или применимости. В некоторых аспектах система 400 может включать в себя платформу, которая может эффективно использовать некоторые аспекты традиционной системы аутентификации, такой как система, раскрытая на фиг. 1 (хотя не ограничиваясь ею), также как некоторые аспекты новой системы, раскрытой на фиг. 2. В некоторых аспектах система 400 и процессы, реализуемые посредством нее, могут работать, чтобы обрабатывать миллионы транзакций и запросов аутентификации, ежедневно. Такие рамки и масштаб обработки, включающие в себя каждый запрос аутентификации, то, был ли запрос аутентификации завершен, и первоначальная транзакция покупки также представляется в ассоциированной авторизации покупки, или был ли запрос аутентификации завершен, делаются возможными посредством системы 400. Соответственно, система 400 обязательно содержит компьютерные устройства, системы и сети, которые усовершенствуются, как противоположность ограничению реализацией известного процесса.

В некоторых аспектах система 400 включает в себя сервер 410 приложений, который может принимать сообщения запроса аутентификации плательщика (PAReq) или другое сообщение(я) в зависимости от используемого протокола аутентификации и ответные сообщения аутентификации плательщика (PARes) или другое сообщение(я) в зависимости от используемого протокола аутентификации, ассоциированные с транзакцией, от одного или более источников. В соответствии с некоторыми системами аутентификации и процессами PAReq или другие сообщения и PARes или другие сообщения могут быть приняты от ACS 405, внешнего по отношению к среде предприятия. В некоторых аспектах PAReq-сообщения и PARes-сообщения могут быть приняты от ACS эмитента системы, сконфигурированной, по меньшей мере, частично, аналогично системе 100 на фиг. 1. PAReq и PARes транзакции или другие данные, принятые от внешнего ACS, могут быть запрошены от поставщика(ов) внешнего ACS. Данные PAReq и PARes, принятые сервером 410, могут быть отправлены серверу 425 базы данных. Сервер 425, также называемый в данном документе "сервером истории", может работать, чтобы отслеживать, хранить, форматировать, кодировать и/или шифровать принятые данные для вставки PAReq и PARes или других аутентификационных данных в таблицу базы данных, систему, другие структуры данных и службу хранения данных.

В некоторых аспектах сервер 410 может принимать данные PAReq и PARes, ассоциированные с транзакциями, от одного или более серверов, внутренних по отношению к среде предприятия, таких как, например, от серверов 415 и 420. Серверы 415 и 420 могут быть одним или более устройствами или системами, функционирующими как, по меньшей мере, частично, ACS. В некоторых вариантах осуществления ACS 415 является внутренним ACS, который может быть внутренним по отношению к среде предприятия, такой как, например, сервер 215 безопасности (ACS) на фиг. 2. Как изложено ранее относительно фиг. 2, система 200, включающая в себя сервер 210 предприятия и другие компоненты в ней, может работать внутренне по отношению к среде предприятия, при этом предприятие 200 формирует значение аутентификации в ответ на API-вызов из приложения или службы 205. В соответствии с формированием значения аутентификации ACS 415 может иметь данные PAReq и PARes транзакции или другое сообщение(я) в зависимости от используемого протокола аутентификации.

В некоторых вариантах осуществления сервер 420 может включать в себя ACS онлайновой службы аутентификации, предоставляемый предприятием, тогда как в некоторых вариантах осуществления сервер 420 может включать в себя другие типы ACS-серверов, которые могут, по меньшей мере, при случае, связываться с приложениями, устройствами и/или службами, внешними по отношению к среде предприятия. Сервер 420 может иметь данные PAReq и PARes транзакции или другие аутентификационные данные, ассоциированные с некоторыми онлайновыми и другими типами транзакций. PAReq и PARes или другие аутентификационные данные от серверов 415 и 420 могут быть переданы серверу 410 приложений затем серверу 425 истории.

Другие аспекты данных процесса аутентификации, а именно, сообщения запроса подтверждения регистрации (VEReq) и ответные сообщения подтверждения регистрации (VERes) или другое сообщение(я) в зависимости от используемого протокола аутентификации, могут быть приняты от одного или более серверов 415 (например, внутреннего ACS-сервера) и сервера каталогов (DS) 440. В некоторых аспектах сервер 415 является внутренним ACS, который может обеспечивать внутреннее формирование значения аутентификации для транзакции, как обсуждалось относительно фиг. 2. По существу, данные VEReq и VERes, соответствующие ассоциированной транзакции(ям), сохраняются посредством внутреннего ACS 415. Это VEReq и VERes или другое сообщение(я) могут быть переданы серверу 440 приложений, по меньшей мере, в целях хранения.

В некоторых случаях VEReq и VERes или другое сообщение(я) могут быть сформированы с помощью и во взаимодействии с внешними устройствами, приложениями и службами, такими как система 100 на фиг. 1. Соответственно, VEReq и VERes или другие данные, ассоциированные с некоторыми транзакциями, могут быть приняты через сервер 440 от интерфейса 435 MPI торгово-сервисного предприятия и сохранены на DS 440.

В некоторых аспектах, принимаются ли данные VEReq и VERes от внутреннего ACS или DS 440, сервер 440 может функционировать, чтобы отслеживать, хранить, форматировать, кодировать и/или шифровать принятые данные, чтобы вставлять VEReq и VERes или другие данные в таблицу базы данных, систему и другие структуры данных. В некоторых вариантах осуществления указание источника или типа устройства, которое предоставляет VEReq и VERes или другие данные, включается в данные VEReq и VERes или другое сообщение(я) в зависимости от используемого протокола аутентификации. Этот указатель источника может предоставлять понимание того, был ли запрос маркера аутентификации, ассоциированный с конкретной транзакцией, сформирован посредством внутреннего процесса (например, фиг. 2) или внешнего процесса, устройства, службы или системы.

Данные как на сервере 425 истории (т.е., PAReq и PARes или другие данные), так и DS-сервере 445 (т.е., VEReq и VERes или другие данные) могут быть синхронизированы и иначе обработаны, объединены или агрегированы для включения в банк данных, хранилище, устройство или систему 430. В некоторых вариантах осуществления банк 430 данных может содержать систему управления базой данных или экземпляр узла системы управления базой данных. В некоторых аспектах объединенные PAReq/PARes или другие данные и VEReq/VERes или другие данные могут содержать единственную информационную запись или их представление в виде структуры данных. Объединенная информационная запись может предоставлять, в дополнение к другим деталям транзакции, непрерывный вид последовательности транзакции, включающий в себя то, была ли аутентификация запрошена торгово-сервисным предприятием, была ли аутентификация предоставлена эмитентом, была ли аутентификация одобрена или отвергнута, и была ли запрошена авторизация оплаты для транзакции, и была ли она одобрена или отвергнута.

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

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

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

Обращаясь к фиг. 5, увидим, что некоторые варианты осуществления относятся к данным, собранным от внутренних систем аутентификации (ACS 515 и системы 520 аутентификации) и внешних систем аутентификации (например, внешней системы 502 аутентификации и внешнего ACS 504). Данные от внутренних (515, 520) и внешних (502, 504) систем аутентификации передаются через сервер 510 истории аутентификации. Сервер 510 истории аутентификации может работать, чтобы передавать аутентификационные данные, принятые как из внутренних, так и внешних источников, в банк 530 данных. В некоторых аспектах сервер каталогов (DS) 540 аутентификации предусматривается в платформе 500 аутентификации на фиг. 5. DS 540 может взаимодействовать с торгово-сервисным предприятием или MPI 535 торгово-сервисного предприятия и внутренним ACS и внутренней системой аутентификации, чтобы обеспечивать внутреннее формирование значения аутентификации для транзакции, как обсуждалось относительно фиг. 2 и 4. По существу, VEReq и VERes или другие данные сообщений, соответствующие ассоциированной транзакции(ям), могут быть сохранены посредством внутреннего ACS 515. Это VEReq и VERes или другое сообщение(я) могут быть переданы серверу 540 приложений, по меньшей мере, в целях хранения.

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

В некоторых аспектах сервер истории аутентификации в данном документе собирает данные из различных источников (например, 515, 520) на платформе аутентификации и от систем аутентификации (например, 502, 504), которые предоставляют службы "от имени", такие как, например, биометрическая платформа или система генерации и подтверждения одноразового пароля. Транзакционные (и другие) данные могут также быть приняты сервером истории аутентификации (например, 510) от DS-системы для того, чтобы предоставлять полный непрерывный вид транзакции. Эти данные, из множества источников, как внутренних, так и внешних по отношению к организации, сети или предприятию, могут быть переданы в банк данных (например, 530), где они могут потребляться для внутренней и внешней бизнес-отчетности и анализа, также как, например, потребляться системами 545 оценки риска, чтобы обеспечивать оценку мошенничества транзакции.

Фиг. 6 - это блок-схема последовательности операций процесса, в соответствии с некоторыми вариантами осуществления в данном документе. Обращаясь к процессу 600, увидим, что сообщение запроса аутентификации плательщика (PAReq) и сообщение ответа аутентификации плательщика (PARes) (или другие сообщения и данные в зависимости от конкретного используемого протокола аутентификации), ассоциированные с транзакцией, принимаются, по меньшей мере, от одного сервера управления доступом (ACS), внешнего по отношению к конкретной среде предприятия, на этапе 605. Как иллюстрировано на фиг. 4, внешний ACS может быть ACS эмитента, ассоциированным с и предоставленным посредством или от имени эмитента, участвующего в процессе или протоколе аутентификации.

Процесс 600 дополнительно включает в себя прием, на этапе 610, по меньшей мере, от одного сервера управления доступом (ACS), внутреннего по отношению к среде предприятия, сообщения запроса подтверждения регистрации (VEReq) и сообщения ответа подтверждения регистрации (VERes) (или других сообщений и данных в зависимости от конкретного используемого протокола аутентификации), ассоциированных с транзакцией. В соответствии с одним вариантом осуществления в данном документе данные VEReq и VERes могут быть приняты от компьютера или другого устройства, включающего в себя машинный процессор. Внутренний ACS может включать в себя ACS, предусмотренный, как раскрыто выше в данном документе, чтобы формировать маркер аутентификации, внутренний по отношению к среде предприятия (например, фиг. 2).

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

На этапе 615, PAReq-сообщение и PARes-сообщение (или другие сообщения и данные в зависимости от конкретного используемого протокола аутентификации), ассоциированные с транзакцией, объединяются с VEReq-сообщением и VERes-сообщением (или другими сообщениями и данными в зависимости от конкретного используемого протокола аутентификации), ассоциированными с транзакцией, в единую информационную запись. В некоторых аспектах определение может быть выполнено, чтобы определять, соответствуют ли конкретные VEReq/VERes или другие сообщения некоторым другим конкретным PAReq/PARes или другим сообщениям, в попытке гарантировать, что данные транзакции точно отслеживаются и регистрируются, и целостность данных поддерживается.

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

Информационная запись, сохраненная во время этапа 620, может включать в себя все аспекты транзакции, включающие в себя, например, VEReq/VERes или другие сообщения, PAReq/PARes или другие сообщения, детали авторизации оплаты (например, обслуживающие агенты, сети, институты эмитента и эквайера, подробные данные отдельной позиции транзакции оплаты и т.д.) и другую информацию. Данные в сохраненной записи могут быть достаточно детализированными и исчерпывающими, чтобы предоставлять непрерывный вид транзакции, включающий в себя сущности-объекты, участвующие в транзакции в каждой точке обработки контакта.

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

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

Фиг. 7 является блок-схемой общего вида системы или устройства 700 согласно некоторым вариантам осуществления. Система 700 может быть, например, ассоциирована с любым из устройств, описанных в данном документе, включающих в себя, например, сервер предприятия, сервер истории и аналогичную функциональность в соответствии с процессами, раскрытыми в данном документе. Система 700 содержит процессор 705, такой как один или более коммерчески доступных центральных процессоров (CPU) в форме однокристальных микропроцессоров или многоядерного процессора, соединенный с устройством 715 связи, сконфигурированным, чтобы связываться через сеть связи (не показана на фиг. 7) с другим устройством или системой. В отдельном случае система 700 содержит сервер (например, поддерживающий функции и службы, предоставляемые сервером предприятия, сервером истории и т.д.), устройство 715 связи может предоставлять механизм, чтобы система 700 взаимодействовала с другим устройством, системой или службой (например, экземпляром сервера 215 безопасности). Система 700 может также включать в себя локальную память 710, такую как модули RAM-памяти. Система дополнительно включает в себя устройство 720 ввода (например, сенсорный экран, мышь и/или клавиатуру, чтобы вводить контент) и устройство 725 вывода (например, сенсорный экран, компьютерный монитор для отображения, LCD-дисплей).

Процессор 605 связывается с устройством 730 хранения. Устройство 730 хранения может содержать любое подходящее устройство хранения информации, включающее в себя комбинации магнитных устройств хранения (например, накопитель на жестком диске), оптических устройств хранения, твердотельных устройств и/или полупроводниковых запоминающих устройств. В некоторых вариантах осуществления устройство 630 хранения может содержать систему базы данных.

Устройство 730 хранения может хранить программный код или инструкции 735, которые могут предоставлять исполняемые компьютером инструкции для отслеживания различных аспектов транзакции по формированию значения аутентификации, определения полной записи о транзакции и сохранения полной записи в целях дальнейшей обработки и отчетности, в соответствии с процессами в данном документе. Процессор 705 может выполнять инструкции из программных инструкций 735, чтобы, тем самым, работать в соответствии с любым из вариантов осуществления, описанных в данном документе. Программный код 735 может быть сохранен в сжатом, нескомпилированном и/или зашифрованном формате. Программный код 735 может, кроме того, включать в себя другие программные элементы, такие как операционная система, система управления базой данных и/или драйверы устройств, используемые процессором 705 для взаимодействия, например, с периферийными устройствами. Устройство 730 хранения может также включать в себя данные 740, такие как записи базы данных или поисковые таблицы, включающие в себя, например, записи о торгово-сервисного предприятиях, эмитентах и эквайерах, участвующих в конкретной программе или службе аутентификации, и адреса устройств, используемых этими сущностями-объектами, чтобы реализовывать службу. Данные 740 могут быть использованы системой 700, в некоторых аспектах, в выполнении одного или более процессов в данном документе, включающих в себя отдельные процессы, отдельные этапы этих процессов и сочетания отдельных процессов и отдельных этапов процессов.

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

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

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

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

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

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

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

сохраняют упомянутую единую информационную запись в совместно используемом устройстве хранения данных; и

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

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

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

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

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

6. Способ по п. 5, в котором второе сообщение регистрации включает в себя указание типа ACS, от которого второе сообщение регистрации принимается.

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

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

устройство, содержащее:

процессор; и

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

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

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

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

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

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

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

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

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

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

13. Система по п. 12, в которой второе сообщение регистрации включает в себя указание типа ACS, от которого второе сообщение регистрации принимается.

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

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

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

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

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

сохраняют упомянутую единую информационную запись в устройстве хранения данных; и

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

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

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

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

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

20. Носитель по п. 15, в котором второе сообщение регистрации включает в себя указание типа ACS, от которого второе сообщение регистрации принимается.

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