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

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

 

Область техники, к которой относится изобретение

Изобретение относится к установлению связи между устройством-получателем платежей и платежным приложением клиента в защитном элементе, выполненном с возможностью содержания в терминале мобильной связи.

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

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

GlobalPlatform, см. http://www.globalplatform.org на время подачи этой заявки на патент, обеспечивает стандарты и структуры для защитных элементов и приложений на защитных элементах. Защитные элементы обеспечивают одно или более устанавливаемых приложений, таких как платежные приложения. Например, человек может иметь приложение платежной карты VISA и приложение кредитной карты MasterCard, установленные одновременно. Тогда пользователь может производить платеж, например, используя протокол под названием протокол Europay-MasterCard-Visa (Стандарта платежных смарт-карт) (EMV), используя связь ближнего поля (NFC) со считывающим устройством и факультативно с использованием пользовательского интерфейса терминала мобильной связи. Использование мобильных телефонов, способных поддерживать связь ближнего поля (NFC), допускает выполнение бесконтактных платежей в устройстве для производства платежей в месте совершения покупки (PoS), например, с использованием протокола EMV между приложением карты в защитном элементе и терминалом в торговой точке.

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

Раскрытие изобретения

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

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

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

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

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

Идентификатор клиента может содержать телефонный номер, адрес электронной почты или идентификатор доступа к сети.

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

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

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

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

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

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

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

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

Этап установления защищенного канала может содержать прохождение всей связи между устройством-получателем платежей и платежным приложением клиента через сервер безопасности.

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

Идентификатор клиента может содержать телефонный номер, адрес электронной почты или идентификатор доступа к сети.

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

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

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

Первое сообщение может содержать множество идентификаторов приложений, каждый из которых указывает соответствующее одно из множества платежных приложений (5a, 5b) клиента, при этом этап определения содержит определение, какое из множества платежных приложений (5a, 5b) клиента подлежит использованию для производства платежей; и при этом второе сообщение содержит идентификатор платежного приложения (5a, 5b) клиента, подлежащего использованию.

Способ может содержать этап подсказки, содержащий отправку сообщения подсказки на мобильный терминал (10), соответствующий идентификатору клиента, причем подсказка относится к тому, какое платежное приложение клиента подлежит использованию; и приема сообщения от мобильного терминала (10), указывающего, какое из множества платежных приложений (5a, 5b) клиента подлежит использованию.

Первое сообщение может содержать текстовое сообщение; и сообщение подсказки может содержать текстовое сообщение.

Этап определения может содержать считывание базы данных, указывающей, какое из множества платежных приложений (5a, 5b) клиента подлежит использованию.

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

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

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

Идентификатор приложения в первом сообщении может быть таким же, как идентификатор приложения второго сообщения.

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

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

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

Устройство установления канала может быть выполнено с возможностью установления защищенного канала через глобальную сеть с защитным элементом терминала мобильной связи.

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

Идентификатор приложения в первом сообщении может быть таким же, как идентификатор приложения второго сообщения.

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

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

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

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

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

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

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

Следует отметить, что всякий раз, когда в данном описании используется термин «множество», его нужно истолковать как «более одного».

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

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

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

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

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

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

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

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

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

фиг. 4a - схематическое представление, показывающее компоненты аппаратного обеспечения сервера безопасности, показанного на фиг. 1а-1b;

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

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

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

фиг. 7 показывает один пример компьютерного программного продукта 100, содержащего машиночитаемый носитель; и

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

Осуществление изобретения

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

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

