Аутентифицированный платеж

Аутентифицированный платеж

Иллюстрации

Показать все

Реферат

Данная заявка испрашивает приоритет предварительной заявки на патент США, регистрационный номер 60/198.110, называемой "Аутентифицированный платеж", поданной 17 апреля 2002 года на имя Greg Whitehead, Michael Graves, Thane Plambeck.

Область техники

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

Предшествующий уровень техники

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

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

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

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

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

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

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

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

Согласно настоящему изобретению интерактивная система (100) коммерческих транзакций содержит покупателя (110), продавца (120) и службу (130) аутентификации. Для продавца (120) требуется аутентифицировать (204), что покупатель (110) имеет полномочия использовать средство платежа как часть интерактивной коммерческой транзакции с продавцом (120). Для этого служба (130) аутентификации выполняет следующие этапы, которые осуществляются в режиме реального времени, как часть интерактивной коммерческой транзакции. Служба (130) аутентификации принимает (230) запрос на подтверждение наличия у покупателя (110) полномочий использовать средство платежа.

Она определяет (246), имеет ли покупатель (110) доступ к некоторой секретной информации без раскрытия секретной информации продавцу (120). Доступ к секретной информации должен подтвердить наличие полномочий на использование средства платежа. В зависимости от определения, имеет ли покупатель (110) доступ к секретной информации, служба (130) аутентификации передает (250) продавцу (120) ответ, содержащий информацию о том, имеет ли покупатель (110) полномочия использовать средство платежа. Согласно другому аспекту изобретения служба (130) аутентификации также применяет (260) информацию с личными данными (информацию профиля) покупателя (110) в интерактивную коммерческую транзакцию и/или обрабатывает (270) или по меньшей мере частично обрабатывает транзакцию платежа. Служба (130) аутентификации также может хранить (280) запись об использовании средства платежа и/или о транзакции.

В предпочтительном варианте осуществления (300) интерактивная коммерческая транзакция осуществляется через Интернет. Покупатель (110) осуществляет доступ к Интернету через средство просмотра Web (Web-браузер), продавец (120) использует электронную витрину Интернет, размещенную на Web сервере, и служба (130) аутентификации реализуется на Web сервере. Дополнительно секретная информация содержит секретный ключ. Другими словами, создание цифровых подписей, использующих секретный ключ, должно являться доказательством того, что подписывающееся лицо имеет полномочия использовать соответствующее средство платежа. В этом варианте осуществления запрос (330) на аутентификацию инициируется представлением покупателем формы (400), которая содержит активный элемент, идентифицирующий службу (130) аутентификации. Запрос (330) в службу (130) аутентификации также содержит адрес продавца, чтобы служба аутентификации имела информацию о том, куда передать (350) результаты процесса аутентификации. Для аутентификации продавца (120) служба (130) аутентификации передает (340) запрос покупателю (110), требующий, чтобы покупатель (110) использовал секретный ключ для подписи цифровой подписью некоторых данных. Служба (130) аутентификации использует ответ (342) покупателя для определения (346), имеет ли покупатель (110) доступ к секретному ключу, и затем передает (350) результаты продавцу (120). Служба (130) аутентификации может запросить у покупателя (110) дополнительно подписать цифровой подписью запись транзакции, создавая (380), таким образом, строгую запись транзакции (имеющую юридическое значение).

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

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

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

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

фиг.1 - блок-схема системы, соответствующей настоящему изобретению;

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

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

фиг. 4-7 - разные экранные изображения и диалоговые окна, иллюстрирующие способ, представленный на фиг. 3.

Подробное описание предпочтительных вариантов осуществления

На фиг.1 изображена блок-схема системы 100 согласно настоящему изобретению. Система 100 содержит покупателя 110, продавца 120 и службу 130 аутентификации, связанные друг с другом. Система 100 также может содержать каталог 140 служб аутентификации, который является доступным для покупателя 110, и базу данных 150 профилей покупателей и архив 170 транзакций, которые доступны для службы 130 аутентификации. Необязательный шлюз 160, используемый для осуществления платежа, (шлюз платежа) также доступен для службы 130 аутентификации, хотя в альтернативных вариантах осуществления доступ к шлюзу 160 платежа может иметь продавец 120 или служба 130 аутентификации и продавец 120. Шлюз 160 платежа является просто каналом, через который передаются к соответствующим финансовым учреждениям транзакции платежа. Настоящее изобретение может использоваться с многими разными видами шлюзов 160 платежа (или даже без шлюза платежа) и не ограничено использованием конкретного вида технологии шлюзов.

