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

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

[0001] Эта заявка является заявкой PCT и имеет приоритет по заявке на патент США № 61/299912, поданной 29 января 2010 года, озаглавленной "AUTHENTICATION FRAMEWORK EXTENSION TO VERIFY IDENTIFICATION INFORMATION", содержимое которой включено в настоящий документ посредством ссылки в полном объеме для всех целей.

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

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

[0003] Протокол и структура аутентификации 3-D Secure является одной такой системой для повышения безопасности транзакций, проводимых по сети. В типичной транзакции, использующей протокол 3-D Secure, потребитель может желать купить товар или услугу у продавца. Продавец, используя подключаемый модуль продавца, который является компьютерной программой, запущенной в системе обработки транзакций продавца, идентифицирует эмитент транзакционного счета продавца. Типично, продавец предоставит номер счета, ассоциированный с транзакционным счетом, и подключаемый модуль продавца запросит сервер каталогов, который может определить эмитент, ассоциированный с номером счета. Эмитентом типично является банк, где потребитель обслуживает счет, хотя возможны другие типы эмитентов.

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

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

[0006] Существующие протокол и структура 3-D Secure предоставляют безопасную и надежную для аутентификации держателей транзакционных счетов, когда они привлечены к другим закупочным транзакциям. Однако, транзакционные счета часто используются для других типов транзакций, которыми являются не прямыми закупочными транзакциями. К тому же, эти типы транзакций могут иметь требования аутентификации, которые отличаются от просто аутентификации потребителя, который привлечен к транзакции. Было бы желательно улучшить и расширить существующие протокол и структуру 3-D Secure для расширения способностей за пределы простой аутентификации по паролю держателя транзакционного счета.

[0007] Варианты осуществления этого раскрытия рассматривают эти и другие проблемы индивидуально и совместно.

Сущность изобретения

[0008] Раскрыты системы и способы для аутентификации сторон, вовлеченных в транзакцию. Некоторые варианты осуществления данного раскрытия направлены на системы и способы аутентификации различных идентификационных атрибутов участника при транзакции. Атрибуты могут включать в себя элементы, такие как имя участника, адрес, номер социального страхования, дату рождения или любые другие идентифицирующие атрибуты. В некоторых вариантах осуществления, все участники при транзакции могут иметь аутентифицированную идентификационную информацию. Протокол и структура 3-D Secure расширяются и улучшаются для предоставления способности аутентифицировать идентификационные сведения участников в транзакциях.

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

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

[0011] Эти и другие варианты осуществления данного изобретения описаны подробно ниже.

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

[0012] На Фиг. 1 изображена примерная транзакция денежного перевода.

[0013] На Фиг. 2 примерно изображен примерный снимок экрана транзакции перевода.

[0014] На Фиг. 3 изображена аутентификация адресата.

[0015] На Фиг. 4 изображена аутентификация адресата используя закодированные значения.

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

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

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

[0019] На Фиг. 8 изображена высокоуровневая схема компьютера.

Подробное описание

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

[0021] Использование кредитных или дебетовых транзакционных счетов, которые могут быть просто названы как счета для оплаты товаров или услуг, предоставленных продавцом, является общепринятым. Типично, держатель счета, покупающий товары или услуги, предоставит идентификатор счета, такой как пластиковую кредитную карту, смарткарту или даже сам номер счета, продавцу. Продавец запрашивает авторизацию у эмитента счета для определения, доступны ли достаточные денежные средства и или кредитные средства, чтобы сделать покупку. Если достаточные денежные средства доступны, транзакция авторизовывается, и покупка завершается. Периодически, типично в конце рабочего дня, продавец предъявляет все авторизованные транзакции в банк-эквайер для расчета. Банк-эквайер затем запрашивает денежные средства у эмитента авторизованных транзакций. Эмитент переводит денежные средства в банк-эквайер, и те денежные средства перечисляются на счет продавца.

[0022] Для того чтобы снизить вероятность мошеннических транзакций, были разработаны структуры, такие как 3-D Secure, также называемые как Верифицированные посредством Visa (VbV). В протоколе 3-D Secure, до запроса авторизации транзакции продавцом, устанавливается связь между покупателем и эмитентом счета покупателя. Эмитент может запросить аутентификацию покупателя, например, посредством запроса пароля. Если пароль правильный, покупатель аутентифицируется как авторизованный пользователь, и могут проводиться авторизация и процесс расчета.

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

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