Клиент 15 находится в контакте с устройством-получателем 16 платежей через глобальную сеть 14, такую как Интернет. Таким образом, клиент 15 указывает, например, с использованием компьютера 13 или терминала 10 мобильной связи, желание совершить покупку, с продавцом, соответствующим устройству-получателю 16 платежей. Это желание совершить покупку может состоять, например, в том, чтобы купить что-то с помощью интернет-магазина, с помощью телефонного торгового агента или в реальном магазине. В случае реального магазина клиент 15 может, например, получить URI (универсальный индикатор ресурсов) для совершения покупки с использованием NFC или двумерного штрих-кода, при этом тег NFC или двумерный штрих-код может быть расположен на покупаемом продукте. Тогда терминал 10 мобильной связи может установить связь с устройством-получателем 16 платежей, например, как указано обеспеченным URI, с использованием глобальной сети, чтобы указать желание купить рассматриваемый продукт.

Терминал 10 мобильной связи содержит встроенный защитный элемент 12. Терминал 10 мобильной связи может быть любым подходящим портативным мобильным терминалом, таким как мобильный (сотовый) телефон, следующий какому-либо одному или более из стандартов GSM (глобальной системы мобильной связи), UMTS (универсальной системы мобильной связи), W-CDMA (широкополосного множественного доступа с кодовым разделением), CDMA 2000 (множественного доступа с кодовым разделением - 2000), FOMA (свободы доступа к мобильной мультимедийной связи), WiMax/IEEE 802.16 (общемировой совместимости широкополосного беспроводного доступа/IEEE) и/или LTE (долгосрочного развития). В качестве альтернативы или дополнительно, терминал мобильной связи соединен с глобальной сетью 14 с помощью любого подходящего протокола Wi-Fi (беспроводного доступа), например любого из протоколов IEEE 802.llx. Глобальная сеть 14 в этом контексте также включает в себя компоненты, позволяющие терминалу 10 мобильной связи устанавливать связь с глобальной сетью.

Устройство-получатель 16 платежей является любым сервером, подходящим для выполнения способов, как объясняется более подробно ниже. Сервер 18 безопасности соединен с устройством-получателем 16 платежей. Как правило, сервер 18 безопасности соединен со множеством устройств-получателей 16 платежей, при этом каждый продавец или магазин имеет по меньшей мере одно устройство-получатель 16 платежей. Устройство-получатель 16 платежей и сервер безопасности могут быть соединены через глобальную сеть 14 и/или через некоторое другое средство (не показано), такое как прямое соединение локальной сети. Провайдер 19 схемы является объектом общего наблюдения за торговой операцией. Например, провайдером 19 схемы может быть MasterCard, или VISA, или любая другая компания, работающая с кредитными картами.

Когда устройство-получатель 16 платежей и защитный элемент 12 должны находиться в связи, это происходит только через защищенный канал 17a-17b, при этом всей связью по этому защищенному каналу управляет сервер 18 безопасности. Сервер 18 безопасности в свою очередь находится в контакте с терминалом 10 мобильной связи и встроенным защитным элементом 12. Другими словами, вследствие того, что сервер безопасности управляет связью между устройством-получателем 16 платежей и защитным элементом 12, никакая связь между устройством-получателем 16 платежей и защитным элементом 12 не может происходить без одобрения сервера 18 безопасности.

Фиг. 1b является схематическим представлением, иллюстрирующим вторую среду, в которой могут быть применены варианты осуществления изобретения. Основное различие в них заключается в том, что терминал 10 мобильной связи находится в контакте с сервером 18 безопасности некоторым другим способом, отличающимся от соединения через глобальную сеть 14, например через сеть мобильной связи.

Что касается фиг. 1а и 1b, то на них представленный вариант осуществления связан с уплатой со стороны клиента 15 продавцу, выполняемому устройством-получателем 16 платежей. Она производится с использованием приложения платежной карты, выполняющегося на защитном элементе 12, связанном с мобильным телефоном, как объясняется выше. Защитный элемент 12 может быть реализован с использованием карты модуля идентификации абонента (SIM-карты) или универсальной карты с интегральной схемой (UICC), карты памяти (например, SD), вставленной в терминал мобильной связи, или защитный элемент 12 может быть встроен непосредственно в запоминающее устройство терминала мобильной связи.

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

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

