Расширение структуры аутентификации для верификации идентификационной информации

Расширение структуры аутентификации для верификации идентификационной информации

Иллюстрации

Показать все

Реферат

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

[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 следовал бы затем той же процедуре при подсчете хэш-значения, но вместо того, чтобы возвратить указатель совпадение/нес