[0025] Одной такой услугой прямого платежа со счета на счет, которая предполагалась, является услуга денежного перевода (MT). Услуга MT может обеспечить возможность отправителю отправлять деньги адресату, используя свою кредитную или дебетовую карту. Отправитель может войти на web-сайт MT или посетить физическое местоположение, которое имеет киоск для выполнения денежных переводов. Отправитель может предоставлять свои сведения о счете, такие как номер кредитной карты, посредством набора данных на web-сайте или проведения своей карты. Отправитель может затем ввести номер счета предназначенного адресата. Денежные средства могут быть затем переведены напрямую со счета отправителя на счет адресата, минуя необходимость в банке-эквайере.

[0026] Такая услуга была бы огромным удобством для перевода денег между физическими лицами напрямую используя их соответственные счета. Однако существуют дополнительные беспокойства, возникающие из безопасности и перспективы эмитента счета. Например, если перевод только требует номер счета отправителя и номер счета адресата, нет способа для аутентификации имени человека, который принимает денежные средства. Во многих странах, для целей безопасности, требуется, чтобы было известно имя и потенциально другая идентифицирующая информация физического лица, принимающего денежные средства. Это имя нуждается в аутентификации эмитентом счета адресата. Например, в США, определенные физические лица могут быть в списке особо обозначенных граждан (SDN). Гражданам США запрещено делать какой-либо тип бизнеса, в том числе перевод денег, любым, кто находится в списке SDN. Было бы необходимо для услуги MT быть способной аутентифицировать имя адресата с помощью эмитента счета адресата.

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

[0028] Дополнительно, аутентификация или идентификационные сведения не ограничены только адресатами. Информация отправителя может быть аутентифицирована равным образом. К тому же, типы транзакций не ограничены транзакциями денежных переводов. Предполагалась любая транзакция, в которой идентификационные сведения одного или более участников в транзакции нуждаются в аутентификации.

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

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

[0031] Варианты осуществления данного раскрытия расширяют протокол и структуру аутентификации 3-D Secure, чтобы включать в себя аутентификационные и идентификационные сведения. Текущая структура, как описано выше, используется для аутентификации потребителя как части платежной транзакции. Эмитент счета потребителя идентифицирован, и потребитель приглашается эмитентом для ввода пароля. Если пароль совпадает с тем, который сохранил эмитент, то транзакции разрешено продолжиться. Структура может быть расширена для обеспечения возможности верификации других сведений об участниках в транзакции. Например, идентификационная информация адресата может быть аутентифицирована, даже если денежные средства не снимаются со счета адресата. К тому же, для дополнительной безопасности, идентификационная информация отправителя может быть также верифицирована.

[0032] ПРИМЕРНЫЕ СИСТЕМЫ

[0033] На Фиг. 1 изображена примерная транзакция денежного перевода. Как упомянуто выше, транзакция денежного перевода является одним типом транзакции, которая может извлечь пользу из вариантов осуществления данного раскрытия. Однако следует понимать, что варианты осуществления данного раскрытия не ограничены транзакциями денежных переводов, и описание транзакций денежных переводов является для целей объяснения, а не ограничения.

[0034] Отправитель 102 может захотеть перевести денежные средства со своего счета на счет получателя 104. Отправитель и получатель могут быть также названы как участники в транзакции. Счет получателя может быть предоставлен эмитентом 110. Счет отправителя может быть также предоставлен эмитентом (не показан). Для целей простоты объяснения транзакция денежного перевода описана относительно получателя. Однако следует понимать, что аутентификация идентификационных сведений, выполненная по отношению к получателю, может быть также выполнена по отношению к отправителю.

[0035] Для того чтобы привлечься к денежному переводу, отправитель 102 осуществляет доступ к серверу 106 денежных переводов. Сервер денежных переводов может включать в себя считываемый компьютером носитель 106(a), который содержит компьютерный код, который при исполнении сервером 106 денежных переводов предписывает серверу исполнять этапы, описанные в настоящем документе. Способ доступа может быть в любом подходящей форме. Например, отправитель 102 может осуществлять доступ к web-сайту, предоставленному сервером 106 денежных переводов. В качестве альтернативы, отправитель 102 может посетить физическое местоположение, содержащее киоск, оперативно подключенный к серверу 106 денежных переводов. Отправитель 102 может обеспечивать сервер 106 денежных переводов сведениями о транзакции, такими как счет для перевода с и на, и сумма. К тому же, идентифицирующая информация для адресата и возможно отправителя также предоставлена. Примерный экран ввода показан на Фиг. 2.