Фиг. 2a представляет схему последовательности операций, иллюстрирующую связь в первом варианте осуществления, когда клиент совершает покупку с использованием компонентов, показанных на фиг. 1а-1b.

Клиент 15 сначала указывает 20 на требование произвести платеж устройству-получателю 16 платежей. Это может быть, например, при просмотре интернет-магазина и указании требования уплатить, или при согласии заплатить за услугу или продукт телефонному торговому агенту. На этом этапе идентификатор клиента, такой как телефонный номер MSISDN (номер мобильного абонента цифровой сети с предоставлением комплексных услуг), адрес электронной почты или любой другой идентификатор доступа к сети передается от клиента 15 устройству-получателю 16 платежей.

Затем устройство-получатель 16 платежей отправляет сообщение 22 на сервер 18 безопасности с идентификатором клиента и идентификаторами приложений для одного или более платежных приложений клиента (например, VISA, MasterCard, American Express, Diner Club и т.д.), которые продавец устройства-получателя 16 платежей хотел бы использовать. Идентификатор приложения может содержать текстовую строку, указывающую на приложение, префикс приложения или уникальный идентификатор приложения в соответствии с EMV. Кроме того, туда включается маркер безопасности для устройства-получателя 16 платежей, как доказательство, что устройству-получателю платежей разрешено получить доступ к одному или более платежным приложениям клиента. Маркер безопасности содержит сертификат, который был ранее выдан провайдером 19 схемы или посредником устройству-получателю 16 платежей, санкционирующий устройство-получателя 16 платежей для одного или более платежных приложений клиента; при этом для каждого провайдера схемы, например для VISA или MasterCard, обеспечивается один маркер. Например, маркер безопасности может содержать электронную подпись, удовлетворяющую требованиям инфраструктуры открытых ключей. Таким образом, устройство-получатель платежей генерирует подпись с использованием своего закрытого ключа, посредством чего сервер 18 безопасности может (1) проверить, что подпись соответствует открытому ключу устройства-получателя платежей, как записано в маркере безопасности, таким образом аутентифицируя продавца; и (2) проверить, что маркер безопасности или сертификат является допустимым, посредством проверки цифровой подписи маркера, проверки времени истечения срока действия, проверки относительно списков аннулирования и других стандартных операций PKI (инфраструктуры открытых ключей), чтобы таким образом проверить полномочия устройства-получателя платежей для установления контакта с платежным приложением клиента.

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

Затем сервер 18 безопасности проверяет 23, с использованием маркера безопасности, что устройство-получатель 16 платежей санкционировано для получения доступа к платежным приложениям клиента.

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

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

Если были отправлены несколько маркеров, соответствующих различным платежным приложениям клиента, устройство-получатель 16 платежей запрашивает 26 клиента 15, с использованием канала предыдущих продаж, какое платежное приложение клиента следует использовать. Например, это может происходить через веб-интерфейс для интернет-магазина, или с помощью телефонного торгового агента, спрашивающего клиента по телефону. Тогда клиент 15 выбирает 28, какое платежное приложение клиента нужно использовать. Однако следует отметить, что этот запрос 26 ни в коем случае не использует защитный элемент 12.

Если платежный канал не был уже установлен, как объясняется выше, устройство-получатель 16 платежей отправляет сообщение 30 на сервер 18 безопасности, чтобы установить защищенный платежный канал с защитным элементом. Тогда сервер безопасности устанавливает защищенный канал и отвечает 32 устройству-получателю 16 платежей, чтобы обеспечить возможность устройству-получателю платежей установить связь с платежным приложением на защитном элементе 12. Если текстовая строка или префикс приложения использовались прежде в качестве идентификатора приложения, сервер безопасности при этом передает id (идентификатор) приложения, который устройство-получатель платежей может использовать, если дополнительно связывается с платежным приложением клиента.

