×
09.12.2018
218.016.a543

ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ

Вид РИД

Изобретение

Юридическая информация Свернуть Развернуть
№ охранного документа
0002674329
Дата охранного документа
06.12.2018
Краткое описание РИД Свернуть Развернуть
Аннотация: Изобретение относится к средствам для защищенной обработки удаленных транзакций. Техническим результатом является повышение безопасности проведения удаленных транзакций, инициируемых из мобильных устройств. Способ содержит: прием, посредством серверного компьютера, запроса на осуществление платежа, включающего в себя зашифрованную платежную информацию, которая шифруется с использованием стороннего ключа, дешифрование зашифрованной платежной информации с использованием стороннего ключа, определение открытого ключа процессора транзакций, ассоциированного с платежной информацией, проверку достоверности того, что сертификат процессора транзакции является подлинным, извлечение открытого ключа процессора транзакции из сертификата процессора транзакции и осуществление повторного шифрования платежной информации с использованием открытого ключа процессора транзакций, отправляют ответ по осуществлению платежа, включающий в себя повторно зашифрованную платежную информацию, в процессор транзакций, который дешифрует повторно зашифрованную платежную информацию с использованием закрытого ключа процессора транзакций и инициирует платежную транзакцию. 2 н. и 20 з.п. ф-лы, 14 ил.
Реферат Свернуть Развернуть

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

[0001] Данная заявка испрашивает приоритет предварительной заявки на патент (США) № 61/957,948, поданной 15 июля 2013 года, предварительной заявки на патент (США) № 61/863,869, поданной 8 августа 2013 года, предварительной заявки на патент (США) № 61/871,814, поданной 29 августа 2013 года, и предварительной заявки на патент (США) № 61/880,154, поданной 19 сентября 2013 года, все из которых полностью фактически содержатся по ссылке в данном документе.

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

[0002] Растущее число потребителей использует устройства, выполненные с возможностью использовать протоколы связи ближнего поля (near-field communication, NFC) и другие протоколы связи ближнего действия для платежных транзакций. Например, потребительское мобильное устройство может содержать аппаратные NFC-средства и защищенный элемент или другой защищенный носитель хранения данных для сохранения конфиденциальной информации счета. Чтобы осуществлять платежную транзакцию, потребитель может помещать мобильное устройство около торгового терминала, устройства доступа или другого считывающего устройства на основе связи ближнего действия или бесконтактной связи. Транзакция затем может обрабатываться с использованием защищенной платежной информации, сохраненной на защищенном носителе хранения данных, без необходимости от пользователя предоставлять физическую кредитную карту или вводить вручную номер кредитной карты.

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

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

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

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

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

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

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

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

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

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

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

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

[0013] Фиг. 2 показывает блок-схему примерного мобильного устройства, которое может использоваться в некоторых вариантах осуществления изобретения.

[0014] Фиг. 3 показывает блок-схему примерного удаленного диспетчера ключей, согласно некоторым вариантам осуществления изобретения.

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

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

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

[0018] Фиг. 7 показывает блок-схему примерной системы для выполнения удаленной транзакции с использованием мобильного шлюза, ассоциированного с сетью обработки платежей и приложением продавца мобильного устройства, согласно некоторым вариантам осуществления изобретения.

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

[0020] Фиг. 9 показывает блок-схему последовательности операций примерного способа для обработки удаленной транзакции с использованием мобильного шлюза, ассоциированного с сетью обработки платежей и приложением продавца мобильного устройства, согласно некоторым вариантам осуществления изобретения.

[0021] Фиг. 10 показывает блок-схему примерной системы для выполнения удаленной транзакции с использованием стороннего поставщика услуг (например, поставщика мобильных кошельков) и приложения продавца мобильного устройства, согласно некоторым вариантам осуществления изобретения.

[0022] Фиг. 11 показывает блок-схему последовательности операций примерного способа для обработки удаленной транзакции с использованием стороннего поставщика услуг (например, поставщика мобильных кошельков) и приложения продавца мобильного устройства, согласно некоторым вариантам осуществления изобретения.

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

[0024] Фиг. 13 показывает блок-схему последовательности операций другого примерного способа шифрования и дешифрования информации с использованием криптографии в эллиптических кривых, согласно некоторым вариантам осуществления изобретения.

[0025] Фиг. 14 показывает блок-схему примерного компьютерного устройства.

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

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

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

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

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

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

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

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

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

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

[0035] Перед пояснением вариантов осуществления изобретения, описание некоторых терминов может быть полезным в понимании вариантов осуществления изобретения.

[0036] "Удаленная транзакция" может включать в себя любую транзакцию, в которой одна сторона в транзакции отделена на некоторое расстояние и/или посредством устройства от другой стороны в транзакции. Например, удаленная транзакция может включать в себя транзакцию по принципу "без физического наличия карты", транзакцию на базе электронной коммерции или другую онлайновую транзакцию, выполняемую через связь между двумя или более устройств. Например, удаленные транзакции могут включать в себя устройства, которые не присутствуют в идентичном местоположении, либо несколько устройств, причем две стороны (например, продавец и потребитель) не используют идентичное устройство для того, чтобы завершать транзакцию. Дополнительно, удаленная транзакция может включать в себя транзакцию в магазине, которая не завершается с использованием торгового терминала продавца (т.е. устройства доступа), а вместо этого завершается посредством использования потребителем мобильного устройства для того, чтобы обмениваться данными с удаленным (или локальным) серверным компьютером продавца, выполненным с возможностью обрабатывать удаленные транзакции. Традиционно, удаленные транзакции имеют более высокую вероятность мошенничества, поскольку удаленные транзакции не дают получателю платежа возможность идентифицировать плательщика или иным образом обеспечивать то, что оплата, которую они принимают, является легитимной, поскольку две стороны не присутствуют в идентичном местоположении в ходе транзакции (к примеру, в транзакции по принципу "с физическим наличием карты" или в магазине). Локальная транзакция, транзакция по принципу "с физическим наличием карты", транзакция в присутствии держателя карты или транзакция в магазине может включать в себя транзакцию, в которой две или более сторон в транзакции присутствуют в идентичном местоположении, используют идентичное устройство проведения транзакций, или выполняется, по меньшей мере, через одного присутствующего человека или объект, чтобы аутентифицировать идентификатор плательщика и/или получателя платежа.

[0037] "Запрос на осуществление платежа" может включать в себя сообщение, содержащее запрос на то, чтобы обрабатывать или инициировать оплату. Например, запрос на осуществление платежа может отправляться из мобильного устройства, ассоциированного с потребителем в связи с транзакцией покупки, ассоциированной с товарами или услугами, предоставляемыми посредством продавца. Запрос на осуществление платежа может включать в транзакцию любую релевантную информацию, включающую в себя платежную информацию (например, идентификаторы счетов, персональную информацию и т.д.), информацию транзакции (например, информацию продавца, приобретаемые изделия и т.д.), информацию устройства (например, телефонный номер мобильного устройства, идентификатор защищенного элемента и т.д.), информацию маршрутизации (например, адрес по Интернет-протоколу (IP) компьютера назначения, идентификатор для компьютера назначения, банковский идентификационный номер (BIN) и т.д.) и любую другую релевантную информацию для платежной транзакции. Например, запрос на осуществление платежа может включать в себя зашифрованную платежную информацию для транзакции и может отправляться в сторонний компьютер, который выполнен с возможностью аутентифицировать запрос на осуществление платежа, проверять достоверность сертификата открытых ключей, дешифровать зашифрованную платежную информацию, извлекать открытый ключ из прошедшего проверку достоверности сертификата, повторно шифровать дешифрованную платежную информацию и отправлять повторно зашифрованную платежную информацию в процессор транзакций для инициирования платежной транзакции. Соответственно, запрос на осуществление платежа может включать в себя любую информацию, релевантную для защищенного процесса для передачи конфиденциальных данных на сервер продавца для обработки удаленной транзакции.

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

[0039] При использовании в данном документе, "платежные учетные данные" могут включать в себя любую информацию, которая обеспечивает возможность процессору идентифицировать, верифицировать и/или обрабатывать платежную транзакцию с использованием счета потребителя. Например, платежные учетные данные могут включать в себя идентификатор счета (например, первичный номер счета (PAN)), маркер (token) (например, замену идентификатора счета), дату истечения срока действия, значение проверки подлинности карты (например, CVV, CVV2, dCVV и т.д.), динамическую криптограмму или динамическое значение (например, динамические аутентификационные данные), персональную информацию, ассоциированную со счетом (например, адрес и т.д.), псевдоним счета или любую другую релевантную информацию.

[0040] В некоторых вариантах осуществления, платежные учетные данные могут сохраняться в защищенном запоминающем устройстве мобильного устройства. Защищенное запоминающее устройство мобильного устройства может иметь такую конфигурацию, в которой данные, сохраненные в защищенном запоминающем устройстве, не могут быть непосредственно доступны внешним приложениям, и к мобильному платежному приложению, ассоциированному с защищенным запоминающим устройством, может осуществляться доступ, чтобы получать платежные учетные данные, сохраненные на защищенном запоминающем устройстве. Соответственно, приложение продавца может взаимодействовать с мобильным платежным приложением либо с приложением для проведения удаленных транзакций или другим приложением для проведения удаленных транзакций, чтобы взаимодействовать с мобильным платежным приложением таким образом, чтобы получать доступ к платежным учетным данным, сохраненным на защищенном запоминающем устройстве. В некоторых вариантах осуществления, к комплекту разработки программного обеспечения (SDK), интерфейсу прикладного программирования (API) либо другому стороннему программному коду или модулю может осуществляться доступ, чтобы запрашивать платежные учетные данные из мобильного платежного приложения. Дополнительно, защищенное запоминающее устройство может иметь такую конфигурацию, в которой платежные учетные данные могут предоставляться в зашифрованной форме с использованием сеансовых извлеченных ключей (SDK) на основе совместно используемого главного извлеченного ключа (MDK), ассоциированного с эмитентом платежных учетных данных, сохраненных на защищенном запоминающем устройстве из мобильного устройства. Дополнительно, может присутствовать допустимый цифровой сертификат для осуществления доступа посредством SDK или API к защищенному запоминающему устройству (например, защищенному элементу).

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

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

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

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

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

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

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

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

[0049] "Мобильный шлюз" может представлять собой серверный компьютер или последовательность серверных компьютеров, которые выполнены с возможностью обмениваться данными с мобильным устройством. Мобильный шлюз может обмениваться данными с мобильным устройством с использованием сообщений по радиоинтерфейсу (OTA) или с использованием любых других сетей и протоколов связи. Например, мобильный шлюз может быть выполнен с возможностью предоставлять защищенный канал связи (т.е. защищенный канал) с мобильным устройством, по которому информация может передаваться защищенно в/из мобильного устройства с использованием сети мобильной связи, Интернета и/или любой другой релевантной сети связи.

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

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

[0052] "Динамическое значение" может включать в себя любые данные, которые изменяются. Например, динамическое значение может изменяться во времени (например, периодически), при использовании (например, в расчете на транзакцию) и/или изменяться на основе принимаемой информации (например, входной информации в алгоритм). Например, динамическое значение может включать в себя значение аутентификации (либо значение запроса на аутентификацию), которое может изменяться каждый раз, когда инициируется транзакция, и может формироваться с использованием совместно используемого секретного алгоритма или другой совместно используемой информации между двумя объектами таким образом, что один объект может проверять достоверность того, что другой объект имеет доступ к совместно используемому секрету и в силу этого является подлинным. Оно также может упоминаться в качестве аутентификационных данных. В некоторых вариантах осуществления, динамическое значение может включать в себя криптограмму, которая формируется с использованием совместно используемого секретного алгоритма между двумя объектами. Например, криптограмма может формироваться в расчете на транзакцию на основе извлеченного алгоритма, который является конкретным для каждого потребительского устройства и/или счета эмитента, и ее достоверность может проверяться в процессоре обслуживания платежей или в эмитенте счета для каждой транзакции. Такие динамические значения могут упоминаться в качестве динамических значений проверки подлинности карты (например, dCVV, dCVV2), уникальных значений проверки подлинности для аутентификации (UAVV), значения проверки подлинности для аутентификации на основе маркеров (TAVV) и т.д. и могут отличаться на основе входных данных и алгоритма, используемого для того, чтобы формировать верифицируемые динамические значения. Например, значение проверки подлинности для аутентификации на основе маркеров может использовать маркер в качестве ввода в алгоритм проверки подлинности, в то время как динамическое значение проверки подлинности карты может использовать первичный номер счета в качестве ввода, чтобы формировать dCVV.

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

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

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

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

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

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

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

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

[0061] "Пара открытого/закрытого ключа" может включать в себя пару связанных криптографических ключей, сформированных посредством объекта. Открытый ключ может использоваться для открытых функций, таких как шифрование сообщения, которое следует отправлять в объект, или верификация цифровой подписи, которая, предположительно, выполнена посредством объекта. Закрытый ключ, с другой стороны, может использоваться для закрытых функций, таких как дешифрование принимаемого сообщения или применение цифровой подписи. Открытый ключ обычно должен авторизовываться посредством органа, известного как центр сертификации (т.е. центр сертификации), который сохраняет открытый ключ в базе данных и распределяет его в любой другой объект, который запрашивает его. Закрытый ключ типично должен сохраняться на защищенном носителе хранения данных и обычно должен быть известен только для объекта. Тем не менее, криптографические системы, описанные в данном документе, могут содержать механизмы восстановления ключей для выдачи потерянных ключей и недопущения потерь данных.

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

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

[0064] "Цифровая подпись" может означать результат применения алгоритма, который обеспечивает возможность подписывающей стороне объявлять, а верифицирующей стороне - верифицировать подлинность и целостность документа. Например, для пары открытого/закрытого ключа, подписывающая сторона может действовать посредством закрытого ключа, а верифицирующая сторона может действовать посредством открытого ключа. Этот процесс может подтверждать подлинность отправителя и целостность подписанного документа вследствие так называемого принципа неотрицаемости, которая не разрешает отрицание того, что подписано. Сертификат или другие данные, которые включают в себя цифровую подпись посредством подписывающей стороны, как говорят, "подписываются" посредством подписывающей стороны.

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

[0066] "Центр сертификации" может включать в себя любой объект, выполненный с возможностью выдавать сертификаты. Центр сертификации может удостоверять свой идентификатор с использованием сертификата центра сертификации, который включает в себя открытый ключ центра сертификации. Сертификат центра сертификации может быть подписан посредством закрытого ключа другого центра сертификации или может быть подписан посредством закрытого ключа идентичного центра сертификации. Последний известен как самоподписанный сертификат. Центр сертификации также типично поддерживает базу данных всех сертификатов, выданных посредством центра сертификации.

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

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

[0069] "Маркер" может включать в себя любую замену данных. Например, маркер может включать в себя замену для идентификатора счета в эмитенте, сети обработки платежей, продавце или любом другом объекте транзакции. Маркер может идентифицировать платежный счет или неплатежный счет, причем взаимосвязь между счетом и маркером управляется посредством реестра 1061 или базы данных маркеров.

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