[0036] После приема информации о транзакции от отправителя 102 сервер 106 денежных переводов может отправить запрос 130 регистрации верификации (VEReq) на сервер 108 каталогов. Сервер 108 каталогов может также содержать считываемый компьютером носитель, который содержит компьютерный код, который при исполнении сервером 108 каталогов, предписывает серверу исполнять этапы, описанные в настоящем документе. На основе сведений о транзакции, в общем номер счета адресата, сервер 108 каталогов может определить эмитент счета адресата. Например, первые шесть цифр транзакционного счета типично определяют банк, который выдал счет. В некоторых случаях, сервер 108 каталогов сам по себе способен определять, что эмитент адресата не способен аутентифицировать идентификационную информацию. В таких случаях, сервер 108 каталогов просто посылает ответ 136 регистрации верификации (VEResp), который указывает, что эмитент не способен верифицировать идентификационную информацию адресата. Это не означает, что адресат является неаутентичным, а скорее эмитент не может или выбирает не реализовывать систему аутентификации.

[0037] В большинстве случаев, сервер 108 каталогов будет способен идентифицировать сервер 110 управления аутентификацией (ACS), который ассоциирован с эмитентом счета адресата. ACS 110 может быть также назван как сервер управления доступом или сервер управления авторизацией. ACS 110 может также содержать считываемый компьютером носитель, который содержит компьютерный код, который при исполнении посредством ACS 110 предписывает серверу исполнять этапы, описанные в настоящем документе. Сервер 108 каталогов пересылает VEReq 132 и ACS 110. Как изображено на Фиг. 1, ACS показан как интегрированный внутри системы счетов эмитента. Однако эта конфигурация является для целей объяснения, а не ограничения. В некоторых случаях, ACS эмитента может находиться вне систем эмитента. В других случаях, ACS могут быть предоставлены третьей стороной, которая предоставляет услуги ACS для множественных эмитентов. Следует понимать, что эмитенты, которые имеют реализованные варианты осуществления данного раскрытия, предоставят ACS 110, который выполнен с возможностью предоставления функциональности, описанной ниже.

[0038] После приема сообщения VEReq от сервера 108 каталогов, ACS 110 может затем определить способен ли быть аутентифицирован номер счета конкретного адресата. Этот этап не аутентифицирует адресата, а скорее определяет, что ACS способен аутентифицировать адресата. ACS 110 затем отправляет VEReq 134 на сервер 108 каталогов. Сервер 108 каталогов пересылает VEResp 136 на сервер 106 денежных переводов. Если адресат может быть аутентифицирован, VEResp будет включать в себя контактную информацию, такую как IP-адрес, для ACS 110, который может аутентифицировать адресата.

[0039] Сервер 106 денежных переводов затем анализирует VEResp 136 для определения, может ли быть аутентифицирован адресат. Если нет, сервер 106 денежных переводов может либо разрешить, либо запретить транзакцию на основе бизнес- или нормативных правил. Например, если существует требование, бизнеса или правовое, что адресат должен быть аутентифицирован до денежного перевода, то сервер 106 денежных переводов запретит транзакцию. Если аутентификация адресата является необязательной, то сервер 106 денежных переводов мог бы продолжить транзакцию.

[0040] Если VEResp 136 указывает, что адресат может быть аутентифицирован, сервер 106 денежных переводов может отправлять запрос 138 авторизации плательщика (PAReq) на ACS 110, который был идентифицирован в VEResp 136. Термин "запрос авторизации плательщика" не следует интерпретировать как подразумевающий запрос, ассоциированный с платежом. Скорее, PAReq является типом запроса, который задан в протоколе 3-D Secure. Варианты осуществления текущего раскрытия расширяют функциональность, предоставленную существующим протоколом 3-D Secure. PAReq 138 может включать в себя номер счета адресата и любое число идентифицирующих сведений об адресате. Некоторые примерные сведения показаны на Фиг. 2. В некоторых вариантах осуществления, PAReq 138 не будет включать в себя идентификационные сведения, а скорее закодированные версии идентификационных сведений. В еще одних вариантах осуществления, PAReq может не включать в себя идентификационные сведения, кроме номера счета адресата. Содержимое PAReq будет описано более подробно по отношению к Фиг. 3 и 4.