Затем устройство-получатель 16 платежей устанавливает связь 34 с определяемым платежным приложением клиента на защитном элементе 12 для производства платежа, например, с использованием протокола (EMV). Хотя протокол EMV известен сам по себе, он до сих пор использовался только для непосредственной связи между устройством-получателем платежей и защитным элементом, когда защитный элемент был помещен в месте совершения продажи или находился в физической близости при использовании взаимодействий NFC. В отличие от этого, вся связь между устройством-получателем 16 платежей и защитным элементом 12 производится под управлением сервера 18 безопасности. Поскольку устройство-получатель 16 платежей связывается с защитным элементом 12 только под управлением сервера 18 безопасности и поскольку только устройства-получатели платежей, которые санкционированы для определяемого платежного приложения клиента, до этого момента мошенническим устройствам-получателям 16 платежей препятствуют в получении доступа к приложениям в защитном элементе 12. Кроме того, предотвращается запрашивание устройством-получателем платежей приложений, для которых это устройство-получатель платежей не санкционировано. Например, если непосредственная связь между устройством-получателем платежей и приложениями клиента разрешена, устройство-получатель платежей может делать попытку установления связи с различными приложениями клиента, что ставит под угрозу конфиденциальность клиента. Действительно, если непосредственная связь между устройством-получателем платежей и защитным элементом разрешена, простое существование определенных приложений клиента может быть раскрыто, что ставит под угрозу конфиденциальность клиента.

Защищенный канал может быть реализован, например, с использованием SSL, протокола защищенных соединений, и SCP80, протокола защищенного канала 80. Это обеспечивает возможность устройству-получателю 16 платежей использовать APDU (пакеты данных протокола прикладного уровня) для производства платежей, связываясь с определяемым платежным приложением клиента.

Фиг. 2b представляет схему последовательности операций, иллюстрирующую систему связи во втором варианте осуществления, когда клиент совершает покупку с использованием компонентов, показанных на фиг. 1а-1b. Основное отличие по сравнению с вариантом осуществления фиг. 2a заключается в том, что сервер 18 безопасности определяет, какое платежное приложение клиента следует использовать. Коммуникационные сигналы 20, 22, 24, 34 и обработка 23 соответствуют сигналам и обработке, представленным на фиг. 2a.

Однако, в этом варианте осуществления, если сообщение 22 от устройства-получателя платежей содержит множество платежных приложений клиента, сервер 18 безопасности на этом этапе 23 определяет, какое из множества платежных приложений клиента следует использовать для остальной части торговой операции. Это может быть выполнено, например, сервером безопасности, отправляющим сообщение 35 на защитный элемент 12, чтобы осведомиться 36 у клиента 15, какое платежное приложение клиента следует использовать посредством Java MidLet, веб-приложения или отдельного приложения, выполняющегося на защитном элементе 12. Тогда клиент 15 может выбрать 37, какое платежное приложение клиента следует использовать, после чего этот выбор передается 38 на сервер 18 безопасности.

В качестве примера, устройство-получатель 16 платежей указывает 22, что оно может использовать для производства платежа VISA, MasterCard или American Express. Затем сервер 18 безопасности запрашивает базу данных или запускает логические функции на терминале мобильной связи клиента 15, чтобы определить, что пользователь имеет платежное приложение клиента только VISA и MasterCard. Клиенту предоставляют вариант выбора для производства платежа с помощью VISA или MasterCard (то есть используя платежное приложение клиента VISA или платежное приложение клиента MasterCard), посредством чего пользователь выбирает, используя пользовательский интерфейс терминала 10 мобильной связи, произвести оплату с использованием платежного приложения клиента VISA на защитном элементе 12.

Затем устройство-получатель 16 платежей отправляет сообщение 30 на сервер 18 безопасности, чтобы установить защищенный платежный канал с защитным элементом 12. Сервер безопасности устанавливает защищенный канал и отвечает 32 устройству-получателю 16 платежей, чтобы разрешить устройству-получателю платежей установить связь с платежным приложением на защитном элементе 12.