[0071] Варианты осуществления настоящего изобретения, описанные в данном документе, включают в себя несколько различных вариантов осуществления, которые могут комбинироваться любым подходящим способом, как должны признавать специалисты в данной области техники. Например, в различных вариантах осуществления, описанных ниже, поясняются различные специальные стороны, приложения продавцов, мобильные платежные приложения и процессоры транзакций, и конкретные блок-схемы последовательности операций способа предоставляются в качестве примеров. Эти примеры предоставляются для иллюстрации принципов настоящего изобретения и должны быть неограничивающими. Соответственно, признаки из различных вариантов осуществления могут комбинироваться любым подходящим способом, включающим в себя использование зарегистрированных открытых ключей и сертификатов открытых ключей в конфигурациях, отличных от конфигураций, которые предоставляются явно в каждой иллюстративной системе, описанной в данном документе. Например, процессы на основе сертификатов открытых ключей (как описано в связи с фиг. 1 и 5-6) могут использоваться со сторонними поставщиками услуг (как показано в системе по фиг. 10), и процессы на основе зарегистрированных ключей (как описано в связи с фиг. 10) могут использоваться с удаленным диспетчером ключей (как описано в связи с фиг. 1 и 5-6). Соответственно, это представляет собой только один пример различных комбинаций, которые могут предоставляться согласно некоторым вариантам осуществления настоящего изобретения, которое может быть подробнее описано ниже.

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

[0072] Фиг. 1 показывает блок-схему примерной системы 100 для выполнения удаленной транзакции с использованием удаленного диспетчера 140 ключей и приложения 121 продавца мобильного устройства 120, согласно некоторым вариантам осуществления изобретения. Система 100 содержит пользователя (например, потребителя 110), мобильное устройство 120, включающее в себя приложение 121 продавца, защищенный элемент 122 и мобильное платежное приложение 123, удаленный диспетчер 140 ключей, центр 180 сертификации, компьютер 130 продавца, компьютер 150 эквайера, сеть 160 обработки платежей и компьютер 170 эмитента. Различные объекты могут быть выполнены с возможностью обмениваться данными друг с другом по любой подходящей сети беспроводной или проводной связи и с использованием любого подходящего протокола связи, включающего в себя открытые или собственные протоколы связи.

[0073] При использовании в данном документе, "эмитент" типично может означать коммерческую организацию (например, банк), которая поддерживает финансовые счета для пользователя и зачастую выдает портативное потребительское устройство, такое как кредитная или дебетовая карта, пользователю. Эмитент также может выдавать или инициализировать информацию счета для мобильного устройства 120, чтобы предоставлять возможность мобильных платежей, инициируемых посредством мобильного устройства. "Продавец" типично представляет собой объект, который участвует в транзакциях и может продавать товары или услуги. "Эквайер" типично представляет собой коммерческую организацию (например, коммерческий банк), которая имеет деловые отношения с конкретным продавцом или другим объектом. Некоторые объекты могут выполнять функции эмитента и эквайера. Некоторые варианты осуществления могут охватывать таких эмитентов-эквайеров как один объект. Каждый из объектов может содержать одно или более компьютерных устройств (например, компьютер 130 продавца, компьютер 150 эквайера, сеть 160 обработки платежей и компьютер 170 эмитента) для того, чтобы обеспечивать связь или выполнять одну или более функций, описанных в данном документе.

[0074] Сеть 160 обработки платежей может включать в себя подсистемы, сети и операции обработки данных, используемые для того, чтобы поддерживать и доставлять услуги центра сертификации, услуги авторизации, услуги обработки файлов заблокированных карт, услуги бальной оценки транзакций и услуги клиринга и расчетов. Примерная сеть 160 обработки платежей может включать в себя VisaNet™. Сети обработки платежей, такие как VisaNet™, могут обрабатывать транзакции по кредитным картам, транзакции по дебетовым картам и другие типы коммерческих транзакций. VisaNet™, в частности, включает в себя систему VIP (систему объединенных платежей Visa), которая обрабатывает запросы на авторизацию, и систему Base II, которая выполняет услуги клиринга и расчетов.

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

[0076] В некоторых платежных транзакциях по принципу "с физическим наличием карты" или платежных транзакциях в магазине, пользователь приобретает товар или услугу у продавца с использованием мобильного устройства 120. Например, мобильное устройство 120 пользователя может взаимодействовать с устройством доступа (не показано) у продавца, ассоциированного с компьютером 130 продавца. Например, пользователь может выполнять быстрое прикосновение мобильного устройства 120 к считывающему устройству по стандарту связи в поле в ближней зоне (NFC) в устройстве доступа. Альтернативно, в удаленной транзакции или транзакции по принципу "без физического наличия карты", пользователь может указывать сведения по оплате компьютеру 130 продавца электронно, к примеру, в онлайновой транзакции.

[0077] Сообщение с запросом на авторизацию может формироваться посредством мобильного устройства 120 или компьютера 130 продавца и затем перенаправляться в компьютер 150 эквайера. После приема сообщения с запросом на авторизацию, сообщение с запросом на авторизацию затем отправляется в сеть 160 обработки платежей. Сеть 160 обработки платежей затем перенаправляет сообщение с запросом на авторизацию в соответствующий компьютер 170 эмитента, ассоциированный с эмитентом, ассоциированным с пользователем.

[0078] "Сообщение с запросом на авторизацию" может представлять собой электронное сообщение, которое отправляется в сеть 160 обработки платежей и/или эмитенту платежной карты, чтобы запрашивать авторизацию для транзакции. Сообщение с запросом на авторизацию согласно некоторым вариантам осуществления может соответствовать ISO 8583, который представляет собой стандарт для систем, которые обмениваются информацией электронных транзакций, ассоциированной с платежом, произведенным пользователем с использованием платежного устройства или платежного счета. Сообщение с запросом на авторизацию может включать в себя идентификатор счета эмитента, который может быть ассоциирован с платежным устройством или платежным счетом. Сообщение с запросом на авторизацию также может содержать дополнительные элементы данных, соответствующие "идентификационной информации", включающие в себя, только в качестве примера: служебный код, CVV (значение проверки подлинности карты), dCVV (динамическое значение проверки подлинности карты), дату истечения срока действия и т.д. Сообщение с запросом на авторизацию также может содержать "информацию транзакции", к примеру, любую информацию, ассоциированную с текущей операцией, такую как сумма транзакции, идентификатор продавца, местоположение продавца и т.д., а также любую другую информацию, которая может быть использована при определении того, следует или нет идентифицировать и/или авторизовать транзакцию. Сообщение с запросом на авторизацию также может включать в себя другую информацию, к примеру, информацию, которая идентифицирует устройство доступа, которое формирует сообщение с запросом на авторизацию, информацию относительно местоположения устройства доступа и т.д.

[0079] После того, как компьютер 170 эмитента принимает сообщение с запросом на авторизацию, компьютер 170 эмитента отправляет сообщение с ответом по авторизации обратно в сеть 160 обработки платежей, чтобы указывать то, авторизуется (или не авторизуется) текущая транзакция. Сеть 160 обработки платежей затем перенаправляет сообщение с ответом по авторизации обратно в компьютер 150 эквайера. В некоторых вариантах осуществления, сеть 160 обработки платежей может отклонять транзакцию, даже если компьютер 170 эмитента авторизует транзакцию, например, в зависимости от значения бальной оценки риска мошенничества. Компьютер 150 эквайера затем отправляет ответное сообщение обратно в компьютер 130 продавца.

[0080] "Сообщение с ответом по авторизации" может представлять собой ответ в форме электронного сообщения на сообщение с запросом на авторизацию, сформированное посредством финансового учреждения-эмитента 170 или сети 160 обработки платежей. Сообщение с ответом по авторизации может включать в себя, только в качестве примера, один или более следующих индикаторов состояния: Approval (подтверждение) - транзакция подтверждена; Decline (отклонение) - транзакция не подтверждена; или Call Center (через центр обработки вызовов) - ответ, предполагающий дополнительную информацию, продавец должен позвонить по бесплатному телефонному номеру для авторизации. Сообщение с ответом по авторизации также может включать в себя код авторизации, который может представлять собой код, который банк-эмитент кредитных карт возвращает в ответ на сообщение с запросом на авторизацию в электронном сообщении (либо непосредственно, либо через сеть 160 обработки платежей) в компьютер 130 продавца, который указывает подтверждение транзакции. Код может служить в качестве подтверждения авторизации. Как отмечено выше, в некоторых вариантах осуществления, сеть 160 обработки платежей может формировать или перенаправлять сообщение с ответом по авторизации продавцу.

[0081] После того, как компьютер 130 продавца принимает сообщение с ответом по авторизации, компьютер 130 продавца затем может предоставлять сообщение с ответом по авторизации пользователю. Ответное сообщение может отображаться посредством мобильного устройства 120 или может быть распечатано на физическом чеке платежа. Альтернативно, если транзакция представляет собой онлайновую транзакцию, продавец может предоставлять веб-страницу или другой индикатор относительно сообщения с ответом по авторизации в качестве виртуального чека платежа. Чеки платежей могут включать в себя данные транзакции для транзакции.

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

[0083] В системе обработки удаленных транзакций по фиг. 1, мобильное устройство 120 выполнено с возможностью инициировать и обрабатывать удаленную транзакцию с компьютером 130 продавца с использованием удаленного диспетчера 140 ключей, чтобы предоставлять окружение проведения защищенных удаленных платежных транзакций, даже при использовании неизвестного приложения 121 продавца, либо другое приложение для мобильных устройств устанавливается на мобильном устройстве 120.

[0084] Пользователь (например, потребитель 110) может управлять мобильным устройством 120 с возможностью выполнять любое число функций, которые мобильное устройство 120 выполнено с возможностью осуществлять. Например, потребитель 110 может использовать мобильное устройство 120, чтобы осуществлять удаленные платежные транзакции посредством обмена данными с удаленным диспетчером 140 ключей и компьютером 130 продавца. Компьютер 130 продавца может доставлять доступные продукты и услуги в приложение 121 продавца, которое потребитель 110 может использовать для того, чтобы инициировать удаленную транзакцию независимо от того, расположен он в местоположении продавца или удаленно от продавца.

[0085] Мобильное устройство 120 может быть выполнено с возможностью обмениваться данными с удаленным диспетчером 140 ключей, который выполнен с возможностью упрощать и/или обрабатывать удаленную транзакцию. Удаленный диспетчер 140 ключей выполнен с возможностью осуществлять определенное число функций, связанных с удаленной транзакцией, включающих в себя прием зашифрованной платежной информации, проверку достоверности сертификата открытых ключей, ассоциированного с удаленной транзакцией, дешифрование зашифрованной платежной информации с использованием ключа из удаленного диспетчера ключей и повторное шифрование платежной информации с использованием открытого ключа, ассоциированного с процессором транзакций (например, продавцом, процессором продавца, эквайером и т.д.) для транзакции. Различные модули удаленного диспетчера 140 ключей подробнее описываются на фиг. 3.

[0086] "Мобильное устройство" может включать в себя любое электронное вычислительное устройство. Например, мобильное устройство 120 может включать в себя мобильный телефон, планшетный компьютер, нетбук, переносной компьютер или любое другое подходящее мобильное вычислительное устройство. Мобильное устройство 120 может содержать приложение 121 продавца и мобильное платежное приложение 123. Мобильное платежное приложение 123 может сохраняться в защищенном запоминающем устройстве (например, защищенном элементе 122).

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

[0088] Защищенный элемент 122 может представлять собой любой аппаратный или программный компонент, выполненный с возможностью защищенно сохранять любую информацию и/или защищенные приложения. Например, защищенный элемент 122 может быть выполнен с возможностью сохранять платежную информацию. Дополнительно, мобильное платежное приложение 123 может быть инициализировано и сохранено в защищенном элементе 122, чтобы защищенно осуществлять доступ к персонализированной конфиденциальной информации (например, платежным учетным данным, маркерам, идентификаторам счетов и т.д.), ассоциированной с потребительским финансовым счетом. Например, в некоторых вариантах осуществления, защищенный элемент 122 может включать в себя защищенный криптопроцессор или бесконтактную интегральную схему, чтобы защищать информацию, сохраненную в защищенном элементе 122. Защищенный элемент 122 может иметь отдельный процессор, сохраненная информация может шифроваться с секретными ключами, хранимыми только посредством доверенных диспетчеров услуг или других обозначенных объектов, и защищенный элемент 122 может содержать любые другие аппаратные средства, так что защищенный элемент 122 может представлять собой защищенную область, в которой может сохраняться важная информация (например, платежные учетные данные, ключи шифрования и любая другая конфиденциальная информация). Дополнительно, к защищенным элементам данных защищенного элемента 122 может осуществляться доступ только с использованием специальных секретных ключей, к которым могут иметь доступ только определенные доверенные диспетчеры услуг.

[0089] Мобильное платежное приложение 123 может включать в себя любой интерфейс прикладного программирования (API), услугу, приложение, апплет или другой исполняемый код, подходящий для того, чтобы извлекать платежную информацию из защищенного модуля хранения данных или защищенного элемента 122 и обмениваться данными с приложением 121 продавца. В некоторых вариантах осуществления, мобильное платежное приложение 123 может быть защищено. Например, мобильное платежное приложение 123 может запускаться в защищенном элементе 122 (как показано на фиг. 2) или в другом доверенном окружении, в качестве службы ядра или на более высоком уровне разрешений, чем приложение 121 продавца.

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

[0091] Фиг. 2 показывает блок-схему примерного мобильного устройства 120, согласно некоторым вариантам осуществления изобретения. Мобильное устройство 120 может включать в себя схему, которая используется для того, чтобы предоставлять определенные функции устройства, такие как телефония. Функциональные элементы, отвечающие за предоставление этих функций, могут включать в себя процессор 120(A), который программируется с возможностью осуществлять инструкции, которые реализуют функции и операции устройства. Процессор 120(A) может осуществлять доступ к устройству 120(E) хранения данных (либо другой подходящей области запоминающего устройства или запоминающему элементу) для того, чтобы извлекать инструкции или данные, используемые при выполнении инструкций, к примеру, приложения продавцов, приложение для проведения удаленных транзакций или другие приложения для мобильных устройств. Элементы 120(C) ввода/вывода данных, такие как клавиатура или сенсорный экран, могут использоваться для того, чтобы предоставлять возможность пользователю управлять мобильным устройством 120 и вводить данные (например, аутентификационные данные пользователя). Элементы ввода/вывода данных также могут быть выполнены с возможностью выводить данные (например, через динамик). Дисплей 120(B) также может использоваться для того, чтобы выводить данные пользователю. Элемент 120(D) связи может использоваться для того, чтобы обеспечивать передачу данных между мобильным устройством 120 и проводной или беспроводной сетью (например, через антенну 120(H)), с тем чтобы помогать в подключении к Интернету или другой сети связи и обеспечении функций передачи данных.