Покупатель 110 предпочитает использовать средство платежа как часть интерактивной коммерческой транзакции с продавцом 120. Например, в одном приложении покупателем 110 является пользователь, продавцом 120 является электронныйпродавец с электронной витриной в Интернете, и пользователь для покупки у электронного продавца некоторого продукта, информации или услуги предпочитает использовать свою кредитную карточку. В качестве другого возможного варианта покупателем 110 является индивидуальное лицо, соединяющееся с продавцом 120 через радиотелефон или карманный персональный цифровой ассистент (ПЦА), продавцом 120 является служба оплаты счетов, и для упомянутого лица предпочтительно выписать "Интернет-чеки" для оплаты своих ежемесячных счетов. В качестве другого возможного варианта покупателем 110 является корпорация или лицо, действующее от имени корпорации, покупающее материалы или услуги у поставщика 120 корпорации. Другие возможные варианты средств платежа включают текущие номера контрольного счета, виртуальные деньги или электронные представления наличных, значение денежной предоплаты, которое хранится в электронных бумажниках, платежные карточки и кредиты или купоны Интернета.

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

На фиг.2 изображена запись событий, иллюстрирующая функционирование 200 системы 100. Способ 200 может быть приближенно разделен на три основных части: регистрация 202 покупателя, аутентификация 204 покупателя и регистрация 206 транзакции. Не во всех реализациях используются все три стадии 202-206, или все индивидуальные этапы, изображенные на фиг.2, но в рассматриваемом возможном варианте они содержатся для иллюстрации различных аспектов изобретения. При регистрации 202 покупателя между покупателем 110 и службой 130 аутентификации устанавливается секретная информация, которая будет использована на стадии 204 для аутентификации покупателя и средства платежа. Регистрация 202 покупателя предпочтительно для каждого средства платежа происходит только один раз. Аутентификация 204 покупателя происходит в режиме реального времени, как часть интерактивной коммерческой транзакции. На этой стадии покупатель 110 демонстрирует службе 130 аутентификации, что имеет доступ к секретной информации. Если демонстрация доступа прошла успешно, то служба 130 аутентификации информирует продавца 120 о том, что покупатель 110 имеет полномочия использовать средство платежа. На стадии 206 регистрации транзакций служба 130 аутентификации создает запись о транзакции, и эта запись впоследствии может использоваться как доказательство проведения конкретной транзакции.

Использование отдельной службы 130 аутентификации имеет много преимуществ. Например, как будет более понятно из последующего описания, большая часть процесса 204 аутентификации покупателя выполняется службой 130 аутентификации. Служба 130 аутентификации определяет, продемонстрировал ли покупатель 110 доступ к секретной информации и, следовательно, имеет полномочия использовать средство платежа. Покупатель 110 принимает участие только в минимальной степени, а продавец 120, по существу, не принимает участия совсем. Сосредоточение этой функции в службе 130 аутентификации приводит к значительной гибкости и снижает расходы на масштабирование. Например, для создания защиты разного уровня для разных средств платежа могут использоваться разные виды секретной информации, от простых персональных идентификационных номеров (ПИН) до сложных протоколов цифровой сертификации. Разные виды секретной информации обычно требуют разной инфраструктуры для выполнения стадии 204 аутентификации покупателя. Сосредоточение стадии 204 аутентификации покупателя в службе 130 аутентификации позволяет распределить стоимость этой инфраструктуры на многих продавцов 120. Дополнительно, если меняется вид секретной информации или соответствующая процедура аутентификации покупателя, то большая часть изменений повлияет только на службу 130 аутентификации, следовательно, позволяя легко реализовать новые технологии аутентификации. Напротив, известные способы, такие как ЗЭТ, требовали от продавца 120 обеспечения большой части необходимой инфраструктуры. Это приводило к большим затратам, медленному внедрению и трудности перехода на новые технологии, что в итоге привело к отказу от ЗЭТ и от подобных подходов.

Этот способ также имеет преимущество, поскольку продавец 120 не получает доступ к секретной информации покупателя 110, так как продавец не принимает участие в аутентификации 204 покупателя. Это предотвращает повторное использование продавцом 120 секретной информации покупателя 110 для санкционирования впоследствии мошеннических транзакций. Например, допустим, что секретной информацией является ПИН. Если бы продавец 120 был ответственен за аутентификацию 204 покупателя, то покупатель 110 должен был раскрыть свой ПИН продавцу 120, который имел возможность использовать его впоследствии в мошеннических целях. Однако в настоящем способе покупатель 110 раскрывает ПИН не продавцу 120, а только службе 310 аутентификации.

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