Связь 34 между устройством-получателем 16 платежей и защитным элементом 12 через сервер 18 безопасности производится, как в варианте осуществления, иллюстрированном на фиг. 2a.

В одном варианте осуществления, когда сообщение 22 от устройства-получателя 16 платежей содержит множество платежных приложений клиента, сервер 18 безопасности получает список допустимых платежных приложений клиента, например, с использованием сообщений 35 и 38 от защитного элемента 12. В одном варианте осуществления сервер 18 безопасности запрашивает, например, бесконтактную регистрационную службу (CRS), как определено в Поправке C спецификации карты GlobalPlatform, в защитном элементе 12, в котором хранится такой список допустимых платежных приложений клиента. Тогда клиент 15 имеет заданный список допустимых платежных приложений клиента. Сервер 18 безопасности определяет пересекающийся набор из списка платежных приложений клиента от устройства-получателя 16 платежей и списка допустимых платежных приложений от защитного элемента 12. Тогда этот пересекающийся набор содержит все платежные приложения клиента, которые запрашивает устройство-получатель платежей и одобряет клиент 15. Затем этот пересекающийся список (который может содержать ноль, один или более пунктов) отправляется 24 устройству-получателю 16 платежей и используется впоследствии, как описано выше.

Фиг. 3a является схематическим представлением, показывающим компоненты аппаратного обеспечения устройства-получателя 16 платежей, представленного на фиг. 1а-1b. Контроллер 46 обеспечен с использованием любого подходящего центрального процессора (CPU), микроконтроллера, цифрового сигнального процессора (DSP) и т.д., способного выполнять команды программного обеспечения, хранящиеся в компьютерном программном продукте 45, например, в форме запоминающего устройства. Компьютерный программный продукт 45 может быть запоминающим устройством или любой комбинацией из оперативного запоминающего устройства для считывания и записи (ОЗУ, RAM) и постоянного запоминающего устройства (ПЗУ, ROM). Запоминающее устройство также содержит постоянное запоминающее устройство, которое может быть, например, любым единственным из магнитного запоминающего устройства, оптического запоминающего устройства, или твердотельной памяти, или даже удаленно смонтированного запоминающего устройства, или комбинацией из них.

Интерфейс 40 ввода/вывода (I/O) обеспечен для того, чтобы дать возможность устройству-получателю 16 платежей взаимодействовать с другими компонентами, такими как сервер 18 безопасности. Интерфейс 40 I/O может быть, например, сетевым интерфейсом, таким как интерфейс Ethernet (локальной компьютерной сети).

Устройство-получатель 16 платежей может быть реализовано в том же веб-сервере, который используется для интернет-магазина, или это может быть отдельный сервер.

Фиг. 3b является схематическим представлением, показывающим функциональные модули устройства-получателя платежей, представленного на фиг. 1а-1b. Модули могут быть реализованы с использованием программного обеспечения устройства-получателя платежей, такого как компьютерная программа. Все модули зависят от среды 41 выполнения, которая использует контроллер 46, и факультативно компьютерный программный продукт 45, и интерфейс 40 I/O, представленные на фиг. 3a.

Устройство 42 получения идентификатора клиента выполнено с возможностью получения идентификатора клиента. Источником для идентификатора клиента может быть, например, торговая операция интернет-магазина или запрос http от терминала мобильной связи.

Передатчик 43 выполнен с возможностью отправки первого сообщения на сервер 18 безопасности, при этом первое сообщение может содержать идентификатор клиента, полученный устройством получения идентификатора клиента, идентификатор приложения, указывающий на платежное приложение клиента, и маркер безопасности для устройства-получателя платежей. Это обеспечивает возможность серверу безопасности аутентифицировать устройство-получатель 16 платежей.

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