[0092] Мобильное устройство 120 также может включать в себя интерфейс 120(F) бесконтактного элемента или интерфейс защищенного запоминающего устройства, чтобы обеспечивать передачу данных между бесконтактным элементом 120(G) и другими элементами устройства, причем бесконтактный элемент 120(G) может включать в себя защищенное запоминающее устройство (например, защищенный элемент 122) и элемент передачи данных по технологии связи в поле в ближней зоне (либо по другой форме технологии ближней или бесконтактной связи). Как отмечено выше, сотовый телефон или аналогичное устройство является примером мобильного устройства 120, которое может использоваться в соответствии с вариантами осуществления настоящего изобретения. Тем не менее, другие формы или типы устройств могут использоваться без отступления от базовых принципов изобретения. Дополнительно, устройства могут не требовать возможности обмениваться данными с использованием сотовой сети для того, чтобы быть подходящими для использования с вариантами осуществления настоящего изобретения.

[0093] Фиг. 3 показывает блок-схему примерного удаленного диспетчера 140 ключей, согласно некоторым вариантам осуществления изобретения. Удаленный диспетчер 140 ключей может содержать серверный компьютер 141, базу 141(F) данных корневых открытых ключей центра сертификации и базу 141(E) данных закрытых ключей. Серверный компьютер 141 может содержать модуль 141(A) проверки подлинности сертификатов, модуль 141(B) извлечения открытых ключей, модуль 141(C) обработки транзакций и интерфейс 141(D) мобильного устройства. Серверный компьютер 141 дополнительно может содержать процессор (не показан) и компьютерно-читаемый носитель (не показан), соединенный с процессором, причем компьютерно-читаемый носитель содержит код, выполняемый посредством процессора, для осуществления способа, как описано в вариантах осуществления в данном документе.

[0094] Модуль 141(A) проверки подлинности сертификатов может быть выполнен с возможностью верифицировать сертификат продавца (либо другой сертификат процессора транзакций) как ассоциированный с конкретным продавцом, подлинный и допустимый. Модуль 141(A) проверки подлинности сертификатов может выполнять любое число этапов, чтобы выполнять эту функциональность. Например, модуль 141(A) проверки подлинности сертификатов может обмениваться данными с центром 180 сертификации, чтобы обеспечивать то, что открытый сертификат в данный момент является допустимым и на хорошем счету (например, не сообщен, через списки аннулированных сертификатов (CRL) или ответчики по протоколу определения онлайнового состояния сертификатов (CSPR) и т.п., как скомпрометированный или аннулированный). Дополнительно, модуль 141(A) проверки подлинности сертификатов может использовать корневой открытый ключ центра сертификации, сохраненный в базе 141(F) данных корневых ключей, чтобы проверять достоверность того, что сертификат открытых ключей является легитимным и подписан посредством соответствующего центра 180 сертификации.

[0095] Возвращаясь к фиг. 1, центр 180 сертификации может быть ассоциирован с серверным компьютером продавца и может выдавать для компьютера 130 продавца сертификат открытых ключей, который может использоваться в ходе обработки удаленных платежных транзакций, чтобы устанавливать доверие между сторонним серверным компьютером (например, удаленным диспетчером 140 ключей) и серверным компьютером продавца в отношении того, что компьютер 130 продавца является подлинным и авторизован на получение конфиденциальных платежных учетных данных в зашифрованной платежной информации. Процесс, посредством которого центр 180 сертификации может выдавать сертификат продавца, подробнее описан на фиг. 4 ниже. Некоторые неограничивающие примеры способов выдачи сертификатов содержатся в документе "ANSI X9.24 Part 2 Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys", и в документе "ISO 11568 Part 4 Banking - Key management (retail) - Part 4: Asymmetric cryptosystems - Key management and life cycle".

[0096] Модуль 141(B) извлечения открытых ключей может быть выполнен с возможностью извлекать открытый ключ из принимаемого или сохраненного сертификата открытых ключей для использования при обработке удаленной транзакции. Открытый ключ может извлекаться с использованием любых подходящих процессов. В некоторых вариантах осуществления, открытый ключ может извлекаться до или после проверки достоверности и/или проверки подлинности сертификата открытых ключей.

[0097] Модуль 141(C) обработки транзакций может быть выполнен с возможностью обрабатывать запрос на осуществление платежа и предоставлять ответ по осуществлению платежа в ответ в запрос на осуществление платежа при условии, что принимаемый или сохраненный сертификат открытых ключей является допустимым и активным для транзакции. Например, модуль 141(C) обработки транзакций может дешифровать принимаемые зашифрованные сообщения с использованием закрытого ключа из удаленного диспетчера ключей, сохраненного в базе 141(E) данных закрытых ключей, и использовать извлеченный открытый ключ процессора транзакций из сертификата процессора транзакций (например, сертификата продавца) для того, чтобы повторно шифровать дешифрованное сообщение или информацию из сообщения для надежной доставки в процессор транзакций. Модуль 141(C) обработки транзакций дополнительно может передавать повторно зашифрованное сообщение (например, ответ по осуществлению платежа) в интерфейс 141(D) мобильного устройства для доставки в надлежащий процессор транзакций.

[0098] Интерфейс 141(D) мобильного устройства может быть выполнен с возможностью обмениваться данными с мобильным устройством 120. Например, мобильное устройство 120 может включать любые подходящие протоколы связи или сетевые интерфейсы, чтобы обмениваться данными с мобильным устройством 120. Интерфейс 141(D) мобильного устройства может принимать сообщение (например, запрос на осуществление платежа) из мобильного устройства 120 и может быть выполнен с возможностью синтаксически анализировать сообщение, чтобы определять релевантную информацию, включенную в сообщение.

[0099] База 141(E) данных закрытых ключей может содержать закрытый ключ для удаленного диспетчера 140 ключей (также называемый "закрытым ключом из удаленного диспетчера ключей"). Закрытый ключ может формироваться через любой подходящий способ и может сохраняться защищенно, так что неавторизованным объектам не предоставляется доступ к закрытому ключу. В некоторых вариантах осуществления, закрытый ключ может сохраняться в локальном запоминающем устройстве или в удаленной защищенной базе данных. В некоторых вариантах осуществления, закрытый ключ может представлять собой один из пары закрытого/открытого ключа, ассоциированной с удаленным диспетчером 140 ключей, и открытый ключ может предоставляться в приложения 121 продавцов, мобильные платежные приложения 123, мобильные устройства 120, приложения для проведения удаленных транзакций (не показаны) и любые другие объекты транзакции, которые выполнены с возможностью шифровать платежную информацию для обработки посредством удаленного диспетчера 140 ключей. Дополнительно, в некоторых вариантах осуществления, база 141(E) данных закрытых ключей может включать в себя симметричный ключ шифрования, который может использоваться в том случае, если данные шифруются с использованием симметричного ключа шифрования вместо пары открытого/закрытого ключа шифрования.

[0100] База 141(F) данных корневых открытых ключей может содержать корневой открытый ключ для центра сертификации, ассоциированного с сертификатом открытых ключей. В некоторых вариантах осуществления, один корневой открытый ключ центра сертификации может сохраняться в удаленном диспетчере ключей, ассоциированном с одним центром сертификации (и может сохраняться локально на компьютере удаленного диспетчера ключей), в то время как в других вариантах осуществления, несколько корневые ключи центра сертификации могут сохраняться в базе данных или локально на компьютере удаленного диспетчера ключей. Корневой открытый ключ центра сертификации может использоваться в процессе проверки достоверности подписей, чтобы обеспечивать то, что сертификат открытых ключей является допустимым и активным с выдающим центром сертификации.

Способы выдачи/инициализации сертификатов продавцам

[0101] Фиг. 4 показывает блок-схему последовательности операций примерного способа 400 для инициализации пар открытых/закрытых ключей продавцов и сертификатов приложений продавцов с использованием центра 180 сертификации, согласно некоторым вариантам осуществления изобретения. В некоторых вариантах осуществления, способ 400 может осуществляться, чтобы предоставлять компьютеру 130 продавца сертификат, указывающий степень доверия или подлинность продавца. Затем, принимаемый сертификат продавца может быть включен в приложения продавцов, установленные или предоставленные в мобильных устройствах.

[0102] На этапе 401, компьютер 130 продавца формирует пару открытого/закрытого ключа продавца. Пара открытого/закрытого ключа продавца может формироваться в любом подходящем формате, таком как RSA или криптография в эллиптических кривых (ECC). В некоторых вариантах осуществления, закрытый ключ продавца может сохраняться защищенно на компьютере 130 продавца.

[0103] На этапе 402, компьютер 130 продавца отправляет открытый ключ продавца из пары открытого/закрытого ключа в центр 180 сертификации. Центр 180 сертификации может включать в себя любой подходящий объект, выполненный с возможностью выдавать и проверять достоверность сертификата. Например, в некоторых вариантах осуществления, центр 180 сертификации может включать в себя сеть 160 обработки платежей, удаленный диспетчер 140 ключей, поставщика мобильных кошельков, объект, который не включен в типичную систему обработки платежных транзакций, или любой другой объект.

[0104] На этапе 403, центр 180 сертификации верифицирует подлинность продавца с использованием любого подходящего средства. Например, компьютер 130 продавца может предоставлять центру 180 сертификации информацию, предоставляющую идентификатор компьютера 130 продавца как управляемого посредством продавца. В одном примере, компьютер 130 продавца может предоставлять документ, подписанный авторизованной подписавшей стороной продавца (например, президентом организации продавца).

[0105] На этапе 404, центр 180 сертификации формирует подписанный сертификат продавца с использованием принимаемого запроса на подписание сертификата продавца, который включает в себя открытый ключ продавца. Типично, сертификат продавца может быть подписан посредством корневого закрытого ключа центра сертификации. Подпись центра сертификации обеспечивает возможность объекту проверять подлинность сертификата продавца с использованием корневого открытого ключа центра сертификации.

[0106] На этапе 405, центр 180 сертификации отправляет подписанный сертификат продавца в компьютер 130 продавца.

[0107] На этапе 406, компьютер 130 продавца формирует подписанный сертификат приложения продавца с использованием закрытого ключа продавца. Таким образом, цепочка доверия может устанавливаться от сертификата приложения продавца, к сертификату продавца, к корневому сертификату центра сертификации. В некоторых вариантах осуществления, подписанный сертификат приложения продавца может быть ассоциирован с экземпляром или версией приложения 121 продавца. Например, сертификат приложения продавца может использоваться для того, чтобы верифицировать то, что приложение 121 продавца исходит от продавца.

[0108] На этапе 407, компьютер 130 продавца сохраняет сертификат приложения продавца и закрытый ключ приложения продавца, ассоциированный с сертификатом приложения продавца, в приложении 121 продавца. Таким образом, когда приложение 121 продавца загружается на мобильное устройство 120, подлинность приложения 121 продавца может быть верифицирована.

[0109] Следует понимать, что фиг. 4 имеет намерение быть описательным и неограничивающим. Например, в некоторых вариантах осуществления изобретения, пара открытого/закрытого ключа продавца может формироваться посредством центра 180 сертификации, и закрытый ключ продавца может предоставляться в компьютер 130 продавца защищенно, например, с использованием сообщения на основе криптографических стандартов с открытым ключом (PKCS) № 12.

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

[0110] Фиг. 5 показывает блок-схему последовательности операций примерного способа 500 для обработки удаленной транзакции с использованием удаленного диспетчера 140 ключей и приложения 121 продавца мобильного устройства 120, согласно некоторым вариантам осуществления изобретения. В некоторых вариантах осуществления, способ по фиг. 5 может осуществляться после того, как сертификат приложения продавца инициализирован (например, в соответствии со способом 400) и сохранен в приложении 121 продавца с или без закрытого ключа приложения продавца. Затем, способ по фиг. 5 может выполняться, чтобы осуществлять удаленную платежную транзакцию для товаров или услуг.

[0111] На этапе 501, приложение 121 продавца отправляет информацию получателя платежа в мобильное платежное приложение 123 для выполнения удаленной платежной транзакции. Информация получателя платежа может включать в себя информацию, подходящую для того, чтобы идентифицировать способ оплаты пользователя (например, платежные учетные данные, ассоциированные с мобильным платежным приложением 123), продавца, ассоциированного с мобильным платежным приложением 123 (и удаленной платежной транзакцией), тип транзакции (например, удаленная транзакция) и любую другую информацию, которая может быть релевантной для мобильного платежного приложения 123 для обработки удаленной платежной транзакции. Например, информация получателя платежа может включать в себя имя пользователя, идентификатор сети обработки платежей, ассоциированный со способом оплаты (например, Visa™, MasterCard™ и т.д.), и последние четыре цифры номера счета для мобильного платежного приложения 123, чтобы идентифицировать платежные учетные данные или информацию счета, которую следует использовать для удаленной платежной транзакции.

[0112] Дополнительно, информация получателя платежа может включать в себя идентификатор продавца, который предоставлен в приложение 121 продавца (либо на сервер продавца, ассоциированный с приложением 121 продавца) в ходе фазы регистрации для услуги обработки удаленных транзакций или удаленного диспетчера 140 ключей. В некоторых вариантах осуществления, информация получателя платежа может использоваться для того, чтобы идентифицировать сертификат продавца, который следует предоставлять в удаленный диспетчер 140 ключей (например, для вариантов осуществления, в которых мобильное платежное приложение 123 передает сертификат продавца в удаленный диспетчер 140 ключей).

[0113] Дополнительно, информация получателя платежа может включать в себя тип идентификатора транзакции, информирующего мобильное платежное приложение 123 в отношении того, что запрос ассоциирован с удаленной платежной транзакцией. Соответственно, мобильное платежное приложение 123 может выбирать надлежащий открытый ключ шифрования, с помощью которого следует шифровать платежную информацию (например, открытый ключ удаленного диспетчера ключей), надлежащий целевой или маршрутный адрес для удаленного диспетчера 140 ключей и корректный протокол связи или формат сообщений для обмена данными с удаленным диспетчером 140 ключей.

[0114] На этапе 502, мобильное платежное приложение 123 использует принимаемую информацию получателя платежа для того, чтобы извлекать и/или формировать платежную информацию из защищенного элемента 122 мобильного устройства 120. "Платежная информация" может включать в себя данные платежной карты (например, номер платежного счета (PAN) и дату истечения срока действия), криптограмму (к примеру, динамическое значение проверки подлинности карты (dCVV или dCVV2) или другие динамически сформированные данные) либо любую другую информацию, подходящую для того, чтобы осуществлять удаленную платежную транзакцию.

[0115] На этапе 503, мобильное платежное приложение 123 шифрует платежную информацию с использованием ключа из удаленного диспетчера ключей. Ключ из удаленного диспетчера ключей может представлять собой симметричный или открытый ключ, ассоциированный с парой открытого/закрытого ключа удаленного диспетчера ключей. В некоторых вариантах осуществления, мобильное платежное приложение 123 может определять открытый ключ удаленного диспетчера ключей с использованием сертификата удаленного диспетчера ключей, сохраненного на мобильном устройстве 120, может запрашивать сертификат из мобильного диспетчера ключей или может получать открытый ключ удаленного диспетчера ключей в защищенном элементе 122 или общем запоминающем устройстве из мобильного устройства 120. Если ключ из удаленного диспетчера ключей представляет собой симметричный ключ, симметричный ключ может сохраняться защищенно с помощью мобильного платежного приложения 123.

[0116] На этапе 504, мобильное платежное приложение 123 отправляет зашифрованную платежную информацию в приложение 121 продавца. Следует отметить, что поскольку закрытый ключ из удаленного диспетчера ключей неизвестен посредством приложения 121 продавца, зашифрованная платежная информация не может быть расшифрована посредством приложения 121 продавца.