[0041] ACS 110 может затем извлекать информацию об адресате из базы данных 110(b), обслуживаемой эмитентом, посредством использования номера счета. Ввиду того, что эмитент является организацией, которая обслуживает счет, эмитент будет иметь идентификационные данные об адресате, так как эта информация могла бы потребоваться для первоначального создания счета. Предполагая, что эмитент правильно верифицировал информацию адресата после создания счета, данные адресата, хранящиеся в базе данных 110(b), должны быть аутентичными. Например, при создании счета эмитент может требовать представления учетных данных, таких как паспорт или водительская лицензия, чтобы гарантировать, что человек, создающий счет, предоставляет легитимную информацию.

[0042] ACS 110 может затем сравнить идентификационную информацию в PAReq с данными, извлеченными из базы данных 110(b). В некоторых вариантах осуществления, ACS будет просто делать определение да/нет в отношении того, был ли аутентифицирован адресат. В других вариантах осуществления, аутентификация может быть более гранулярной. Например, если ASC 110 способен аутентифицировать имя, но не дату рождения или номер социального страхования, ASC может указывать, что он способен только аутентифицировать части идентификационной информации адресата. Аналогично, если ACS 110 способен аутентифицировать фамилию адресата, но не основное имя, ACS 110 может указать, что он был только способен аутентифицировать часть имени. Дополнительные варианты осуществления будут описаны по отношению к Фиг. 3 и 4.

[0043] Как только ACS 110 сделал определение аутентификации, эта информация может быть возвращена серверу 106 денежных переводов и сообщении ответа 140 авторизации плательщика (PAResp). Снова, термин "ответ авторизации плательщика" не следует интерпретировать так, чтобы подразумевать, что платежная транзакция проводится. Скорее сообщение PAResp 140 является существующим сообщением в рамках протокола 3-D Secure, и варианты осуществления настоящего раскрытия модифицируют существующий протокол для предоставления функциональности, которая ранее не существовала.

[0044] Сервер 106 денежных переводов может принимать сообщение 140 PAResp и определять, должна ли быть продолжена транзакция. Так же, как и выше, сервер 106 денежных переводов может разрешить или запретить транзакцию на основе уровня аутентификации. Например, если ACS 110 просто возвращает значение да/нет для аутентификации, законы и правила могут требовать, чтобы транзакция была запрещена, если возвращено "нет". В качестве альтернативы, законы или правила могут указывать, что если возвращено "нет" для аутентификации от эмитента, транзакция может продолжаться, но оператор сервера 106 денежных переводов затем примет на себя ответственность за любые последствия разрешения неаутентифицированного адресата. Эта гибкость также доступна, если ACS отвечает c указателем, что только части идентификационной информации адресата могли бы быть аутентифицированы. Например, если ACS 110 способен аутентифицировать фамилию, а не основное имя, или был способен аутентифицировать имя, а не номер социального страхования, сервер 106 денежных переводов может затем принять решение либо разрешить, либо запретить транзакцию.

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

[0046] На Фиг. 2 примерно изображен примерный снимок экрана транзакции перевода. Отправитель может указать сумму 202, которую он хочет перевести. Отправитель может также указать идентификационную информацию 204 об отправителе. Как объяснено выше, эта информация может быть полезна при предотвращении перевода денежных средств неавторизованными отправителями. Информация 204 об отправителе может включать в себя информацию, такую как имя, номер счета, дата истечения срока действия счета, адрес, дата рождения и номер социального страхования. Как должно быть понятно, идентификационные сведения является просто примерами, и любая другая идентифицирующая информация могла бы быть использована равным образом. Также не существует требования, чтобы присутствовали все примерные порции информации. Информация 206 о получателе может быть аналогичной информации об отправителе с показанными некоторыми примерными порциями идентификационной информации. Снова, могло бы быть использовано больше, меньше или разные идентификационные элементы. К тому же, не существует требования, чтобы отправитель и получатель использовали одни и те же порции идентификационной информации. Например, отправитель может нуждаться в указании своего имени и даты рождения, в то время как необходимо только имя адресата.

[0047] К тому же, примерный снимок экрана, изображенный на Фиг. 2, не предназначен для ограничения вариантов осуществления данного раскрытия до транзакций денежных переводов. Скорее, на Фиг. 2 изображен один тип транзакции, в которой варианты осуществления данного изобретения могут преимущественно быть использованы для предоставления улучшенной аутентификации идентификационной информации участника транзакции, в то же время преимущественно повторно используя протокол и структуру 3-D Secure. Предполагался любой тип транзакции, при которой аутентификация идентификационных сведений участника была бы полезной.