Согласно фиг.2 каждый из блоков 110, 120 и 130, выделенных штриховыми линиями, представляет один из компонентов в системе 100. Блоки, выделенные сплошной линией, представляют разные этапы способа 200. Размещение блока, выделенного сплошной линией, внутри блока, выделенного штриховой линией, указывает, что этап, по существу, выполняется этим компонентом. Например, этап 210 размещен внутри блока, выделенного штриховой линией, для службы 130 аутентификации. Это указывает на то, что служба аутентификации 130, по существу, выполняет этап 210. Некоторые этапы имеют два блока, что указывает на то, что этапы выполняются в двух компонентах. Например, один компонент может передавать сообщение другому компоненту. Предпочтительно, этапы реализуются программным обеспечением, выполняющимся на разных компонентах внутри системы 100, возможно, с помощью блоков аппаратного обеспечения. Этапы могут быть реализованы также в аппаратном обеспечении и/или аппаратно-программном обеспечении.

Стадия 202 регистрации покупателя предпочтительно осуществляется перед фактической интерактивной коммерческой транзакцией. На этой стадии 202 между покупателем 110 и службой 130 аутентификации 130 устанавливается секретная информация. Информация является секретной в том смысле, что в идеале она известна и/или доступна только покупателю (или покупателю 110 и службе 130 аутентификации, в случае секретной информации, совместно используемой покупателем и службой аутентификации). Она не является, по существу, доступной общественности или продавцам 120. Дополнительно секретная информация соответствует конкретному средству(ам) платежа, и доказательство доступа к секретной информации будет принято за подтверждение полномочий на использование средства платежа.

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

В конкретном возможном варианте, иллюстрируемом фиг.2, секретная информация устанавливается следующим образом. Служба 130 аутентификации принимает (210) информацию подтверждения, которая впоследствии обеспечивает службе аутентификации возможность определить, имеет ли покупатель 110 доступ к секретной информации. Затем служба 130 аутентификации хранит (212) информацию подтверждения, соответствующую средству платежа, например, как часть базы 150 данных профилей покупателя. В одном варианте осуществления, следующим за этой моделью, секретной информацией покупателя является секретный ключ, а соответствующей информацией подтверждения является соответствующий открытый ключ.

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

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

На стадии 204 аутентификации покупателя покупатель 110 предпочитает использовать средство платежа как часть интерактивной коммерческой транзакции с продавцом 120. Служба 130 аутентификации как часть транзакции определяет в режиме реального времени, имеет ли покупатель 110 на это полномочия. В конкретном возможном варианте, согласно фиг.2, это осуществляется следующим образом. Покупатель 110 предлагает (220) использовать средство платежа. Например, покупатель 110 может предложить заплатить за покупку, используя кредитную карточку.

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

Служба 130 аутентификации определяет, имеет ли покупатель 110 доступ к секретной информации, на этапах 240-246. Служба 130 аутентификации передает (240) покупателю 110 «запрос на запрос». Этот "запрос на запрос" запрашивает доказательство того, что покупатель имеет доступ к секретной информации. Например, если секретной информацией является пароль, то в "запросе на запрос" может запрашиваться пароль. Если секретной информацией является секретный ключ, то в "запросе на запрос" может запрашиваться, чтобы покупатель 110 подписал что-либо цифровой подписью, используя секретный ключ. В одном варианте осуществления "запрос на запрос" также содержит описание интерактивной коммерческой транзакции и обеспечивает покупателю возможность отклонить транзакцию, например, если описание не соответствует представлениям покупателя. Также, в "запросе на запрос" вместо этого может запрашиваться согласие покупателя на осуществление транзакции. Если покупатель 110 предпочитает продолжить, то он передает (242) свой "ответ на запрос" обратно, в службу 130 аутентификации.

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

Затем служба 130 аутентификации передает (250) продавцу 120 ответ на исходный запрос продавца. Ответ содержит информацию о том, имеет ли покупатель 110 полномочия использовать средство платежа. Также он может содержать дополнительную информацию, как описано ниже со ссылками на этапы 260 и 270. Следует отметить, что во время аутентификации покупателя 204 секретная информация продавцу 120 не передается.

Перед тем как перейти к описанию этапов 260 и 270, следует отметить, что этапы 240-250 аутентификации, иллюстрируемые фиг.2, являются только одним вариантом реализации стадии 204 аутентификации покупателя. Другие реализации будут очевидны. Например, служба 130 аутентификации может раньше принять (230) запрос на аутентификацию от покупателя 110, чем от продавца 120. Как другой возможный вариант, служба 130 аутентификации может не использовать запрос 240 и ответ 242 на запрос. Доказательство доступа к секретной информации, например, может быть включено, как часть исходного запроса 230. Дополнительно, как упомянуто на стадии 202 регистрации покупателя, служба 130 аутентификации может использовать способы помимо информации подтверждения (этапы 244 и 246) для определения, имеет ли покупатель доступ к секретной информации.