[0117] На этапе 505, приложение 121 продавца принимает зашифрованную платежную информацию и формирует запрос на осуществление платежа, включающий в себя зашифрованную платежную информацию, принимаемую зашифрованную платежную информацию, любые другие данные транзакции (например, сумму транзакции, идентификатор продавца, идентификаторы продуктов и т.д.), ассоциированные с платежной транзакцией, которые не включены в зашифрованную платежную информацию, сертификат продавца, ассоциированный с компьютером 130 продавца, и подпись, сформированную с использованием закрытого ключа компьютера продавца. Приложение 121 продавца затем может передавать запрос на осуществление платежа в удаленный диспетчер 140 ключей. В некоторых вариантах осуществления, запрос на осуществление платежа может шифроваться с использованием сеансового ключа, устанавливаемого между удаленным диспетчером 140 ключей и мобильным устройством 120. Сеансовый ключ может устанавливаться и передаваться через любой подходящий способ.

[0118] На этапе 506, удаленный диспетчер 140 ключей принимает запрос на осуществление платежа, может дешифровать запрос на осуществление платежа с использованием сеансового ключа и синтаксически анализирует зашифрованную платежную информацию, незашифрованные данные транзакции, сертификат продавца и подпись из запроса на осуществление платежа. Удаленный диспетчер 140 ключей может проверять достоверность подписи. Типично, подпись может проходить проверку достоверности с использованием открытого ключа, включенного в сертификат продавца. Альтернативно, в некоторых вариантах осуществления, открытый ключ может быть зарегистрирован и сохранен в удаленном диспетчере ключей как ассоциированный с сертификатом продавца. Если подпись не проходит проверку достоверности, то удаленный диспетчер 140 ключей указывает приложению 121 продавца, что подпись недопустима, и способ прекращается. В противном случае, способ переходит к этапу 507. Следует отметить, что проверка достоверности подписи является необязательной (и также подписывание является необязательным) и может возникать на периодической основе, и в силу этого подпись также может не передаваться из компьютера 130 продавца.

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

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

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

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

[0123] На этапе 511, компьютер 130 продавца принимает повторно зашифрованную платежную информацию и дешифрует повторно зашифрованную платежную информацию с использованием закрытого ключа продавца, сохраненного на компьютере 130 продавца. Таким образом, в первый раз при обработке удаленных транзакций, компьютер 130 продавца может получать доступ к платежной информации (например, платежным учетным данным и/или другой защищенной информации), которую мобильное платежное приложение 123 получает и шифрует, из защищенного запоминающего устройства из устройства мобильной связи. Например, сервер продавца может получать идентификатор счета (например, первичный номер счета (PAN)) и дату истечения срока действия, ассоциированную с платежным счетом, а также конкретную для транзакции криптограмму или динамическое значение. Криптограмма предоставляет дополнительные возможности аутентификации и проверки достоверности для процессора обслуживания платежей и/или эмитента и обеспечивает минимизированный риск мошенничества в таких удаленных транзакциях.

[0124] На этапе 512, компьютер 130 продавца может использовать дешифрованную платежную информацию для того, чтобы инициировать и/или осуществлять платежную транзакцию. Например, компьютер 130 продавца может формировать сообщение с запросом на авторизацию, включающее в себя информацию, которая типично должна присутствовать в транзакциях по принципу "с физическим наличием карты" (например, платежные учетные данные, данные на основе микросхемы шифрования и т.д.). Соответственно, компьютер 130 продавца может увязывать дешифрованную платежную информацию (а также другую информацию транзакции, включенную в ответ по осуществлению платежа) с форматом, ассоциированным с сообщением с запросом на авторизацию компьютера 130 продавца, компьютера 150 эквайера, сети 160 обработки платежей и компьютера 170 эмитента.

[0125] Следует понимать, что фиг. 5 имеет намерение быть описательным и неограничивающим. Например, как показано ниже в отношении фиг. 6, любое число различных объектов может использоваться для того, чтобы дешифровать повторно зашифрованную платежную информацию. Например, фиг. 6 показывает три различных варианта для дешифрования и передачи платежной информации. Другие объекты транзакции также могут быть выполнены с возможностью дешифровать повторно зашифрованную платежную информацию и инициировать платежную транзакцию.

[0126] Фиг. 6 показывает дополнительные примерные способы для осуществления удаленной транзакции с использованием удаленного диспетчера 140 ключей и приложения 121 продавца мобильного устройства 120, согласно некоторым вариантам осуществления изобретения. Например, как показано на фиг. 6, после того, как удаленный диспетчер 140 ключей дешифрует зашифрованную платежную информацию, удаленный диспетчер 140 ключей может повторно шифровать платежную информацию с использованием открытого ключа, ассоциированного с любым числом различных объектов обработки транзакций. Например, вместо использования открытого ключа приложения продавца для того, чтобы шифровать платежную информацию, открытый ключ продавца (ассоциированный с закрытым ключом, сохраненным в серверном компьютере продавца) или открытый ключ эквайера (ассоциированный с закрытым ключом, сохраненным на компьютере 150 эквайера) может использоваться для того, чтобы шифровать платежную информацию, и повторно зашифрованная платежная информация может передаваться в каждый соответствующий объект (например, серверный компьютер продавца или компьютер 150 эквайера) для дешифрования и формирования сообщений с запросом на авторизацию.

[0127] Этапы 601-608 (только некоторые из которых показаны на фиг. 6) являются аналогичными этапам, поясненным выше в отношении фиг. 5. Например, на этапе 601, приложение 121 продавца отправляет информацию получателя платежа в мобильное платежное приложение 123 мобильного устройства 120, чтобы идентифицировать надлежащую платежную информацию для транзакции. Дополнительно, на этапах 602-604, мобильное платежное приложение 123 шифрует платежную информацию с использованием открытого ключа удаленного диспетчера ключей и отправляет зашифрованную платежную информацию в удаленный диспетчер 140 ключей.

[0128] Тем не менее, на этапе 605, в зависимости от конфигурации системы обработки удаленных транзакций, любое число сертификатов открытых ключей (например, сертификат открытых ключей приложения продавца, сертификат открытых ключей продавца, сертификат открытых ключей эквайера и т.д.) может передаваться в удаленный диспетчер 140 ключей. Приложение 121 продавца может определять то, какой сертификат открытых ключей должен предоставляться, а также информацию маршрутизации для зашифрованной платежной информации, как только повторно зашифрованная платежная информация возвращается из удаленного диспетчера 140 ключей.

[0129] Этапы 606-608 являются аналогичными этапам, описанным выше в отношении этапов 506-508 по фиг. 5; тем не менее, идентификатор сертификата процессора транзакций может включать в себя любое из приложения 121 продавца, компьютера 130 продавца или компьютера 150 эквайера. Соответственно, удаленный диспетчер 140 ключей может проверять достоверность принимаемого сертификата открытых ключей, дешифровать зашифрованную платежную информацию (например, идентификатор счета и криптограмма) и повторно шифровать дешифрованную платежную информацию (например, данные карты и криптограмму) с открытым ключом, извлеченным из принимаемого сертификата открытых ключей. Как пояснено выше, сертификат открытых ключей может быть ассоциирован с любым процессором транзакций, в том числе, например, с компьютером 130 продавца, приложением 121 продавца или компьютером 150 эквайера.

[0130] На этапах 609A-609C, удаленный диспетчер 140 ключей может отправлять повторно зашифрованную платежную информацию в объект обработки транзакций (например, приложение 121 продавца, компьютер 130 продавца, компьютер 150 эквайера и т.д.), ассоциированный с принимаемым сертификатом открытых ключей (и затем с открытым ключом, используемым для того, чтобы шифровать платежную информацию).

[0131] Например, для варианта A, сертификат открытых ключей, отправленный на этапе 605, включает в себя сертификат открытых ключей приложения продавца, так что удаленный диспетчер 140 ключей проверяет достоверность сертификата и извлекает или иным образом получает открытый ключ приложения продавца. Соответственно, открытый ключ приложения продавца используется для того, чтобы повторно шифровать дешифрованную платежную информацию, и на этапе 609A, удаленный диспетчер 140 ключей отправляет повторно зашифрованную платежную информацию в приложение 121 продавца.

[0132] На этапе 610A, приложение 121 продавца может принимать повторно зашифрованную платежную информацию, определять закрытый ключ приложения продавца, ассоциированный с повторно зашифрованной платежной информацией, и дешифровать повторно зашифрованную платежную информацию с использованием закрытого ключа приложения продавца. Соответственно, приложение 121 продавца может иметь конфиденциальную информацию, которая сохранена в защищенном элементе 122, а также защищенную информацию, которая сформирована с использованием защищенных алгоритмов мобильного платежного приложения 123 для платежной транзакции. Например, приложение 121 продавца может иметь платежные учетные данные потребителя (например, идентификатор счета, дату истечения срока действия, значение проверки подлинности карты (CVV), персональную информацию и т.д.), а также криптограмму или другое динамическое значение, которое может использоваться для того, чтобы аутентифицировать то, что мобильное платежное приложение 123, используемое для того, чтобы формировать данные транзакции, является подлинным.

[0133] Приложение 121 продавца затем может инициировать платежную транзакцию с использованием дешифрованной платежной информации. Приложение 121 продавца может инициировать платежную транзакцию с использованием любого подходящего способа. Например, приложение 121 продавца может формировать сообщение с запросом на авторизацию, выполненное с возможностью отправляться через сеть 160 обработки платежей. Альтернативно, хотя не показано на фиг. 6, приложение 121 продавца может шифровать дешифрованную платежную информацию снова с использованием ключа сервера продавца и может отправлять платежную информацию в компьютер 130 продавца для дешифрования и инициирования платежной транзакции. В связи с этим, дешифрованная платежная информация может передаваться в компьютер 130 продавца для формирования сообщения с запросом на авторизацию или другого инициирования платежной транзакции.

[0134] На этапе 612A, компьютер 130 продавца может отправлять сообщение с запросом на авторизацию в компьютер 150 эквайера, ассоциированный с продавцом для обработки транзакции. Сообщение с запросом на авторизацию может отправляться по защищенному каналу связи с использованием ключа шифрования для зашифрованной линии связи или процесса шифрования. Соответственно, в некоторых вариантах осуществления, платежная информация, включенная в сообщение с запросом на авторизацию, может шифроваться еще раз и отправляться в компьютер 150 эквайера для обработки. Любой другой защищенный процесс может использоваться для того, чтобы отправлять сообщение с запросом на авторизацию в эквайер через защищенный процесс. Хотя не показано на фиг. 6, компьютер 150 эквайера затем может перенаправлять сообщение с запросом на авторизацию в сеть 160 обработки платежей, которая выполнена с возможностью обрабатывать платежную транзакцию, как если платежная транзакция представляет собой транзакцию по принципу "с физическим наличием карты" или другую локальную транзакцию.

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

[0136] В некоторых вариантах осуществления, сеть 160 обработки платежей может определять то, что сообщение с запросом на авторизацию ассоциировано с удаленной платежной транзакцией, на основе типа криптограммы или динамических данных, сформированных посредством мобильного платежного приложения 123, либо посредством индикатора уровня безопасности, предоставленного в платежной информации или в сообщении с запросом на авторизацию. Например, мобильное платежное приложение 123, приложение 121 продавца или компьютер 130 продавца могут предоставлять индикатор уровня безопасности, который информирует платежную сеть, а также эмитентов, в отношении того, что транзакция инициирована удаленно, но обработана через способ обработки защищенных удаленных платежных транзакций, описанный в данном документе. В таких вариантах осуществления, могут быть предусмотрены различные индикаторы уровня безопасности для традиционной незащищенной (или на основе клавишного ввода) транзакции по принципу "без физического наличия карты". Соответственно, индикатор уровня безопасности может информировать различные объекты в отношении того, кто несет ответственность за мошенничество в платежной транзакции (например, продавец в сравнении с эмитентом), а также риски, ассоциированные с такими типами транзакций.

[0137] Удаленная платежная транзакция дополнительно может маршрутизироваться эмитенту, ассоциированному с платежными учетными данными, и может приниматься решение по авторизации, и транзакция может быть авторизована или отклонена, как подробно описано выше в отношении фиг. 1. Сообщение с ответом по авторизации может формироваться и возвращаться через систему обработки транзакций в серверный компьютер продавца, приложение 121 продавца, мобильное платежное приложение 123, чтобы обновлять информацию предыстории счетов или транзакций, ассоциированную с мобильным платежным приложением 123 или защищенным элементом 122 и предоставленную для потребителя 110. Соответственно, транзакция может обрабатываться.

[0138] Альтернативно, для варианта B, сертификат открытых ключей, отправленный на этапе 605, включает в себя сертификат открытых ключей продавца, так что удаленный диспетчер 140 ключей проверяет достоверность сертификата и извлекает или иным образом получает открытый ключ продавца. Следовательно, открытый ключ продавца используется для того, чтобы повторно шифровать платежную информацию, и на этапе 609B, удаленный диспетчер 140 ключей отправляет повторно зашифрованную платежную информацию в компьютер 130 продавца.

[0139] Любое число различных способов может использоваться для того, чтобы отправлять повторно зашифрованную платежную информацию в компьютер 130 продавца. Например, сообщение с ответом по осуществлению платежа может включать в себя незашифрованную информацию маршрутизации, ассоциированную с компьютером 130 продавца, так что приложение 121 продавца может автоматически маршрутизировать повторно зашифрованную платежную информацию в компьютер 130 продавца. Альтернативно или в комбинации, приложение 121 продавца может иметь информацию маршрутизации (например, адрес серверного компьютера), ассоциированную с компьютером 130 продавца, программируемую в приложении 121 продавца, и когда транзакция инициируется, приложение 121 продавца может знать, что любое соответствующее сообщение с ответом по осуществлению платежа может маршрутизироваться в компьютер 130 продавца. Дополнительно, флаг или другой элемент данных в принимаемом сообщении, включающем в себя повторно зашифрованную платежную информацию, может указывать приложению 121 продавца то, в какое место и в какой объект отправлять повторно зашифрованную платежную информацию.

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

[0141] На этапах 610B-611B, компьютер 130 продавца может дешифровать повторно зашифрованную платежную информацию, инициировать платежную транзакцию и отправлять сообщение с запросом на авторизацию в эквайер, как описано на этапах 611A-612A выше.

[0142] Дополнительно, для варианта C, сертификат открытых ключей, отправленный на этапе 605, включает в себя сертификат открытых ключей эквайера, так что удаленный диспетчер 140 ключей проверяет достоверность сертификата и извлекает или иным образом получает открытый ключ эквайера. Следовательно, открытый ключ эквайера используется для того, чтобы повторно шифровать платежную информацию, и на этапе 609C, удаленный диспетчер 140 ключей отправляет повторно зашифрованную платежную информацию в компьютер 150 эквайера. Процессы, аналогичные процессам, описанным выше в отношении отправки зашифрованной платежной информации открытого ключа продавца, могут использоваться для того, чтобы отправлять в компьютер 150 эквайера зашифрованную платежную информацию, включающие в себя либо маршрутизацию информации через приложение 121 продавца и компьютер 130 продавца, либо непосредственную отправку зашифрованной платежной информации в компьютер 150 эквайера.