[0048] ПРИМЕРНЫЕ СПОСОБЫ

[0049] На Фиг. 3 изображена аутентификация адресата. Отправитель (не показан) может предоставлять идентификационные сведения 302 адресата. Например, отправитель 102 мог бы предоставить такую информацию на web-странице, предоставленной сервером 106 денежных переводов, как изображено на Фиг. 2. В этом примере, информация 302 адресата включает в себя имя и фамилию адресата, его дату рождения и его номер счета. Сервер 106 денежных переводов может определять, может ли быть адресат аутентифицирован посредством отправки VEReq и приема VEResp, как описано выше по отношению к Фиг. 1. Если идентификационная информация адресата может быть аутентифицирована эмитентом адресата, процесс может продолжаться.

[0050] Сервер денежных переводов, или более конкретно, подключаемый модуль, установленный на сервере денежных переводов, может затем отправить сообщение PAReq 304 на ACS 110, который ассоциирован с эмитентом адресата. Как показано, PAReq 304, который проще может быть назван как запрос авторизации, может включать в себя идентификационные сведения адресата, которые подлежат аутентификации. В настоящем примере, информация включает в себя имя и фамилию адресата, дату рождения и номер счета.

[0051] ACS 110 может затем принять PAReq 404. Используя содержащийся в нем номер счета, ACS может запросить базу данных 110(b), ассоциированную с эмитентом, для извлечения идентификационных сведений, предоставленных адресатом, когда был создан счет. Как упомянуто выше, следует предполагать, что эмитент верифицировал идентификационную информацию адресата, когда был создан счет. ACS может затем сравнить идентификационные сведения в сообщении PAReq 304 с извлеченными сведениями 306 для определения того, есть ли совпадение.

[0052] В некоторых вариантах осуществления, ACS 110 может сделать окончательное определение того, аутентифицированы ли идентификационные сведения. Например, ACS 110 может просто возвратить значение в указатель в сообщении PAResp, которое указывает, что идентификационные сведения совпадают или не совпадают. Таким образом, ACS 110 является окончательным арбитром аутентификации идентификационной информации адресатов. ACS 110 может использовать политики, заданные эмитентом, для определения того, до какого уровня идентификационные сведения должны совпасть до того, как сведения будут считаться аутентичными. Например, как показано на Фиг. 3, сообщение PAReq 304 включает в себя основное имя адресата John, тогда как хранящиеся идентификационные сведения 306 указывают, что фактическое основное имя адресата Jonathon. Затем может быть оставлено политикам эмитента определить, является ли такая ошибка в идентификационных сведениях достаточной для указания, что сведения в сообщении PAReq не могут быть аутентифицированы. Таким образом, в таком варианте осуществления, эмитенту дается гибкость в определении того, достаточны ли идентификационные сведения для аутентификации.

[0053] В альтернативных вариантах осуществления, ACS 110 может не принять решение да/нет по отношению к результатам аутентификации. Например, для каждой порции идентификационной информации ACS 110 может отвечать указанием совпадение/несовпадение. Например, сообщение PAResp 310 может включать в себя точную предоставленную информацию, которая способна быть аутентифицирована. В данном примере, как показано на Фиг. 3, сообщение PAReq 304 указывает, что основное имя адресата John, тогда как записи эмитента указывают, что основное имя адресата Jonathon. Это результат мог бы быть сообщен обратно серверу 106 денежных переводов в форме указателя имени. Указатель имени может включать в себя значение, которое может быть интерпретировано так, чтобы указывать до какой степени совпадает имя. Например, таблица 312 указателя имени показывает возможные значения для указателя имени. Имя могло бы не иметь совпадения, основное имя совпадает, фамилия совпадает, основное имя и фамилия совпадают или полностью совпадают. В некоторых случаях, могли бы быть предоставлены дополнительные указатели для общих ошибок, таких как совпадение при перестановке, при котором основное имя и фамилию поменяли местами. Любое число таких комбинаций могло бы быть включено в указатель имени.