Согласно фиг.2 в некоторых вариантах осуществления служба 130 аутентификации может внести (260) в транзакцию дополнительную информацию профиля покупателя. Например, продавец 120 может запросить, чтобы к транзакции был добавлен адрес отгрузки для покупателя. Служба 130 аутентификации должна восстановить эту информацию из базы 150 данных и добавить ее к текущей транзакции. Такая дополнительная информация может быть добавлена в разных местах в ходе транзакции и может включать в себя связь с покупателем 110 или продавцом 120. В возможном варианте с использованием адреса отгрузки у покупателя 110 могут запросить подтвердить адрес, и/или продавец 120 может использовать адрес для вычисления расходов на транспорт, которые, в свою очередь, изменят сумму транзакции в долларах.

Аналогично, служба 130 аутентификации может также обрабатывать (270) транзакцию платежа, например, через шлюз 160, через который осуществляется платеж. В одном крайнем случае служба 130 аутентификации может просто уведомлять (250) продавца 120 о том, что покупатель 110 имеет полномочия использовать средство платежа, но продавец 120 выполняет все остальные этапы, требуемые для обработки средства платежа. В другом крайнем случае служба 130 аутентификации может выполнять этапы для обработки транзакции платежа. В промежуточном случае служба 130 аутентификации выполняет некоторые этапы, а покупатель завершает остальные этапы.

Применение информации профилей покупателей (260) и обработка платежей (270) предпочтительны, поскольку служба 130 аутентификации является, собственно, централизованным пунктом для осуществления таких действий. Как в случае действительных этапов 240-246 аутентификации, может быть реализовано снижение расходов на масштабирование за счет службы 130 аутентификации, выполняющей эти функции, вместо их выполнения каждым индивидуальным продавцом 120.

На стадии 206 регистрации транзакций служба 130 аутентификации сохраняет (280) запись транзакции в архиве 170 транзакций. Достоверность записи будет зависеть от конкретного приложения. Как один возможный вариант, служба 130 аутентификации может просто хранить описания открытого текста транзакции. Как другой возможный вариант, более подходящими могут быть записи с временным маркером, подписанные цифровой подписью. Рассматривая возможный вариант с использованием пароля, упомянутый выше, запись, подписанная цифровой подписью, может быть создана при подписании службой аутентификации записи цифровой подписью с использованием собственного секретного ключа. В возможном варианте с использованием секретного ключа непосредственно покупатель 110 создает запись транзакции, подписанную цифровой подписью, используя свой собственный секретный ключ. В каждом из двух последних примеров результатом является устойчивая (к взлому) запись транзакции, подписанная цифровой подписью, которая может использоваться покупателем НО, продавцом 120 или другими сторонами для разрешения спорных вопросов относительно транзакции.

Фиг. 3-7 иллюстрируют предпочтительный вариант осуществления системы 100 и способа 200. В варианте осуществления с использованием Интернета интерактивная коммерческая транзакция осуществляется через систему, основанную на протоколе передачи гипертекста HTTP, конкретно Интернет. Покупатель 110 получает доступ в Интернет, используя стандартный Web-браузер. Продавцом 120 является электронный продавец, использующий электронную витрину Web-сайта (сайта) в Интернете, в данном случае это фиктивный торговый футбольный центр Пита. Электронная витрина работает на стандартном Web сервере. Служба 130 аутентификации также взаимодействует с Интернетом через Web сервер. Покупатель 110 хочет приобрести в торговом футбольном центре Пита кубок Adidas Eqt. Predator Accelerator, используя в качестве средства платежа свою кредитную карточку. Секретной информацией, используемой для защиты транзакции, является секретный ключ, соответствующий средству платежа. Для удобства этот вариант осуществления будет определен как вариант осуществления на базе Интернет, но это не подразумевает, что данный вариант осуществления является единственно возможным для Интернета.

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

Способ 300, как и способ 200, в общем, может быть разбит на три основных части: регистрация 302 покупателя, аутентификация 304 покупателя и регистрация 306 транзакции. Однако этапы, выполняемые для аутентификации 304 покупателя, и этапы, выполняемые для регистрации 306 транзакции, взаимосвязаны друг с другом.

На стадии регистрации 302 покупателя покупатель 110 устанавливает со службой 130 аутентификации свою "учетную запись". В данном случае это означает, что проводится любая автономная проверка (например, прием подтверждения от компании кредитной карточки, что покупатель 110 имеет полномочия использовать кредитную карточку). Дополнительно для учетной записи формируется пара секретный ключ - открытый ключ, и открытый ключ хранится 312 в базе 150 данных службы аутентификации. В предпочтительном варианте осуществления открытый ключ хранится в форме цифрового сертификата, показывающего, что открытый ключ соответствует учетной записи покупателя.

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