[0143] На этапе 610C, компьютер 150 эквайера может дешифровать повторно зашифрованную платежную информацию, инициировать платежную транзакцию и отправлять сообщение с запросом на авторизацию в эквайер, как описано на этапах 611A-612A и 610B-611B выше.

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

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

[0145] Другой вариант осуществления настоящего изобретения включает в себя систему для выполнения удаленной транзакции с использованием мобильного шлюза 190, ассоциированного с компьютером 161 сети обработки платежей. Взаимодействие через интерфейс с сетью 160 обработки платежей может обеспечивать определенное число преимуществ, включающих в себя дополнительные возможности аутентификации, включающие в себя проверку достоверности значений аутентификации до того, как транзакция отправляется через платежную сеть, с использованием сообщения с запросом на авторизацию в сеть 160 обработки платежей. Соответственно, сеть 160 обработки платежей может выполнять дополнительные процессы аутентификации (например, управление рисками, проверки по оборачиваемости и т.д.) для запроса на осуществление платежа (и ассоциированного счета потребителя) до того, как инициируется оплата, что может обеспечивать возможность сети 160 обработки платежей информировать систему продавца в отношении того, является или нет транзакция подлинной, до того, как инициируется транзакция, через сообщение с запросом на авторизацию. Продавец затем может изменять процессы принятия решений на основе рисков, аутентификации и любые другие процессы проведения транзакций на основе результатов аутентификации, предоставленных посредством сети обработки платежей.

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

[0147] Фиг. 7 показывает блок-схему примерной системы 700 для выполнения удаленной транзакции с использованием мобильного шлюза 190, ассоциированного с сетью 160 обработки платежей и приложением 121 продавца мобильного устройства 120, согласно некоторым вариантам осуществления изобретения. Как можно видеть на фиг. 7, система 700 обработки удаленных транзакций является аналогичной системе, показанной на фиг. 1; тем не менее, вместо независимого удаленного диспетчера 140 ключей, система 700 включает в себя мобильный шлюз 190, который обеспечивает возможность мобильному устройству 120 передавать зашифрованную платежную информацию запроса на осуществление платежа непосредственно в сеть 160 обработки платежей, которая выполнена с возможностью обрабатывать удаленную платежную транзакцию. Сеть 160 обработки платежей может допускать предоставление определенного числа дополнительных признаков и характеристик для способа обработки защищенных удаленных платежных транзакций, как подробнее описано ниже.

[0148] Описание большинства объектов системы по фиг. 7 содержится выше в отношении фиг. 1, так что подробное пояснение не предоставляется здесь. Тем не менее, мобильное устройство 120 по фиг. 7 выполнено с возможностью обмениваться данными с мобильным шлюзом 190, который выполнен с возможностью обмениваться данными с сетью 160 обработки платежей, которая может быть ассоциирована или отвечать за обработку удаленной платежной транзакции.

[0149] Мобильный шлюз 190 может содержать ключ шифрования мобильного шлюза, который может совместно использоваться с мобильным платежным приложением 123, сохраненным в защищенном элементе 122 мобильного устройства 120. Ключ шифрования мобильного шлюза может быть симметричным или из пары открытого/закрытого ключа шифрования. Ключ шифрования мобильного шлюза может быть инициализирован в мобильном платежном приложении 123 и может обеспечивать возможность мобильному платежному приложению 123 инициировать защищенный канал с мобильным шлюзом 190, что может обеспечивать возможность мобильному платежному приложению 123 предоставлять сквозное шифрование для связи между мобильным платежным приложением 123 и компьютером 161 сети обработки платежей. Альтернативно или в комбинации, мобильное платежное приложение 123 может использовать открытый ключ мобильного шлюза, чтобы защищенно шифровать и передавать информацию в/из мобильного шлюза 190. Соответственно, мобильный шлюз 190 может быть выполнен с возможностью дешифровать зашифрованную платежную информацию, которая шифруется с использованием открытого ключа или другого защищенного ключа шифрования, сохраненного в защищенном элементе 122 мобильного устройства 120. Соответственно, конфиденциальные данные могут быть защищенно совместно использованы мобильным устройством 120 и серверным компьютером мобильного шлюза.

[0150] Мобильный шлюз 190 может включать в себя модуль формирования защищенных каналов, который выполнен с возможностью конфигурировать защищенную линию связи между мобильным шлюзом 190, мобильным устройством 120 и компьютером 161 сети обработки платежей. Модуль формирования защищенных каналов может обмениваться любой релевантной информацией для формирования посредством мобильного платежного приложения 123 и мобильного шлюза 190 совпадающих или комплементарных сеансовых ключей для защищенной передачи конфиденциальной информации. Любой другой подходящий способ для формирования защищенного канала может реализовываться.

[0151] Дополнительная информация относительно характеристик мобильного шлюза 190 содержится в заявке (США) № 13/662,843, поданной 29 октября 2012 года, озаглавленной "Over The Air Update of Payment Transaction Data Stored in Secure Memory", заявке (США) № 12/563,410, поданной 21 сентября 2009 года, озаглавленной "Apparatus and Method for Preventing Unauthorized Access to Payment Application Installed in Contactless Payment Device", и заявке (США) № 13/563,421, поданной 21 сентября 2009 года, озаглавленной "Over The Air Update of Payment Transaction Data Stored in Secure Memory", которые фактически полностью содержатся в данном документе по ссылке.

[0152] В дополнение к модулям, описанным выше в отношении фиг. 1, сеть 160 обработки платежей по фиг. 7 может иметь определенное число других модулей, ассоциированных с характеристиками обработки удаленных платежных транзакций, описанными в данном документе. Например, сеть 160 обработки платежей дополнительно может содержать закрытый ключ из пары открытого/закрытого ключа шифрования (например, пары ключей шифрования сети обработки платежей), и открытый ключ шифрования сети обработки платежей может совместно использоваться с компьютером 130 продавца, который зарегистрирован для предоставленной сетью 160 обработки платежей обработки удаленных транзакций. Следует отметить, что мобильный шлюз 190 и модули, описанные в данном документе для сети 160 обработки платежей, могут считаться интегрированными в один объект либо также могут подразделяться на дополнительные объекты. Например, мобильный шлюз 190 может быть интегрирован в серверный компьютер 161 сети обработки платежей, или функции шифрования и дешифрования сети 160 обработки платежей могут быть включены в мобильный шлюз 190.

[0153] Фиг. 8 показывает блок-схему примерной сети 160 обработки платежей, согласно некоторым вариантам осуществления изобретения. Сеть 160 обработки платежей может содержать серверный компьютер 161, базу 161(F) данных зарегистрированных ключей и базу 161(G) данных закрытых ключей. Серверный компьютер 161 может содержать модуль 161(A) регистрации ключей, модуль 161(B) проверки достоверности криптограмм, модуль 161(C) обработки транзакций, модуль 161(D) проверки достоверности продавцов и интерфейс 141(E) мобильного шлюза. Серверный компьютер 161 дополнительно может содержать процессор (не показан) и компьютерно-читаемый носитель (не показан), соединенный с процессором, причем компьютерно-читаемый носитель содержит код, выполняемый посредством процессора, для осуществления способа, как описано в вариантах осуществления в данном документе.

[0154] Модуль 161(A) регистрации ключей может включать в себя любой программный модуль, который выполнен с возможностью регистрировать ключи шифрования, совместно используемые секреты и/или любую другую информацию процессора транзакций (например, приложения 121 продавца, компьютера 130 продавца, компьютера 150 эквайера и т.д.) в компьютере 161 сети обработки платежей, чтобы предоставлять возможность обработки удаленных платежных транзакций.

[0155] База 161(F) данных зарегистрированных ключей может содержать зарегистрированные открытые ключи из пар открытых/закрытых ключей, ассоциированных с различными продавцами, приложениями продавцов, эквайерами и/или любыми другими процессорами транзакций, которые зарегистрированы для обработки удаленных транзакций. База 161(F) данных зарегистрированных ключей может включать в себя любую подходящую информацию для получения надлежащего открытого ключа для данной транзакции, включающего в себя открытые ключи, сохраняемые с соответствующим сертификатом открытых ключей и/или ассоциированные с конкретным идентификатором продавца, который предоставляется в ходе регистрации. Идентификатор продавца может быть включен в запрос на осуществление платежа, который может обеспечивать возможность модулю 161(C) обработки транзакций сети 160 обработки платежей идентифицировать надлежащий открытый ключ процессора транзакций, ассоциированный с транзакцией.

[0156] База 161(G) данных закрытых ключей может включать в себя базу данных или локальное запоминающее устройство серверного компьютера 161 сети обработки платежей, который включает в себя закрытый ключ сети обработки платежей, ассоциированный с открытым ключом сети обработки платежей из пары открытого/закрытого ключа. База 161(G) данных закрытых ключей может быть защищенной и может сохранять закрытый ключ защищенным и доступным только из серверного компьютера 161 сети обработки платежей. В некоторых вариантах осуществления, может быть предусмотрено несколько закрытых ключей, ассоциированных с сетью 160 обработки платежей.

[0157] Модуль 161(D) проверки достоверности продавцов может включать в себя любой программный модуль, который выполнен с возможностью проверять достоверность регистрации продавца (или другого процессора транзакций), ассоциированного с удаленной платежной транзакцией. Например, модуль 161(D) проверки достоверности продавцов может определять то, зарегистрирован или нет продавец на компьютере 161 сети обработки платежей, чтобы обеспечивать то, что сеть 160 обработки платежей имеет доступ к открытому ключу, ассоциированному с компьютером 130 продавца или приложением 121 продавца. Аналогично функциональности удаленного диспетчера 140 ключей, описанного выше в отношении фиг. 3, модуль 161(D) проверки достоверности продавцов может проверять достоверность сертификата открытых ключей продавца, если он предоставляется, чтобы обеспечивать то, что сертификат продавца является в данный момент допустимым и активным. Если продавец (или другой процессор транзакций) не может проходить проверку достоверности, обработка удаленных платежных транзакций может прекращаться.

[0158] Модуль 161(B) проверки достоверности криптограмм может включать в себя любой программный модуль, который выполнен с возможностью проверять достоверность криптограммы или другого динамического значения аутентификации, ассоциированного с запросом на осуществление платежа. Модуль 161(B) проверки достоверности криптограмм может использовать совместно используемые секреты или совместно используемые алгоритмы для того, чтобы проверять достоверность криптограммы, которая использует повторяющиеся входные данные для того, чтобы повторно вычислять и сравнивать динамическую криптограмму для транзакции. Например, криптограмма или другое динамическое значение может формироваться посредством мобильного платежного приложения 123 с использованием идентификатора счета, даты истечения срока действия, времени транзакции, суммы транзакции или любой другой подходящей информации транзакции, которая может быть доступной как для мобильного платежного приложения 123, так и для сети 160 обработки платежей (либо компьютера эмитента или другого объекта обработки). Совместно используемый алгоритм может совместно использоваться мобильным платежным приложением и сетью обработки платежей (либо эмитентом или другим объектом обработки).

[0159] Дополнительно, модуль 161(B) проверки достоверности криптограмм может быть выполнен с возможностью формировать значение ответа по аутентификации с использованием секретного алгоритма, защищенно сохраненного в сети 160 обработки платежей, и секретный алгоритм не используется совместно с другими объектами в системе обработки удаленных транзакций. Соответственно, модуль 161(B) проверки достоверности криптограмм может проверять достоверность динамической криптограммы, сформированной посредством мобильного платежного приложения 123, и может возвращать другую динамическую криптограмму (например, значение ответа по аутентификации), которая может возвращаться в мобильное устройство 120 и отправляться с любым сообщением с запросом на авторизацию, которое формируется для транзакции. Соответственно, сеть 160 обработки платежей может получать значение ответа по аутентификации в ходе обработки транзакций сообщения с запросом на авторизацию и может проверять достоверность того, что значение ответа по аутентификации совпадает со сформированным сообщением с ответом по аутентификации, первоначально сформированным посредством сети 160 обработки платежей в ходе начальной обработки удаленной платежной транзакции. Соответственно, сеть 160 обработки платежей может удостоверяться в том, что транзакция не изменена, и в том, что данные транзакции являются идентичными транзакции, которая первоначально аутентифицирована посредством компьютера 161 сети обработки платежей.

[0160] Модуль 161(C) обработки транзакций может включать в себя любой программный модуль, который выполнен с возможностью принимать запрос на осуществление платежа, включающий в себя зашифрованную платежную информацию, дешифровать зашифрованную платежную информацию, определять открытый ключ процессора транзакций, повторно шифровать дешифрованную платежную информацию с открытым ключом и предоставлять ответ по осуществлению платежа, включающий в себя повторно зашифрованную платежную информацию, в процессор транзакций.

[0161] Интерфейс 161(E) мобильного шлюза может обеспечивать возможность сети 160 обработки платежей взаимодействовать с мобильным шлюзом 190 и получать из мобильного шлюза 190 связь, по которой сеть 160 обработки платежей может допускать дешифрование, либо которая может уже дешифроваться.

[0162] Фиг. 9 показывает блок-схему последовательности операций примерного способа 900 для выполнения удаленной транзакции с использованием мобильного шлюза 190, ассоциированного с сетью 160 обработки платежей и приложением 121 продавца мобильного устройства 120, согласно некоторым вариантам осуществления изобретения.

[0163] На этапе 901, потребитель 110 инициирует удаленную платежную транзакцию с использованием приложения 121 продавца, и приложение 121 продавца отправляет в серверный компьютер продавца сообщение, указывающее то, что потребитель 110 хочет инициировать удаленную транзакцию.

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

[0165] На этапе 903, приложение 121 продавца перенаправляет зашифрованные данные транзакции в мобильное платежное приложение 123 мобильного устройства 120. В этом варианте осуществления, приложение 121 продавца не может изменять или изменять данные транзакции и может просто выступать в качестве посредника между компьютером 130 продавца и мобильным платежным приложением 123.

[0166] На этапах 904-907, устанавливается защищенный канал, и связь отправляется между мобильным платежным приложением 123, мобильным шлюзом 190, ассоциированным с сетью 160 обработки платежей, и компьютером 161 сети обработки платежей, чтобы инициализировать и подготавливать защищенный канал. Защищенный канал обеспечивает возможность шифрования и защиты от перехвата будущей связи между мобильным устройством 120 и сетью 160 обработки платежей.

[0167] Защищенный канал может устанавливаться любым подходящим способом. Например, защищенный канал может устанавливаться с использованием ключа шифрования мобильного шлюза, инициализированного в мобильном платежном приложении 123 в ходе персонализации мобильного платежного приложения 123. Соответственно, ключи шифрования, используемые для того, чтобы устанавливать защищенный канал, могут включать в себя сеансовый ключ, который изменяется для каждого сеанса или удаленной платежной транзакции. Аналогичный процесс описывается в заявке на патент (США) № 13/075,592 авторов Aabye и др., поданной 30 марта 2011 года, которая настоящим полностью содержится в данном документе по ссылке.