[0054] К тому же, некоторых вариантах осуществления указатель может быть также предоставлен для каждой второй порции идентификационной информации, которая подлежит аутентификации. Как изображено на Фиг. 3, сообщение PAResp 310 включает в себя указатель даты рождения, который указывает, совпадает ли дата рождения в сообщении PAReq 304 с датой рождения, которая находится в базе данных 306. Будет понятно специалисту в данной области техники, что могло бы быть предоставлено любое число таких указателей. В некоторых вариантах осуществления, отдельный указатель предоставляется для каждых сведений, подлежащих аутентификации, тогда как еще в одних вариантах осуществления могут быть предоставлены агрегированные указатели, такие как те, что описаны для имени выше. Следует понимать, что сообщение PAResp может включать в себя указатели, которые обеспечивают возможность серверу денежных переводов определять до какой степени идентификационные сведения адресата были аутентифицированы. Используя те указатели, сервер денежных переводов может определить должно ли транзакции быть разрешено продолжиться.

[0055] На Фиг. 4 изображена аутентификация адресата используя закодированные значения. В некоторых случаях, может быть нежелательно отправлять ценную информацию, такую как номер социального страхования, между сервером 106 денежных переводов и эмитентом 110. Сеть, такая как интернет, используемая для передачи информации, может быть небезопасной. Для того чтобы преодолеть эту потенциальную проблему, вместо того, чтобы отправлять фактическую идентификационную информацию, могли бы быть отправлены закодированные версии данной информации. В идеале, исходная информация не должна быть восстановимой из закодированной версии.

[0056] Продолжая с примером, представленным на Фиг. 3, примерным адресатом 402 мог бы быть John Doe, родившийся 01.01.1990 года, который имеет номер счета 12345. Может быть нежелательно отправлять фактическое имя John Doe между сервером 106 денежных переводов и эмитентом 110. Сервер денежных переводов может вместо этого преобразовать имя в закодированное значение. В одном варианте осуществления, это преобразование может быть в форме хэш-алгоритма, такого как SHA-1. Хэш-алгоритм типично выдает хэш-значение, которое является фиксированной длины. При правильно спроектированном хэш-алгоритме исходные данные, используемые для вычисления хэш-значения, не могут быть восстановлены из хэш-значения. Создание такого хэш-алгоритма известно в данной области техники. К тому же, хэш-значение не нуждается в соответствии одиночному элементу данных. Например, хэш-алгоритм мог бы взять в качестве ввода фамилию и дату рождения и выдать хэш-значение. Любая комбинация элементов, таких как элементов, изображенных на Фиг. 2, могла бы быть использована для генерирования хэш-значения.

[0057] Как показано на Фиг. 4, хэш-значение может быть подсчитано 403 сервером денежных переводов. Это хэш-значение и соответствующий номер счета могут быть отправлены в сообщении PAReq 404 эмитенту 110. Эмитент затем может использовать номер счета для извлечения идентификационной информации 406 для держателя счета из базы данных 110(b) эмитента. Информация типично включала бы в себя имя держателя счета и любую другую информацию 405, используемую для вычисления хэш-значения. Эмитент 110 может затем выполнить хэш-алгоритм (e.g. SHA-1) 407 над данными, извлеченными 405 из базы данных. Если сгенерированное 408 хэш-значение равняется принятому 404 хэш-значению, может быть надежно гарантировано, что имя и дата рождения, введенные на сервере денежных переводов, являются такими же, как те, что хранятся в базе данных эмитента. Это потому, что вероятность разных порций данных, таких как имена и даты рождения, хэшируемых к тому же значению, является невероятно малой при правильно спроектированным хэш-алгоритмом. Таким образом, если сгенерировано такое же хэш-значение, это означает, что был использован тот же ввод, в этом случае имя и дата рождения. В связи с этим, имя и дата рождения могут быть аутентифицированы без необходимости фактически передавать имя или дату рождения из сервера 106 денежных переводов эмитенту 110.

[0058] ACS 110 может затем сравнить хэш-значение, принятое в сообщении PAReq 404, и определить совпадает ли оно со значением подсчитанным 408 посредством ACS. Если значения совпадают, ACS может возвратить PAResp 410, который указывает совпадение хэш-значений. Сервер 106 денежных переводов может интерпретировать совпадение в хэш-значения, в качестве указания, что идентификационные сведения адресата были аутентифицированы.

[0059] В несколько другом варианте осуществления, как описано по отношению к Фиг. 4, сервер 106 денежных переводов может не включать в себя хэш-значение само по себе, в случае сообщения PAReq 404. А скорее, сервер денежных переводов может только включать в себя номер счета.

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

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