Устройство-получатель платежей дополнительно содержит устройство 44 установления канала, которое выполнено с возможностью установления защищенного канала с защитным элементом терминала мобильной связи для производства платежей с использованием платежного приложения клиента. Защищенный канал устанавливается только после того, как второе сообщение принимается приемником 47. Затем может быть произведена оплата между устройством-получателем платежей и платежным приложением клиента с использованием защищенного канала.

Фиг. 4a схематично показывает вариант осуществления сервера 18 безопасности, представленного на фиг. 1а-1b. Контроллер 50 обеспечен с использованием любого подходящего центрального процессора (CPU), микроконтроллера, цифрового сигнального процессора (DSP) и т.д., способного выполнять команды программного обеспечения, хранящиеся в компьютерном программном продукте 52, например, в форме запоминающего устройства. Компьютерный программный продукт 52 может быть запоминающим устройством или любой комбинацией из оперативного запоминающего устройства для считывания и записи (RAM) и постоянного запоминающего устройства (ROM). Запоминающее устройство также содержит постоянное запоминающее устройство, которое, например, может быть любым единственным из магнитного запоминающего устройства, оптического запоминающего устройства, или твердотельной памяти, или даже удаленно смонтированного запоминающего устройства, или комбинацией из них.

Интерфейс 54 ввода/вывода обеспечен для того, чтобы дать возможность серверу 18 безопасности взаимодействовать с другими компонентами, такими как устройство-получатель 16 платежей. Интерфейс 54 I/O может быть, например, сетевым интерфейсом, таким как интерфейс Ethernet.

Факультативно, обеспечен пользовательский интерфейс (не показан) для использования оператора сервера 18 безопасности. Дополнительно или в качестве альтернативы, сервером 18 безопасности можно управлять удаленно или локально, используя приемник/передатчик 54.

Сервер 18 безопасности может быть объединен в одно целое в одном модуле, или он может быть разделен на несколько отдельных модулей, например, по причинам возможности модернизации, легкости реализации или дублирования. В случае если имеется несколько модулей, которые составляют сервер 18 безопасности, некоторые компоненты могут присутствовать более чем в одном модуле, например в контроллере 50, приемнике/передатчике 54 и/или компьютерном программном продукте 52.

Фиг. 4b является схематическим представлением, показывающим функциональные модули сервера безопасности, представленного на фиг. 1а-1b. Модули могут быть реализованы с использованием аппаратного обеспечения и/или программного обеспечения сервера безопасности. Все модули зависят от среды 51 выполнения, которая использует контроллер 50 и факультативно компьютерный программный продукт 52 и интерфейс 54 I/O вода, представленный на фиг. 4a.

Приемник 51 выполнен с возможностью приема первого сообщения от устройства-получателя платежей, как описано выше.

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

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

Кроме того, сервер безопасности содержит устройство 57 установления канала. Устройство установления канала может устанавливать защищенный канал между устройством-получателем платежей и платежным приложением клиента, только когда устройство-получатель платежей санкционировано провайдером схемы платежного приложения клиента. Устройство установления канала может произвести это установление защищенного канала, управляя установлением связи между устройством-получателем платежей и платежным приложением клиента. В качестве альтернативы или дополнительно, установленный канал может гарантировать, что вся связь между устройством-получателем платежей и платежным приложением клиента проходит через сервер безопасности. Это выполняется во взаимодействии с устройством 44 установления канала устройства-получателя платежей. Таким образом, вся связь между устройством-получателем платежей и платежным приложением клиента осуществляется под управлением сервера безопасности.

Фиг. 5 представляет блок-схему последовательности операций, иллюстрирующую способ, выполняемый в устройстве-получателе 16 платежей, представленном на фиг. 1а-1b. Способ может быть реализован с использованием модулей, показанных на фиг. 3b. Блок-схема последовательности операций соответствует схемам последовательности операций на фиг. 2a-2b.

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

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

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

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

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