[0168] Дополнительно, ключ шифрования может представлять собой уникальный извлеченный ключ (UDK), который извлекается из главного ключа, предоставленного посредством эмитента мобильного платежного приложения 123, доверенного диспетчера услуг (SM), ассоциированного с защищенным элементом 122, или эмитента защищенных элементов. Дополнительно, может реализовываться любой другой подходящий способ шифрования, как должны признавать специалисты в данной области техники. В связи с этим, защищенное соединение может реализовываться с использованием таких стандартов шифрования данных, как, например, RSA с ключом, по меньшей мере, в 1024 битов, стандарт тройного шифрования данных (DES), 128-битовый усовершенствованный стандарт шифрования (AES), RC4-алгоритм поточного шифрования с использованием минимальной 128-битовой длины ключа и т.д.

[0169] На этапе 908, после того, как установлен защищенный канал, мобильное платежное приложение 123 может формировать и отправлять запрос на осуществление платежа, включающий в себя зашифрованную платежную информацию с использованием платежных учетных данных, сохраненных в защищенном элементе 122, и ключа шифрования мобильного шлюза, сохраненного или извлекаемого с использованием информации, сохраненной в защищенном элементе 122 (например, совместно используемого ключа шифрования или способа для формирования уникального извлеченного ключа для каждого сеанса). Запрос на осуществление платежа может включать в себя зашифрованные данные транзакции, принятые из компьютера 130 продавца и приложения 121 продавца, без дополнительного изменения или получения доступа к зашифрованной информации транзакции. Зашифрованная платежная информация может включать в себя платежные учетные данные, криптограмму транзакции или другое динамическое значение и любую другую информацию в отношении того, что мобильный шлюз 190 и/или сеть 160 обработки платежей должны обрабатывать запрос на осуществление платежа по удаленной транзакции. Следует отметить, что в этом варианте осуществления, зашифрованная платежная информация может шифроваться с сеансовым ключом, который может включать в себя другой ключ шифрования по сравнению с парой открытого/закрытого сетевого ключа.

[0170] Соответственно, мобильный шлюз 190 может дешифровать зашифрованную платежную информацию, предоставленную посредством мобильного платежного приложения 123, без влияния на зашифрованную информацию транзакции, которая передается из сервера продавца и шифруется с открытым ключом сети обработки платежей. Следовательно, мобильный шлюз 190 может использовать один ключ шифрования для связи по защищенному каналу, и сеть 160 обработки платежей может использовать другой ключ шифрования для дешифрования зашифрованной информации транзакции, предоставленной посредством компьютера 130 продавца. Следовательно, мобильное платежное приложение 123 может использовать первый ключ (например, сеансовый ключ) для того, чтобы формировать и защищенно передавать платежные учетные данные и потребительскую информацию, сохраненную в защищенном элементе 122 мобильного устройства 120, и сеть 160 обработки платежей может использовать второй ключ (например, закрытый ключ сети обработки платежей) для того, чтобы дешифровать информацию транзакции, передаваемую из серверного компьютера продавца.

[0171] На этапе 909, модуль 161(B) проверки достоверности криптограмм компьютера 161 сети обработки платежей проверяет достоверность криптограммы в принимаемом запросе на осуществление платежа как сформированной посредством подлинного мобильного платежного приложения 123. Криптограмма проверки достоверности может формироваться посредством сети 160 обработки платежей с использованием информации транзакции и/или платежной информации, которая совместно используется сетью 160 обработки платежей и мобильным платежным приложением 123 через защищенный канал, предоставленный посредством мобильного шлюза 190. Если принимаемая криптограмма совпадает со сформированной криптограммой проверки достоверности, сеть 160 обработки платежей может определять то, что платежная информация сформирована посредством допустимого и подлинного мобильного платежного приложения 123.

[0172] На этапе 910, модуль 161(C) обработки транзакций компьютера 161 сети обработки платежей может дешифровать данные транзакции с использованием закрытого ключа, ассоциированного с сетью 160 обработки платежей. Дешифрованная информация транзакции может включать в себя идентификатор продавца или любую другую информацию продавца, так что сеть 160 обработки платежей может определять идентификатор и ассоциированный открытый ключ, которые следует использовать для того, чтобы обрабатывать удаленную платежную транзакцию. Дополнительно, модуль 161(D) проверки достоверности продавцов сети 160 обработки платежей может проверять достоверность того, что продавец, ассоциированный с дешифрованной информацией транзакции, является зарегистрированным, допустимым, активным и на хорошем счету для системы обработки удаленных платежных транзакций.

[0173] На этапе 911, дешифрованная платежная информация может аутентифицироваться с использованием любого числа внутренних или внешних процессов аутентификации. Например, процесс аутентификации на основе рисков, сохраненных учетных данных, ответа на оклик или любой другой тип процесса аутентификации потребителей может завершаться. В некоторых вариантах осуществления, мобильный шлюз 190 может запрашивать аутентификационную информацию от потребителя 110 через запрос на аутентификацию, оклик, запрос на пароль или через любой другой подходящий способ. Альтернативно или в комбинации, компьютер 161 сети обработки платежей может определять то, аутентифицирует или нет приложение 121 продавца или мобильное платежное приложение 123 заранее потребителя 110, и может использовать эту информацию для того, чтобы определять то, следует или нет выполнять процессы аутентификации потребителей, и то, какие процессы аутентификации следует выполнять. Например, информация, связанная со способами проверки подлинности держателей карт, выполняемыми посредством приложения 121 продавца до того, как инициируется транзакция, может передаваться в компьютер 161 сети обработки платежей.

[0174] На этапе 912, если процессы аутентификации завершаются удачно, и криптограмма проходит проверку достоверности, модуль 161(B) проверки достоверности криптограмм может формировать значение ответа по аутентификации для транзакции с использованием закрытого ключа, ассоциированного с мобильным шлюзом 190 или сетью 160 обработки платежей. Значение ответа по аутентификации может проходить проверку достоверности посредством сети 160 обработки платежей в ходе обработки авторизации, чтобы предоставлять дополнительный уровень аутентификации для транзакции, посредством указания того, что транзакция ранее проанализирована и аутентифицирована посредством сетевого компьютера процессора обслуживания платежей и не изменена.

[0175] На этапе 913, модуль 161(C) обработки транзакций шифрует платежную информацию с использованием идентифицированного открытого ключа шифрования продавца, который зарегистрирован и сохраняется в сети 160 обработки платежей.

[0176] На этапе 914, интерфейс 161(E) мобильного шлюза компьютера 161 сети обработки платежей отправляет ответ по осуществлению платежа, включающий в себя зашифрованную платежную информацию, в мобильное платежное приложение 123 мобильного устройства 120 с использованием защищенного канала. Мобильное платежное приложение 123 не может осуществлять доступ к зашифрованной платежной информации, поскольку мобильное платежное приложение 123 не имеет доступа к закрытому ключу продавца.

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

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

[0179] На этапе 917, приложение 121 продавца принимает ответ по осуществлению платежа, включающий в себя зашифрованную платежную информацию, и перенаправляет зашифрованную платежную информацию в серверный компьютер продавца.

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

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

[0182] На этапе 920, сообщение с запросом на авторизацию может отправляться в компьютер 150 эквайера, ассоциированный с компьютером 130 продавца, и компьютер 150 эквайера может маршрутизировать сообщение с запросом на авторизацию в сеть обработки платежей, ассоциированную с идентификатором эмитента (например, BIN) или идентификатором счета (например, первичным идентификатором счета), предоставленным в сообщении с запросом на авторизацию.

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

[0184] На этапе 922, сеть 160 обработки платежей перенаправляет сообщение с запросом на авторизацию в компьютер 170 эмитента, ассоциированный со счетом потребителя.

[0185] На этапе 923, компьютер 170 эмитента может выполнять процесс принятия решений на основе оценки рисков и авторизации, при котором компьютер 170 эмитента может синтаксически анализировать релевантную информацию из сообщения с запросом на авторизацию, включающего в себя значение ответа по аутентификации, любую информацию проверки достоверности из сети 160 обработки платежей, связанную с транзакцией (например, бальную оценку риска, результаты других процессов аутентификации и т.д.), и может принимать решение относительно того, авторизуется или нет транзакция. Хотя не показано в фиг. 9, компьютер 170 эмитента затем может формировать и возвращать сообщение с ответом по авторизации, включающее в себя индикатор в отношении того, авторизуется или нет транзакция, обратно через платежную сеть и в конечном счете в компьютер 130 продавца и потребителя 110 (через мобильное устройство 120) в отношении того, авторизуется и успешно завершается транзакция или нет.

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

[0186] Дополнительно, некоторые варианты осуществления настоящего изобретения могут включать в себя стороннего поставщика услуг (например, поставщика мобильных кошельков, поставщика услуг сети мобильной связи, производителя устройств и т.д.) со взаимосвязью с потребителем 1010, предоставляющего признаки безопасности удаленного диспетчера 140 ключей, описанного в связи с фиг. 1. Сторонний поставщик услуг может инициализировать приложение 1025 для проведения защищенных удаленных транзакций в защищенном элементе 1022 и использовать приложение 1025 для проведения удаленных транзакций, чтобы получать платежные учетные данные из мобильного платежного приложения 1023, дешифровать платежную информацию, принимаемую из мобильного платежного приложения 1023, и шифровать платежную информацию для доставки в сторонний серверный компьютер.

[0187] Фиг. 10 показывает блок-схему примерной системы для обработки удаленной транзакции с использованием стороннего поставщика услуг (например, поставщика мобильных кошельков) и приложения 1021 продавца мобильного устройства 1020, согласно некоторым вариантам осуществления изобретения. Система является аналогичной фиг. 1 и 7, и существенные отличия подробнее поясняются ниже.

[0188] Варианты осуществления, показанные на фиг. 10, включают в себя дополнительные конфигурационные параметры для системы обработки удаленных транзакций, включающие в себя использование маркеров для того, чтобы идентифицировать счет потребителя 1010, и использование зарегистрированных ключей продавцов, причем сторонний поставщик 1040 услуг представляет собой поставщика мобильных кошельков. Конфигурация по фиг. 10 является только иллюстративной, и различные стороны и использование маркеров могут использоваться в любой из систем, описанных выше.

[0189] Как показано на фиг. 10, сеть 1060 обработки платежей также может функционально соединяться или включаться в реестр 1061 маркеров. Реестр 1061 маркеров может включать в себя любую базу данных или другое запоминающее устройство, в котором маркеры могут быть выданы в мобильное устройство 1020 и ассоциированы со счетами эмитентов, так что транзакции могут обрабатываться с использованием маркеров вместо первичных номеров/идентификаторов счетов (PAN).

[0190] Мобильное устройство 1020 может содержать приложение 1021 продавца, SDK 1024 для проведения удаленных транзакций, API или другой уровень предоставления сторонних услуг, который может быть включен в приложение 1021 продавца для того, чтобы обеспечивать возможность приложению 1021 продавца взаимодействовать с приложением 1025 для проведения удаленных транзакций, сохраненным в защищенном элементе 1022, приложением 1025 для проведения удаленных транзакций, установленным в защищенном элементе 1022 мобильного устройства 1020, и мобильным платежным приложением 1023, сохраненным в защищенном элементе 1022 мобильного устройства 1020.

[0191] SDK 1024 для проведения удаленных транзакций или уровень предоставления сторонних услуг может включать в себя любой API, приложение, апплет или другой исполняемый код, подходящий для того, чтобы взаимодействовать с защищенным приложением и/или сторонней серверной системой (например, поставщиком мобильных кошельков, удаленным диспетчером ключей и т.д.). Например, SDK 1024 для проведения удаленных транзакций может встраиваться в приложение 1021 продавца и может использоваться посредством приложения 1021 продавца для того, чтобы извлекать платежную информацию из приложения 1025 для проведения защищенных удаленных транзакций в защищенном элементе 1022, чтобы взаимодействовать с мобильным платежным приложением 1023, инициализированным в защищенном элементе 1022, обмениваться данными с приложением 1021 продавца и обмениваться данными со сторонней системой. В некоторых вариантах осуществления, SDK 1024 для проведения удаленных транзакций или уровень предоставления сторонних услуг может быть защищен и встроен в защищенный элемент 1022. Дополнительно, хотя SDK 1024 для проведения удаленных транзакций показан как часть приложения 1021 продавца, SDK 1024 для проведения удаленных транзакций также может представлять собой независимое приложение или может быть встроен в операционную систему мобильного устройства 1020.

[0192] Приложение 1025 для проведения удаленных транзакций включает в себя защищенное приложение, инициализированное в защищенном элементе 1022 мобильного устройства 1020. Приложение 1025 для проведения удаленных транзакций предоставляет защищенную область для хранения сертификата открытых ключей и/или открытого ключа для системы стороннего поставщика услуг (например, поставщика мобильных кошельков). Дополнительно, приложение 1025 для проведения удаленных транзакций может предоставлять верификацию управления доступом к мобильному платежному приложению 1023 (например, предоставляет функции обеспечения безопасности для мобильного платежного приложения 1023) посредством предоставления доступа к мобильному платежному приложению 1023 только тогда, когда потребитель 1010 предоставляет защищенные учетные данные или иным образом аутентифицируется. Например, если подпись не может проходить проверку достоверности, или если сертификат не согласуется с центром 180 сертификации, приложение 1025 для проведения удаленных транзакций может отклонять запрос на удаленную транзакцию из приложения 1021 продавца, и обработка транзакций может завершаться (и потребителю 1010 может указываться пробовать другой способ оплаты или пробовать еще раз). Альтернативно, если сертификат является допустимым, приложение 1025 для проведения удаленных транзакций может передавать запрос на платежную информацию в мобильное платежное приложение 1023.

[0193] Система стороннего поставщика услуг (например, поставщик 1030 мобильных кошельков) может включать в себя любой объект, который имеет интерес или взаимосвязь с потребителем 1010, мобильным устройством 1020, продавцами, сетью 1060 обработки платежей или любыми другими способами или системами обработки платежных транзакций. Например, система стороннего поставщика услуг может содержать поставщика мобильных кошельков, производителя мобильных устройств, оператора сети мобильной связи или любой другой объект, который может взаимодействовать с продавцами и потребительскими устройствами. Соответственно, варианты осуществления настоящего изобретения могут предоставлять возможность системе стороннего поставщика услуг регистрировать продавцов и управлять процессами аутентификации для удаленных транзакций продавца для того, чтобы предоставлять более защищенную обработку удаленных транзакций.

[0194] Зарегистрированные ключи поставщика мобильных кошельков могут включать в себя любые открытые ключи шифрования, используемые для того, чтобы шифровать платежную информацию при обработке удаленной транзакции. Например, в то время как продавцы адаптируются в системе или регистрируются в услуге обработки удаленных платежных транзакций, предоставляемой посредством поставщика мобильных кошельков, продавец может отправлять сертификат открытых ключей поставщика мобильных кошельков и/или сертификат открытых ключей, который поставщик мобильных кошельков может использовать для того, чтобы шифровать платежную информацию перед отправкой в серверный компьютер продавца, так что компьютер 1030 продавца допускает дешифрование платежной информации. Хотя не показано на фиг. 10-11, поставщик мобильных кошельков (или другая третья сторона) также может использовать варианты осуществления, в которых ключи определяются с помощью сертификатов открытых ключей, как описано в отношении фиг. 1-6.