[0061] На Фиг. 5 изображена высокоуровневая схема последовательности операций аутентификации транзакции адресата. Так же, как и выше, на Фиг. 5 описано то, что касается аутентификации адресата транзакции денежного перевода, однако это является для целей объяснения. Варианты осуществления данного раскрытия преимущественно обеспечивают возможность для аутентификации идентификационной информации для любого типа транзакции, где такая информация нуждается в аутентификации. Процесс может начаться на этапе 502, в котором номер счета адресата и идентификационные сведения могут быть приняты. На этапе 504, запрашивают сервер каталогов с помощью сообщения VEReq для определения, способен ли ACS эмитента аутентифицировать адресата. На этапе 506, если эмитент не способен аутентифицировать, процесс переходит на этап 518, который будет описан ниже. Если ACS эмитента способен аутентифицировать информацию адресата, на этапе 508 VEReq отправляется эмитенту для определения того, может ли быть аутентифицирован конкретный адресат. Эмитент отвечает с помощью VEResp, который указывает, может ли быть аутентифицирован конкретный адресат на этапе 510. На этапе 512, если конкретный адресат не может быть аутентифицирован, процесс продолжается на этапе 518, описанном ниже.

[0062] На этапе 514, сообщение PAReq, содержащее идентификационные сведения адресата, отправляется эмитенту. На этапе 516, принимается PAResp от эмитента, указывающий результат аутентификации. Как рассмотрено выше, результатом могло бы быть простое да/нет для аутентификации или перечисление того, что было аутентифицировано и что не было, или указание совпадения хэш-значений, или хэш-значение само по себе. Во всех случаях, процесс достигает этапа 518, где определяется, был ли адресат достаточно аутентифицирован. То, что квалифицируется как "достаточно аутентифицирован" является гибким. Может быть установлена пороговая величина, и если аутентификация приводит к тому, что сообщение PAResp соответствует или превышает пороговую величину, адресат может считаться достаточно аутентифицированным.

[0063] Например, в случаях, где конкретные элементы, такие как основное имя и фамилия, аутентифицируются по отдельности, пороговая величина могла бы быть задана для указания того, что совпадение только по фамилии считается достаточным. Таким образом, PAResp, указывающее совпавшую фамилию, было бы достаточным, даже если не было совпадения по основному имени. Задание пороговой величины может быть очень гибким и может быть адаптировано для нужд конкретного применения. Например, случаи, где используются хэш-значения, пороговой величиной могло бы быть простое да/нет, как хэш-значение либо совпадает, либо нет. В случаях, где элементы данных аутентифицируются по отдельности, пороговая величина могла бы быть задана для указания того, что совпадение определенного числа элементов считается достаточным. Например, совпадение 3 из 5 элементов, касательно каких элементов, может считаться достаточным.

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

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

[0066] На Фиг. 6 изображена высокоуровневая схема последовательности операций аутентификации участника в транзакции. На Фиг. 6 представлены позиции сервера транзакций, такого как сервер денежных переводов. Процесс может начаться на этапе 602, в котором сообщение VEReq отправляется на сервер каталогов для определения, может ли участник в транзакции иметь аутентифицированные идентификационные сведения. На этапе 604, сообщение VEReq может быть принято, причем сообщение включает в себя, могут ли быть аутентифицированы идентификационные сведения участника. На этапе 606, результаты VEResp анализируются. Если идентификационные сведения участника не могут быть аутентифицированы, процесс переходит на этап 618, который будет описан ниже.

[0067] Если сведения для аутентификации могут быть аутентифицированы, процесс переходит на этап 608, на котором сообщение PAReq, которое включает в себя идентификационную информацию участника, отправляется на сервер управления аутентификацией эмитента участника. Как описано выше, идентификационная информация может включать в себя элементы данных, такие как имена, или может включать в себя значения, такие как хэш-значения. Конкретные идентификационные элементы являются гибкими на основе применения. На этапе 610, принимается PAResp от сервера управления аутентификацией эмитента, которое указывает результаты аутентификации.