Фиг. 6 представляет блок-схему последовательности операций, иллюстрирующую способ, выполняемый на сервере безопасности, представленном на фиг. 1а-1b. Способ может быть реализован с использованием модулей, показанных на фиг. 4b. Блок-схема последовательности операций способа соответствует схемам последовательности операций на фиг. 2a-2b.

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

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

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

Как только подлежащее использованию платежное приложение клиента установлено, сервер 18 безопасности отправляет второе сообщение устройству-получателю платежей, указывающее, какое платежное приложение клиента следует использовать. Факультативно, если на этапе 74 определено, какое приложение не выполняется, сервер 18 безопасности на этом этапе может отправить множество идентификаторов платежных приложений клиента устройству-получателю платежей и позволить устройству-получателю платежей определять, какое из этих платежных приложений клиента следует использовать.

На этапе 78 установления защищенного канала сервер 18 безопасности устанавливает, по указанию от устройства-получателя 16 платежей, защищенный канал между устройством-получателем 16 платежей и защитным элементом 12.

Фиг. 7 показывает один пример компьютерного программного продукта 100, содержащего машиночитаемый носитель. На этом машиночитаемом носителе может храниться компьютерная программа 101, причем эта компьютерная программа может побуждать контроллер выполнять способ в соответствии с вариантами осуществления, описанными в данном описании. В этом примере компьютерный программный продукт представляет собой оптический диск, такой как CD (компакт-диск), или DVD (универсальный цифровой диск), или диск стандарта Blu-Ray. Как объясняется выше, компьютерный программный продукт также может быть воплощен в виде запоминающего устройства в устройстве, такого как запоминающее устройство 45 устройства-получателя 16 платежей или запоминающее устройство 52 сервера 18 безопасности. Хотя компьютерная программа 101 в данном описании схематично показана в виде дорожки на изображенном оптическом диске, компьютерная программа может хранится каким-либо способом, который является подходящим для компьютерного программного продукта.

Фиг. 8 иллюстрирует взаимосвязь между терминалом 10 мобильной связи, представленным на фиг. 1а-1b, защитным элементом 12, представленным на фиг. 1а-1b, и приложениями 5a-5b на защитном элементе. Терминал 10 мобильной связи содержит пользовательский интерфейс, содержащий, например, дисплей 5 и средство ввода данных пользователем, например, реализованное посредством обеспечения дисплея 5 в виде сенсорного дисплея, или с использованием клавиатуры.

Как отмечалось выше, защитный элемент 12 может быть реализован с использованием карты модуля идентификации абонента (SIM-карты) или универсальных карт с интегральными схемами (UICC), карты памяти (например, SD), вставленной в терминал мобильной связи, или защитный элемент 12 может быть встроен непосредственно в запоминающее устройство терминала мобильной связи. Защитный элемент 12 содержит одно или более платежных приложений 5a-5b клиента. На защитном элементе 12 также могут находиться другие приложения (не показаны), например, для программ доступа или лояльности.

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

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

2. Сервер безопасности по п.1, в котором устройство установления канала выполнено таким образом, что вся связь между устройством-получателем платежей и платежным приложением клиента устанавливается таким образом, что она проходит через сервер безопасности.

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

4. Сервер безопасности по п.1, в котором идентификатор клиента содержит телефонный номер, адрес электронной почты или идентификатор доступа к сети.

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

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

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

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

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

10. Сервер безопасности по п.9, в котором первое сообщение содержит текстовое сообщение, и сообщение подсказки содержит текстовое сообщение.

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

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

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

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

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

16. Устройство-получатель платежей по п.15, в котором идентификатор приложения в первом сообщении является таким же, как идентификатор приложения во втором сообщении.

17. Устройство-получатель платежей по п.15 или 16, в котором первое сообщение содержит множество идентификаторов приложений, каждый из которых указывает на соответствующее платежное приложение клиента.

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

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

20. Устройство-получатель платежей по п.15, в котором устройство установления канала выполнено с возможностью установления защищенного канала через глобальную сеть с защитным элементом терминала мобильной связи.

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

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