[0195] Фиг. 11 показывает блок-схему последовательности операций примерного способа 1100 для обработки удаленной транзакции с использованием стороннего поставщика услуг (например, поставщика мобильных кошельков) и приложения 1021 продавца мобильного устройства 1020, согласно некоторым вариантам осуществления изобретения.

[0196] На этапе 1101, потребитель 1010 завершает покупки через приложение 1021 продавца, которое обменивается данными с онлайновым магазином или магазином на базе электронной коммерции продавца. Когда потребитель 1010 подготовлен к тому, чтобы рассчитываться за свои покупки и заканчивать приобретение, потребитель 1010 может регистрироваться в стороннем апплете или приложении 1025 для проведения удаленных транзакций либо в уровне предоставления услуг, присутствующем на мобильном устройстве 1020, с использованием сторонних учетных данных (например, поставщика мобильных кошельков). Потребитель 1010 затем может инициировать расчет через приложение 1021 продавца. Приложение 1021 продавца может предоставлять вариант выбирать платежную карту или счет на оплату через приложение 1025 для проведения удаленных транзакций. Потребитель 1010 может выбирать счет для того, чтобы инициировать оплату.

[0197] На этапе 1102, приложение 1021 продавца отправляет информацию получателя платежа в приложение 1025 для проведения удаленных транзакций с использованием комплекта разработки программного обеспечения (SDK) для проведения удаленных транзакций или другого уровня предоставления сторонних услуг либо приложения, расположенного на мобильном устройстве 1020. В одном варианте осуществления, SDK 1024 для проведения удаленных транзакций или приложение 1025 для проведения удаленных транзакций может включать в себя уровень предоставления услуг, который выполнен с возможностью взаимодействовать между приложением 1021 продавца и апплетом 1024 для проведения удаленных транзакций, сохраненным в защищенном элементе 1022 мобильного устройства 1020. Альтернативно, приложение 1025 для проведения удаленных транзакций также может сохраняться в запоминающем устройстве общего назначения мобильного устройства 1020 и может быть выполнено с возможностью обмениваться данными со сторонней серверной платформой 1030 (например, поставщиком мобильных кошельков). В любом случае, приложение 1025 для проведения удаленных транзакций может быть выполнено с возможностью обмениваться данными с мобильным платежным приложением 1023 (например, приложением Visa™ Paywave™), которое сохраняется в защищенном элементе 1022 мобильного устройства 1020.

[0198] На этапе 1103, SDK 1024 для проведения удаленных транзакций или приложение 1025 для проведения удаленных транзакций передает информацию получателя платежа, причем приложение 1025 для проведения удаленных транзакций постоянно размещается в защищенном элементе 1022. Приложение 1025 для проведения удаленных транзакций затем может использовать API или другие команды, чтобы запрашивать то, что мобильное платежное приложение 1023 (например, приложение Visa™ Paywave™) должно предоставлять инициализированные платежные учетные данные (например, платежный маркер, первичный номер счета (PAN), псевдо-PAN, фантомный PAN, дату истечения срока действия и т.д.), которые сохраняются в защищенном элементе 1022 защищенным способом.

[0199] На этапе 1104, мобильное платежное приложение 1023 может использовать принимаемую информацию получателя платежа для того, чтобы извлекать и формировать платежную информацию с использованием защищенного элемента 1022. Например, мобильное платежное приложение 1023 может осуществлять доступ к информации маркера из защищенного элемента 1022 и формировать рабочие данные запроса на осуществление платежа (включающие в себя элементы данных на основе маркеров) и динамическое значение (например, значение аутентификации) с использованием информации получателя платежа, маркера и информации, ассоциированной с маркером (например, даты истечения срока действия маркера). Например, платежная информация может включать в себя маркер (или PAN, псевдо-PAN, замену PAN и т.д.), дату истечения срока действия маркера, уникальный идентификатор транзакции (например, одноразовый номер), аутентификационные данные на основе маркеров (например, динамическое значение или криптограмму, к примеру, CAVV, dCVV и т.д.) и индикатор аутентификации и/или уровня безопасности (например, значение ECI5). Платежная информация дополнительно может включать в себя любую информацию транзакции, которая может быть полезной при обработке транзакции (например, сумму, идентификатор продавца и т.д.).

[0200] Маркер может включать в себя любые платежные учетные данные, которые выданы или известны в реестре 1061 маркеров, соединенном с сетью 1060 обработки платежей или другим платежным объектом. Маркер может представлять собой замену PAN, так что маркер может иметь формат, идентичный формату типичного первичного номера счета (PAN), и обрабатываться через существующую инфраструктуру обработки платежей. Альтернативно, маркер может иметь любой другой возможный формат, так что он ассоциирован с PAN или другим идентификатором счета в реестре 161 маркеров. Варианты осуществления настоящего изобретения могут предоставлять маркер, который может сохраняться в защищенном элементе 1022 и использоваться для транзакций, инициируемых с использованием мобильного платежного приложения 1023, которое должно использоваться в удаленных платежных транзакциях.

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

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

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

[0204] Дополнительно, на этапе 1104, мобильное платежное приложение 1023 может использовать сторонний открытый ключ шифрования, чтобы шифровать рабочие данные запроса на удаленную транзакцию, включающие в себя маркер, аутентификационные данные на основе маркеров и другие данные транзакции. В некоторых вариантах осуществления, мобильное платежное приложение 1023 может определять сторонний открытый ключ с использованием стороннего сертификата, сохраненного на мобильном устройстве 1020, или может осуществлять доступ к стороннему открытому ключу через центр 180 сертификации или другую базу данных. Открытый ключ может быть инициализирован в защищенном элементе 1022 мобильного платежного приложения, и мобильное платежное приложение 1023 может иметь доступ к стороннему открытому ключу. Альтернативно или в комбинации, мобильное платежное приложение 1023 может иметь ключ шифрования (симметричный или открытый ключ из пары открытого/закрытого ключа), ассоциированный с приложением 1025 для проведения удаленных транзакций, инициализированным в защищенном элементе 1022, и шифровать платежную информацию с использованием инициализированного ключа. Альтернативно, поскольку как мобильное платежное приложение 1023, так и приложение 1025 для проведения удаленных транзакций работают в защищенном элементе 1022, мобильное платежное приложение 1023 может передавать платежную информацию в незашифрованном формате, так что ключи шифрования не требуются.

[0205] На этапе 1105, мобильное платежное приложение 1023 отправляет платежную информацию (зашифрованную или нет) в приложение 1025 для проведения удаленных транзакций.

[0206] На этапе 1106, приложение 1025 для проведения удаленных транзакций может определять то, шифруется или нет платежная информация, и если да, может получать ключ шифрования для дешифрования зашифрованной платежной информации. Ключ шифрования приложения для проведения удаленных транзакций может включать в себя любой подходящий ключ шифрования на основе ключа, инициализированного или используемого посредством мобильного платежного приложения 1023, чтобы шифровать платежную информацию. Ключ может представлять собой симметричный или закрытый ключ, ассоциированный с открытым ключом, используемым для того, чтобы шифровать платежную информацию из мобильного платежного приложения 1023. В любом случае, приложение 1025 для проведения удаленных транзакций дешифрует зашифрованную платежную информацию (если она шифруется) и получает платежную информацию, включающую в себя платежные учетные данные. Дополнительно, приложение 1025 для проведения удаленных транзакций может повторно шифровать дешифрованную платежную информацию с открытым ключом шифрования стороннего серверного компьютера (например, ключом шифрования компьютера поставщика мобильных кошельков) таким образом, что конфиденциальная платежная информация может защищенно отправляться поставщику мобильных кошельков. Приложение 1025 для проведения удаленных транзакций может иметь сторонний открытый ключ шифрования, инициализированный в защищенном элементе 1022, либо может использовать сертификат открытых ключей или другую информацию для того, чтобы получать корректный ключ шифрования. Соответственно, платежная информация может шифроваться с открытым ключом стороннего серверного компьютера (например, открытым ключом поставщика мобильных кошельков), и зашифрованная платежная информация может отправляться в серверный компьютер стороннего поставщика услуг (например, поставщик мобильных кошельков) для дополнительной обработки удаленных транзакций.

[0207] На этапе 1107, зашифрованная платежная информация затем может отправляться в SDK 1024 для проведения удаленных транзакций или другое приложение 1025 для проведения удаленных транзакций на мобильном устройстве 1020, которое допускает передачу зашифрованной платежной информации в стороннюю серверную платформу. SDK 1024 для проведения удаленных транзакций затем может отправлять зашифрованную платежную информацию в стороннюю серверную платформу 130. Следует отметить, что поскольку сторонний закрытый ключ неизвестен посредством SDK 1024 для проведения удаленных транзакций, приложения 1021 продавца, приложения 1025 для проведения удаленных транзакций, мобильного платежного приложения 1023 либо любого другого приложения или программы, расположенной на мобильном устройстве 1020, зашифрованная платежная информация не может быть расшифрована посредством каких-либо программ на мобильном устройстве 1020.

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

[0209] Сторонняя серверная система 130 затем может определять соответствующего продавца, ассоциированного с идентификатором продавца. Идентификатор продавца может быть уникальным для сторонней серверной системы 130 и может включать в себя любую информацию, которая идентифицирует продавца, ассоциированного с приложением 1021 продавца, которое первоначально формирует информацию получателя платежа. Продавцы могут регистрировать или иным образом завершать процесс "адаптации" продавца в сторонней серверной системе 130, с тем чтобы включаться в способы обработки платежей на базе электронной коммерции с усиленной аутентификацией. Соответственно, процесс адаптации в системе или регистрации может выполняться между продавцом и сторонней серверной системой 130 до выполнения всех транзакций, и продавец может предоставлять ориентированные на продавца открытые ключи и другую регистрационную информацию (например, адрес продавца и т.д.) в стороннюю систему в это время. Соответственно, когда сторонняя серверная система 130 дешифрует платежную информацию и определяет то, что идентификатор продавца, ассоциированный с конкретным продавцом, включен, сторонняя серверная система 130 может определять открытый ключ продавца, ассоциированный с идентифицированным продавцом.

[0210] На этапе 1110, компьютер 130 поставщика мобильных кошельков может использовать определенный открытый ключ продавца для того, чтобы повторно шифровать платежную информацию с использованием открытого ключа продавца, который сохранен на компьютере 130 поставщика мобильных кошельков в ходе адаптации в системе, либо в некоторых вариантах осуществления, может быть включен вместе с платежной информацией, принимаемой из SDK 1024 для проведения удаленных транзакций или стороннего приложения 1025 для проведения удаленных транзакций, в котором открытый ключ включен в сертификат продавца.

[0211] На этапах 1111, компьютер 130 поставщика мобильных кошельков затем может отправлять повторно зашифрованную платежную информацию, которая зашифрована с использованием открытого ключа продавца, в систему продавца. Зашифрованная платежная информация с ключом продавца может отправляться продавцу через любой подходящий способ. Например, компьютер 130 поставщика мобильных кошельков может отправлять повторно зашифрованную платежную информацию в SDK 1024 для проведения удаленных транзакций или приложение уровня стороннего сервера (этап 1111), которое затем перенаправляет повторно зашифрованную платежную информацию в приложение 1021 продавца (этап 1112), которое затем может перенаправлять повторно зашифрованную платежную информацию в систему продавца (этап 1113). Альтернативно, компьютер 130 поставщика мобильных кошельков может отправлять повторно зашифрованную платежную информацию непосредственно в систему продавца (не показана) или может отправлять повторно зашифрованную платежную информацию через другую третью сторону перед передачей в систему продавца (не показана).

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

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

[0214] На этапе 1115, компьютер 1050 эквайера определяет надлежащую сеть 1060 обработки платежей и перенаправляет сообщение с запросом на авторизацию в сеть 1060 обработки платежей.

[0215] На этапе 1116, сеть 1060 обработки платежей может определять то, что маркер должен быть заменен на PAN или другой идентификатор счета в реестре 1061 маркеров, и то, что аутентификационные данные на основе маркеров должны формироваться с использованием маркера, чтобы обеспечивать то, что данные совпадают и в силу этого проходят проверку достоверности как исходящие из легитимного инициализированного мобильного платежного приложения 1023, сохраненного в защищенном элементе 1022. Сеть 1060 обработки платежей может использовать любой подходящий способ, чтобы определять то, что платежные учетные данные включают в себя маркер. Например, динамическое значение (например, значение аутентификации на основе маркеров) может сигнализировать в сеть 1060 обработки платежей то, что транзакция включает в себя маркер. Любая другая подходящая информация может быть включена, чтобы информировать сеть 1060 обработки платежей касательно того, что платежные учетные данные включают в себя информацию маркера.

[0216] На этапе 1117, реестр 1061 маркеров определяет идентификатор счета и другую информацию счета, ассоциированную с маркером в сообщении с запросом на авторизацию, и отправляет обновленное сообщение с запросом на авторизацию, включающее в себя идентификатор счета, в сеть 1060 обработки платежей.

[0217] На этапе 1118, сеть 1060 обработки платежей перенаправляет обновленное сообщение с запросом на авторизацию эмитенту для принятия решений на основе рисков и авторизации. Как пояснено выше в отношении этапа 922, если эмитент авторизует транзакцию, эмитент может формировать сообщение с ответом по авторизации, которое может передаваться обратно продавцу и/или в мобильное устройство 1020 для завершения транзакции. Дополнительно, реестр 1061 маркеров может заменять идентификатор счета маркером в сообщении на ответ по авторизации.

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

Примерные способы криптографии в эллиптических кривых

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

[0220] Например, как пояснено выше в отношении этапов 1104-1108, мобильное платежное приложение 1023 может получать платежные учетные данные из защищенного элемента 1022, может шифровать платежные учетные данные и может отправлять зашифрованную платежную информацию в компьютер поставщика мобильных кошельков. Компьютер поставщика мобильных кошельков затем может использовать закрытый ключ, чтобы дешифровать зашифрованную платежную информацию. В некоторых вариантах осуществления, мобильное платежное приложение 1023 и компьютер поставщика мобильных кошельков могут использовать криптографию в эллиптических кривых (ECC) для того, чтобы шифровать и дешифровать платежную информацию, соответственно. Чтобы использовать криптографию в эллиптических кривых, мобильное платежное приложение 1023 и серверный компьютер могут иметь функцию аутентификации совместно используемых сообщений и функцию извлечения совместно используемых ключей.

[0221] "Функция извлечения ключа" может включать в себя любую функцию или операцию, применимую, чтобы определять один или более секретных ключей, таких как симметричные ключи или ключи кода аутентификации сообщений (MAC) либо иные известные в данной области техники. Один пример KDF может включать в себя ANSI-X9.63-KDF с SHA-1-вариантом.

[0222] На этапе 1201, мобильное платежное приложение 1023 извлекает открытый ключ сервера, ассоциированный со сторонней компьютерной системой. Открытый ключ стороннего компьютера может быть извлечен любым подходящим способом. Например, открытый ключ сервера может быть включен в сертификат, сохраненный на мобильном устройстве 1020, или может постоянно размещаться в хранилище приложений или в защищенной области хранения, ассоциированной с мобильным платежным приложением 1023. Сторонняя серверная система может сохранять закрытый ключ сервера, соответствующий открытому ключу сервера.

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