[0068] Процесс может затем переходить на этап 612, на котором результаты PAResp анализируются для определения того, был ли участник аутентифицирован. Если участник не был аутентифицирован, процесс переходит на этап 618, который будет описан ниже. Если участник был аутентифицирован на некотором этапе, процесс переходит на этап 618. На этапе 618, определяется соответствует ли или превышает пороговую величину уровень аутентификации участника, и на основе этой пороговой величины транзакция разрешается или запрещается. Как описано выше, пороговая величина является гибкой. В некоторых случаях, пороговая величина может быть задана так, чтобы если участник не может быть полностью аутентифицирован, транзакция всегда запрещается. При других применениях, транзакция может быть разрешена, даже если ни одни идентификационные сведения участника не были аутентифицированы. В еще одних случаях, пороговая величина может быть где-то посередине.

[0069] На Фиг. 7 изображена высокоуровневая схема последовательности операций аутентификации участника в транзакции. На Фиг. 7 представлены позиции сервера управления аутентификацией эмитента. Процесс может начаться на этапе 702, в котором сообщение VEReq принимается от сервера каталогов для определения, может ли ACS аутентифицировать конкретного участника транзакции. На этапе 704, сообщение VEReq может быть возвращено, указывая, может ли участник быть аутентифицирован.

[0070] Если участник может быть аутентифицирован, на этапе 706, может быть принято сообщение PAReq, которое включает в себя идентификационную информацию участника. На этапе 708, принятая идентификационная информация участника может быть сравнена с информацией, хранимой эмитентом счета участника. Как описано выше, это сравнение может принять разные формы, от сравнения отдельных идентификационных элементов до сравнения хэш-значений. На этапе 710, могут быть возвращены результаты сравнения.

[0071] ПРИМЕРНАЯ ОПЕРАЦИОННАЯ СРЕДА

[0072] На Фиг. 8 изображена высокоуровневая схема компьютера. Различные участники и элементы на Фиг. могут управлять или использовать одно или более компьютерных устройств для обеспечения функций, описанных в настоящем документе. Любой из элементов на Фиг. 1 (например, отправитель 102, получатель 104, сервер 108, ACS 110 и т.д.) может использовать любое подходящее число подсистем для обеспечения функций, описанных в настоящем документе. Примеры таких подсистем или компонентов показаны на фиг. 8. Показанные на Фиг. 8 системы взаимосвязаны посредством системной шины 875. Показаны дополнительные подсистемы, такие как принтер 874, клавиатура 878, несъемный диск 879 (или другая память, содержащая считываемые компьютером носители), монитор 876, который соединен с адаптером 882 дисплея, и другие. Периферийные устройства и устройства ввода/вывода (I/O), которые соединены с контроллером 871 I/O, могут быть подключены к компьютерной системе посредством любого числа средств, известных в данной области техники, таких как последовательный порт 877. Например, последовательный порт 877 или внешний интерфейс 881 может быть использован для подключения компьютерного устройства в глобальной сети, такой как Интернет, устройства ввода типа "мышь" или сканера. Взаимосвязь посредством системной шины обеспечивает возможность центральному процессору 873 осуществлять связь с каждой подсистемой и управлять исполнением команд из системной памяти 872 или несъемного диска 879, равно как и обмен информацией между подсистемами. Системная память 872 и/или стационарный диск 879 могут воплощать считываемый компьютером носитель.

[0073] Любой из программных компонентов или функций, описанных в этой заявке, могут быть реализованы в виде программного кода, подлежащего исполнению процессором, используя любой подходящий компьютерный язык, такой как, например, Java, С++ или Perl, использующий, например, обычные или объектно-ориентированные методы. Программный код может быть сохранен как ряд команд, или команд, на считываемый компьютером носитель, такой как оперативная память (RAM), постоянная память (ROM), магнитный носитель, такой как накопитель на жестких дисках или гибкий магнитный диск, или оптический носитель, такой как CD-ROM. Любой такой считываемый компьютером носитель может находиться на или внутри одиночного вычислительного устройства и может присутствовать на или внутри разных вычислительных устройств внутри системы или сети.

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

[0075] Один или более признаков из любого варианта осуществления могут быть скомбинированы с одним или более признаками любого другого варианта осуществления без отступления от объема данного изобретения.

[0076] Указания на единичность не исключают множественности, пока не будет указано обратное.

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

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

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

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

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

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

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

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

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

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

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

10. Постоянный считываемый компьютером носитель по п. 9, в котором указатель указывает одно из совпадений, частичное совпадение или полное совпадение.

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

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

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

14. Постоянный считываемый компьютером носитель по п. 9, в котором указателем, отправленным в ответе авторизации, является указатель да/нет.

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

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