[0224] На этапе 1203, мобильное платежное приложение 1023 извлекает эллиптическую кривую и функцию-генератор (например, P256), которая должна использоваться в процессе шифрования. Эллиптическая кривая и функция-генератор также известны посредством сторонней серверной системы.

[0225] На этапе 1204, мобильное платежное приложение 1023 формирует случайную эфемерную пару ключей в эллиптических кривых (EC), ассоциированную с платежной транзакцией. Пара ключей может содержать закрытый ключ транзакции и открытый ключ транзакции.

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

[0227] На этапе 1206, мобильное платежное приложение 1023 отправляет зашифрованный маркер и открытый ключ транзакции в стороннюю серверную систему.

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

[0229] Фиг. 13 показывает другой способ для шифрования платежного маркера с использованием ECC в мобильном платежном приложении 1023 и последующего дешифрования маркера в сторонней серверной системе. Этапы 1301-1303 являются идентичными этапам, описанным выше в связи с этапами 1201-1204 по фиг. 13, и включают в себя извлечение посредством мобильного платежного приложения 1023 открытого ключа стороннего серверного компьютера, ассоциированного с компьютером 1040 поставщика мобильных кошельков, функции извлечения ключа (KDF), эллиптической кривой (например, P256) и функции-генератора, которая должна использоваться в процессе шифрования.

[0230] На этапе 1304, мобильное платежное приложение 1023 формирует случайную эфемерную пару ключей в эллиптических кривых (EC), ассоциированную с платежной транзакцией. Пара ключей может содержать закрытый ключ транзакции и открытый ключ транзакции. В варианте осуществления по фиг. 13, пара ключей может формироваться таким образом, что открытый ключ транзакции равен закрытому ключу транзакции, умноженному на функцию-генератор.

[0231] На этапе 1305, мобильное платежное приложение 1023 формирует совместно используемый секрет с использованием произведения открытого ключа сервера и закрытого ключа транзакции. Следует отметить, что совместно используемый секрет также равен произведению закрытого ключа сервера, функции-генератора и закрытого ключа транзакции. Аналогично, совместно используемый секрет также равен произведению закрытого ключа сервера и открытого ключа транзакции.

[0232] На этапе 1306, мобильное платежное приложение 1023 формирует симметричный ключ и ключ кода аутентификации сообщений (MAC) с использованием совместно используемого секрета, определенного на этапе 1305, и KDF, определенной на этапе 1303. Симметричный ключ, например, может представлять собой ключ AES-шифрования. MAC-ключ, например, может представлять собой ключ, используемый для того, чтобы формировать хэш-код аутентификации сообщений (HMAC).

[0233] На этапе 1307, мобильное платежное приложение 1023 формирует зашифрованный шифрованный текст, содержащий платежный маркер. В некоторых вариантах осуществления, шифрованный текст может формироваться с использованием симметричного ключа, определенного на этапе 1306. Шифрованный текст содержит зашифрованный платежный маркер и является нечитаемым без симметричного ключа.

[0234] На этапе 1308, мобильное платежное приложение 1023 вычисляет код аутентификации сообщений (MAC) для зашифрованного маркера. MAC может формироваться с использованием MAC-ключа, определенного на этапе 1306, и любой подходящей MAC-функции, такой как HMAC-SHA-256. MAC может формироваться для того, чтобы верифицировать то, что зашифрованный маркер не модифицирован во время передачи.

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

[0236] На этапе 1310, сторонняя серверная система определяет совместно используемый секрет с использованием произведения закрытого ключа сервера и открытого ключа транзакции, принимаемого на этапе 13. Следует отметить, что хотя совместно используемый секрет вычислен с использованием различных ключей, он является идентичным совместно используемому секрету, вычисленному посредством мобильного платежного приложения 1023 на этапе 1305.

[0237] На этапе 1311, сторонняя серверная система формирует симметричный ключ и ключ кода аутентификации сообщений (MAC) с использованием совместно используемого секрета, определенного на этапе 1305, и KDF, определенной на этапе 1303. Следует отметить, что поскольку совместно используемый секрет и KDF являются идентичными совместно используемому секрету и KDF, используемым посредством мобильного платежного приложения 1023, симметричный ключ и MAC-ключ являются идентичными симметричному ключу и MAC-ключу, используемым для того, чтобы формировать зашифрованный маркер и MAC, принимаемый посредством сторонней серверной системы на этапе 1309.

[0238] На этапе 1312, сторонняя серверная система вычисляет MAC принимаемого зашифрованного маркера с использованием MAC-ключа, определенного на этапе 1306. Если вычисленный MAC не совпадает с MAC, принимаемым на этапе 1309, определяется повреждение зашифрованного маркера, и способ приводит к ошибке. Это может инструктировать, например, сторонней серверной системе запрашивать повторную передачу зашифрованного маркера. Если вычисленный MAC и принимаемый MAC совпадают, то способ переходит к этапу 1313.

[0239] На этапе 1313, сторонняя серверная система дешифрует зашифрованный маркер с использованием симметричного ключа, определенного на этапе 1311. Дешифрованный платежный маркер затем может обрабатываться посредством сторонней серверной системы.

Примерное компьютерное устройство

[0240] Фиг. 14 является блок-схемой высокого уровня компьютерной системы, которая может использоваться для того, чтобы реализовывать любой из объектов или компонентов, описанных выше. Подсистемы, показанные на фиг. 14, соединяются через системную шину 1475. Дополнительные подсистемы включают в себя принтер 1403, клавиатуру 1406, жесткий диск 1407 и монитор 1409, который соединяется с адаптером 1404 дисплея. Периферийные устройства и устройства ввода-вывода, которые соединяются с контроллером 1400 ввода-вывода, могут подключаться к компьютерной системе посредством любого числа средств, известных в данной области техники, таких как последовательный порт. Например, последовательный порт 1405 или внешний интерфейс 1408 может использоваться для того, чтобы подключать компьютерное устройство к глобальной вычислительной сети, такой как Интернет, устройству ввода "мышь" или сканера. Соединение через системную шину 1475 обеспечивает возможность центральному процессору 1402 обмениваться данными с каждой подсистемой и управлять выполнением инструкций из системного запоминающего устройства 1401 или жесткого диска 1407, а также обменом информацией между подсистемами. Системное запоминающее устройство 1401 и/или жесткий диск может осуществлять компьютерно-читаемый носитель.

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

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

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

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

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

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


ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
ОБРАБОТКА ЗАЩИЩЕННЫХ УДАЛЕННЫХ ПЛАТЕЖНЫХ ТРАНЗАКЦИЙ
Источник поступления информации: Роспатент

Показаны записи 1-10 из 56.
10.12.2013
№216.012.8a4a

Проверка подлинности портативных потребительских устройств

Изобретение относится к вычислительной технике. Технический результат заключается в повышении безопасности данных. Способ предоставления значения проверки подлинности устройства для портативного потребительского устройства содержит: прием, на сервере, запроса значения проверки подлинности...
Тип: Изобретение
Номер охранного документа: 0002501084
Дата охранного документа: 10.12.2013
27.01.2014
№216.012.9cd7

Архитектура приложения мобильных платежей

Изобретение относится к устройству и способу выполнения платежной транзакции. Технический результат заключается в повышении безопасности выполнения платежных транзакций на множестве платформ мобильных устройств при взаимодействии с платежным приложением, с возможностью его обновления....
Тип: Изобретение
Номер охранного документа: 0002505857
Дата охранного документа: 27.01.2014
10.03.2014
№216.012.aa7f

Прогнозирование и обработка транзакций на основе частоты

Изобретение относится к средствам для отслеживания и анализа данных потребительской активности. Техническим результатом является повышение эффективности и надежности при обработке транзакции за счет проверки ее на предмет мошенничества. Способ осуществляет отслеживание данных событий,...
Тип: Изобретение
Номер охранного документа: 0002509362
Дата охранного документа: 10.03.2014
10.06.2014
№216.012.cead

Верификация портативных потребительских устройств

Изобретение относится к области верификации портативных потребительских устройств. Техническим результатом является повышение безопасности проведения финансовых транзакций при использовании портативных потребительских устройств (например, кредитной карты). Маркер верификации соединяется с...
Тип: Изобретение
Номер охранного документа: 0002518680
Дата охранного документа: 10.06.2014
10.06.2014
№216.012.cfa8

Система и способ для обработки чеков платежей по платежным транзакциям

Изобретение относится к способам и серверному компьютеру обработки электронных чеков платежей. Технический результат заключается в повышении эффективности выполнения электронных платежных транзакций. Серверный компьютер содержит модуль регистрации, имеющий регистрационную информацию,...
Тип: Изобретение
Номер охранного документа: 0002518931
Дата охранного документа: 10.06.2014
10.04.2015
№216.013.3f05

Обработка переключения шифрования

Изобретение относится к системе и способу обработки транзакций. Технический результат заключается в повышении безопасности финансовых транзакций. Способ содержит этапы, на которых принимают на серверном компьютере из терминала конверт, связанный с транзакцией, причем конверт включает в себя...
Тип: Изобретение
Номер охранного документа: 0002547621
Дата охранного документа: 10.04.2015
27.06.2015
№216.013.59cc

Активация услуги с использованием алгоритмически заданного ключа

Изобретение относится к области активации услуг с использованием алгоритмически заданных ключей. Технический результат - предотвращение нарушения безопасности системы обработки данных. Способ подписки пользователя на услугу содержит: идентификацию в компьютере эмитента пользователя, который...
Тип: Изобретение
Номер охранного документа: 0002554529
Дата охранного документа: 27.06.2015
10.07.2015
№216.013.614f

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

Изобретение относится к устройству, способам и компьютеру для аутентификации потребителя и проведения платежной транзакции. Технический результат заключается в повышении скорости проведения платежной транзакции. Устройство содержит процессор, носитель данных, присоединенный к процессору и...
Тип: Изобретение
Номер охранного документа: 0002556453
Дата охранного документа: 10.07.2015
10.09.2015
№216.013.786b

Беспроводное управление прикладной программой оплаты, установленной в мобильном устройстве

Изобретение относится к области управления прикладной программой оплаты, установленной на мобильном устройстве, таком как мобильный телефон. Техническим результатом является обеспечение защиты от мошеннического использования прикладной программы оплаты в ситуациях, в которых мобильное...
Тип: Изобретение
Номер охранного документа: 0002562416
Дата охранного документа: 10.09.2015
20.09.2015
№216.013.7b4e

Обработка аутентификации удаленной переменной

Изобретение относится к средствам обработки аутентификации удаленной переменной. Технический результат повышает защищенность данных в каналах аутентификации. Субъект-отправитель инициирует по каналу инициирования удаленный платеж с использованием альтернативного имени. Альтернативное имя может...
Тип: Изобретение
Номер охранного документа: 0002563163
Дата охранного документа: 20.09.2015
Показаны записи 1-10 из 12.
27.01.2014
№216.012.9cd7

Архитектура приложения мобильных платежей

Изобретение относится к устройству и способу выполнения платежной транзакции. Технический результат заключается в повышении безопасности выполнения платежных транзакций на множестве платформ мобильных устройств при взаимодействии с платежным приложением, с возможностью его обновления....
Тип: Изобретение
Номер охранного документа: 0002505857
Дата охранного документа: 27.01.2014
10.09.2015
№216.013.786b

Беспроводное управление прикладной программой оплаты, установленной в мобильном устройстве

Изобретение относится к области управления прикладной программой оплаты, установленной на мобильном устройстве, таком как мобильный телефон. Техническим результатом является обеспечение защиты от мошеннического использования прикладной программы оплаты в ситуациях, в которых мобильное...
Тип: Изобретение
Номер охранного документа: 0002562416
Дата охранного документа: 10.09.2015
10.04.2016
№216.015.300c

Взаимная мобильная аутентификация с использованием центра управления ключами

Изобретение относится к области аутентификации. Технический результат - обеспечение безопасности связи. Способ аутентификации, содержащий этапы, на которых: отправляют сообщение вызова с мобильного шлюза на потребительское устройство, причем сообщение вызова отправляется в ответ на сообщение...
Тип: Изобретение
Номер охранного документа: 0002580809
Дата охранного документа: 10.04.2016
27.08.2016
№216.015.5022

Передача сообщений общего назначения

Изобретение относится к системам и способам, позволяющим субъектам, таким как эмитенты, торговцы, сети обработки платежей и операторы мобильных сетей, отправлять связанные со счетом сообщения и маркетинговые сообщения на мобильное устройство пользователя в ответ на запрос сообщений,...
Тип: Изобретение
Номер охранного документа: 0002595957
Дата охранного документа: 27.08.2016
12.01.2017
№217.015.63f5

Доверенный внутренний интерфейс

Изобретение относится к способам для проведения транзакции. Технический результат заключается в повышении быстродействия проведения транзакций за счет обеспечения возможности связи и передачи данных между приложениями, установленными в платежном устройстве. В способе выполняют прием в платежном...
Тип: Изобретение
Номер охранного документа: 0002589373
Дата охранного документа: 10.07.2016
19.01.2018
№218.016.09a5

Защита данных с переводом

Изобретение относится к области шифрования данных. Технический результат - обеспечивают механизм для передачи и маршрутизации зашифрованного идентификатора/номера счета через сеть обработки без необходимости обновления существующей инфраструктуры маршрутизации для обработки зашифрованных...
Тип: Изобретение
Номер охранного документа: 0002631983
Дата охранного документа: 29.09.2017
09.08.2018
№218.016.7890

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

Изобретение относится к способу, серверному компьютеру и системе для обработки удаленной транзакции. Технический результат заключается в обеспечении обработки удаленной транзакции. В способе принимают запрос на осуществление платежа, содержащий платежную информацию, зашифрованную с...
Тип: Изобретение
Номер охранного документа: 0002663476
Дата охранного документа: 06.08.2018
11.10.2018
№218.016.9025

Системы и способы для функционально совместимой обработки сетевых маркеров

Изобретение относится к способам, системе и серверам для обработки транзакций. Технический результат заключается в обеспечении безопасности транзакций. В способе принимают сообщение с запросом на авторизацию, содержащее платежный маркер, содержащий идентификатор эмитента платежного маркера,...
Тип: Изобретение
Номер охранного документа: 0002669081
Дата охранного документа: 08.10.2018
08.03.2019
№219.016.d369

Системы и способы для сообщения рисков с использованием данных достоверности маркера

Изобретение относится к средствам по обмену данными по риску с использованием данных достоверности токена. Техническим результатом является повышение достоверности проведения платежей. Серверный компьютер, содержащий соединенные процессор и машиночитаемый носитель, который содержит код,...
Тип: Изобретение
Номер охранного документа: 0002681366
Дата охранного документа: 06.03.2019
27.04.2019
№219.017.3cb1

Способы и системы облачных транзакций

Изобретение относится к области вычислительной техники. Технический результат заключается в улучшении защиты устройства связи при проведении транзакции. Способ содержит этапы, на которых: принимают от удаленного компьютера ключ ограниченного использования (LUK); генерируют посредством...
Тип: Изобретение
Номер охранного документа: 0002686014
Дата охранного документа: 23.04.2019
+ добавить свой РИД