БЕСПРОВОДНОЕ УПРАВЛЕНИЕ ПРИКЛАДНОЙ ПРОГРАММОЙ ОПЛАТЫ, УСТАНОВЛЕННОЙ В МОБИЛЬНОМ УСТРОЙСТВЕ Российский патент 2015 года по МПК G06Q20/32 G06F21/31 

2420-176308RU/085

БЕСПРОВОДНОЕ УПРАВЛЕНИЕ ПРИКЛАДНОЙ ПРОГРАММОЙ ОПЛАТЫ, УСТАНОВЛЕННОЙ В МОБИЛЬНОМ УСТРОЙСТВЕ

Настоящая заявка согласно §119(e) раздела 35 Свода законов США притязает на приоритет предварительной заявки на патент США № 61/099060, озаглавленной "Бесконтактный телефон с секретными данными", поданной 22 сентября 2008 года, предварительной заявки на патент США № 61/220540, озаглавленной "Особенность настраиваемого кода-пропуска", поданной 25 июня 2009 года, и предварительной заявки на патент США № 61/220550, озаглавленной "Функциональные возможности, порожденные каналом мобильной связи", поданной 25 июня 2009 года, содержания которых включены в настоящий документ по ссылке во всей их полноте для всех назначений.

УРОВЕНЬ ТЕХНИКИ

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

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

Интеллектуальные карты или микросхемы имеются в двух общих разновидностях: контактный тип и бесконтактный тип. Интеллектуальная микропроцессорная карта или микросхема контактного типа является такой, которая включает в себя физический элемент (например, магнитную полосу), который обеспечивает доступ к данным и функциональным возможностям карты, обычно через некоторый вид терминала или устройства чтения карт. Бесконтактная интеллектуальная карта или микросхема представляет собой устройство, которое включает в себя средство взаимодействия с устройством чтения карт или терминалом точки продажи без необходимости прямого контакта. Таким образом, таким устройством можно фактически "провести" вблизи устройства чтения карт или терминала. Бесконтактные карты или микросхемы обычно взаимодействуют с устройством чтения карт или терминалом с использованием радиочастотной (RF) технологии, причем близость к устройству чтения или терминалу вызывает передачу данных между картой или микросхемой и устройством чтения или терминалом. Бесконтактные карты нашли использование в банковском деле и других сферах применения, в которых они имеют то преимущество, что пользователю не нужно доставать их из бумажника или кармана для участия в транзакции. Бесконтактная карта или микросхема могут быть встроены или иным образом включены в мобильное устройство, такое как мобильный телефон или персональный цифровой ассистент (PDA). Кроме того, из-за растущего интереса в таких картах, были разработаны стандарты, которые управляют работой и интерфейсами для бесконтактных интеллектуальных карт, такие как стандарт ISO 14433.

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

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

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

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

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

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

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

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

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

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

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

Фиг.11 является блок-схемой последовательности операций для процесса запроса блокировки прикладной программы оплаты в соответствии с вариантом осуществления настоящего изобретения;

Фиг.12 иллюстрирует снимок экрана для экрана персонализации в соответствии с вариантом осуществления настоящего изобретения; и

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

ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

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

В ситуации транзакции потребительское устройство оплаты представляется устройству считывания устройства оплаты или терминалу 22 точки продажи (POS), который может выполнить доступ к данным, хранящимся на или в потребительском устройстве оплаты. Устройство считывания устройства оплаты или терминал 22 точки продажи (POS) может выполнить доступ к данным, хранящимся на устройстве 20 оплаты, посредством прямого контакта (например, посредством использования устройства считывания магнитной полосы) или посредством бесконтактного способа (например, обмена данными между бесконтактной микросхемой, содержащейся в устройстве, и устройством считывания/терминалом, использующим механизм связи ближнего поля). Данные счета (а также любые необходимые потребительские данные) сообщаются от устройства считывания/терминала 22 продавцу 24 и в конечном итоге системе 26 обработки транзакции/данных продавца. Как часть процесса авторизации, выполняемого продавцом, система 26 обработки транзакций продавца может выполнить доступ к базе 28 данных продавца, которая обычно хранит данные относительно клиента/потребителя (как результат процесса регистрации с продавцом, например), устройства оплаты потребителя и истории транзакций потребителя с продавцом. Система 26 обработки транзакций продавца обычно взаимодействует с принимающей стороной 30 (которая управляет счетами продавца) в качестве части всего процесса авторизации.

Система 26 обработки транзакций продавца и/или принимающая сторона 30 предоставляет данные для сети 34 обработки оплаты, которая среди прочих функциональных возможностей участвует в процессах произведения расчетов и урегулирования, которые являются частью всей обработки транзакций. Взаимодействие и передача данных между системой 26 обработки транзакций продавца и сетью 34 обработки оплаты могут выполняться посредством прямого соединения 32 или с помощью посредника, такого как принимающая сторона 30. Как часть процесса авторизации транзакции сеть 34 обработки оплаты может выполнить доступ к базе 36 данных счетов, которая обычно содержит информацию относительно истории оплат счетов потребителя, истории возвратов платежей и спорных ситуаций, кредитоспособности и т.д. Сеть 34 обработки оплаты взаимодействует с эмитентом 38 в качестве части процесса авторизации, причем эмитент 38 является объектом, который выдал устройство оплаты потребителю и управляет счетом потребителя. Данные счета клиента или потребителя обычно хранятся в базе 40 данных клиента/потребителя, доступ к которой может выполнить эмитент 38 как часть процессов авторизации и управления счетами.

В случае, когда устройство 20 оплаты является способным к взаимодействию и/или обмену данными с использованием системы беспроводной связи (например, для случая мобильного телефона или персонального цифрового ассистента, оборудованного беспроводной связью), устройство 20 оплаты может взаимодействовать и/или обмениваться данными с системой 23 сотовой связи по беспроводной сети 21. Система 23 сотовой связи является способной к взаимодействию и обмену данными со шлюзом 25 мобильной связи, который действует для связывания беспроводной сети с проводной сетью 27 (например, частями сети Интернет). Шлюз 25 мобильной связи может выполнять взаимодействие и обмен данными с сетью 34 обработки оплаты обычно посредством проводной сети 27 (например, частей сети Интернет). Как упомянуто, в некоторых вариантах осуществления потребительское устройство оплаты может представлять собой беспроводной мобильный телефон, который включает в себя бесконтактную карту или микросхему. Бесконтактная карта или микросхема могут взаимодействовать с устройством считывания устройства/терминалом точки продажи с использованием возможностей связи ближнего поля (NFC), таких как RF (радиочастотный), инфракрасный или оптический механизм связи.

При обычной работе сообщение запроса авторизации создается во время покупки потребителем товара или услуги в точке продажи (POS) с использованием потребительского устройства оплаты. Сообщение запроса авторизации обычно отправляют от устройства считывания устройства/терминала 22 POS через систему 26 обработки данных продавца принимающей стороне 30 продавца в сеть 34 обработки оплаты и затем эмитенту 38. Сообщение запроса авторизации может включать в себя запрос авторизации на проведение транзакции электронной оплаты. Оно может включать в себя один или более из номера счета оплаты владельца счета, кода валюты, суммы продажи, метки транзакции продавца, города получателя, штата/страны получателя и т.д. Сообщение запроса авторизации может быть защищено с использованием способа надежного шифрования (например, 128-битового SSL (уровень защищенных сокетов) или эквивалента), чтобы воспрепятствовать раскрытию данных.

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

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

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

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

Как отмечено, потребительское устройство 20 оплаты может принимать один из многих подходящих видов. Потребительское устройство оплаты может представлять собой мобильное устройство, которое включает в себя бесконтактный элемент, такой как микросхема для хранения данных (например, номера BIN (идентификационного номера банка), номера счета и т.д.) оплаты, и элемент передачи данных связи ближнего поля (NFC), такой как антенна, светоизлучающий диод, лазер и т.д. Устройство, содержащее бесконтактную карту или микросхему или другой элемент хранения данных, может являться сотовым (мобильным) телефоном, персональным цифровым ассистентом (PDA), пейджером, транспондером и т.п. Потребительское устройство оплаты также может включать в себя способность выполнять дебетовые функциональные возможности (например, дебетовая карта), кредитные функциональные возможности (например, кредитная карта) или функциональные возможности предоплаты (например, карта предоплаты).

В вариантах осуществления изобретения, которые включают в себя бесконтактный элемент (который может включать в себя бесконтактную микросхему и элемент передачи данных связи ближнего поля), встроенный в беспроводной мобильный телефон или подобное устройство, бесконтактный элемент может взаимодействовать с устройством считывания устройства продавца или терминалом точки продажи с использованием способа связи малой дальности, например возможность связи ближнего поля (NFC). Примеры таких технологий NFC включают в себя стандарт ISO 14443, RFID, Bluetooth™ и способы инфракрасной связи.

Фиг.2 является функциональной блок-схемой, иллюстрирующей первичные компоненты системы 100 для запрещения работы прикладной программы оплаты, которая установлена в мобильном телефоне или другом беспроводном устройстве, в соответствии с вариантом осуществления настоящего изобретения. Как показано на фиг.1, система 100 включает в себя мобильное устройство 102 имеющее возможности 122 беспроводной связи. Мобильное устройство 102 может являться беспроводным мобильным телефоном, персональным цифровым ассистентом (PDA), переносным компьютером, пейджером и т.д. В типичном варианте осуществления мобильное устройство 102 является сотовым телефоном, хотя, как отмечено, реализация настоящего изобретения не ограничена этим вариантом осуществления. В случае сотового телефона в качестве мобильного устройства 102 устройство включает в себя компоновку 104 схем мобильного устройства (сотового телефона), которая предоставляет возможность некоторых функциональных возможностей телефонии. Среди других функциональных возможностей схема 104 мобильного устройства дает возможность мобильному устройству 102 взаимодействовать беспроводным образом с системой (то есть, оператором беспроводной связи) 120 сотовой связи через сеть 122 сотовой связи. Компоновка 104 схем мобильного устройства также может включать в себя схему, которая предоставляет возможность других функциональных возможностей устройства, таких как ввод данных, вывод данных, отображение данных, обработка данных и т.д.

Мобильное устройство 102 далее включает в себя бесконтактный элемент 106, обычно реализованный в виде полупроводниковой микросхемы. Бесконтактный элемент 106 может включать в себя элемент 110 безопасного хранения данных, хотя элемент 110 безопасного хранения данных также может быть реализован как элемент, отдельный от бесконтактного элемента 106. Бесконтактный элемент 106 также включает в себя элемент 105 переноса данных (например, передачи данных) связи ближнего поля (NFC), такой как антенна или преобразователь. Бесконтактный элемент 106 обычно встраивается в элементы мобильного устройства 102 и интегрируется с ними, и данные или команды управления, переданные через сеть 122 сотовой связи, могут быть обменены с помощью бесконтактного элемента 106 или применены к бесконтактному элементу 106 посредством интерфейса 108 бесконтактного элемента. Интерфейс 108 бесконтактного элемента функционирует для обеспечения возможности обмена данными и/или командами управления между компоновкой 104 схем мобильного устройства (и, следовательно, сетью сотовой связи) и бесконтактным элементом 106. Таким образом, бесконтактный элемент 106 может включать в себя возможность хранения данных в виде памяти или безопасного хранилища 110 данных, к которому можно выполнить доступ через интерфейс 108 для обеспечения возможности реализации, например, функциональных возможностей чтения, записи и стирания данных. Доступом к безопасному хранилищу 110 данных можно управлять посредством требования некоторого вида аутентификации или предоставления данных безопасности/управления доступом для разрешения чтения, записи или иных действий над данными. Аутентификация или данные безопасности/управления доступом также могут требоваться, чтобы активизировать прикладную программу или функциональную возможность, сохраненную в безопасном хранилище 110 данных. Бесконтактный элемент 106 дополнительно может включать в себя один или более счетчиков. Счетчики могут использоваться для отслеживания различных аспектов пользовательского ввода и информации, соотносящейся к транзакциями, например, количества попыток ввода пароля пользователя, количества проведенных автономных транзакций, общая сумма автономных транзакций и т.д. Автономная транзакция - это транзакция, в которой эмитент карты не должен авторизовать транзакцию во время проведения транзакции.

Безопасное пространство 110 данных может использоваться мобильным устройством 102 для хранения рабочих параметров или других данных, используемых при работе устройства. Безопасное пространство 110 данных также может использоваться для хранения других данных, для которых желательна улучшенная безопасность, например, данных транзакций, персональных данных счета, идентификационных данных, данных аутентификации, рабочих параметров для прикладной программы, данных управления доступом для прикладной программы или функциональных возможностей устройства и т.д. Безопасное пространство 110 данных может быть реализовано в виде микросхемы, которая является отдельной и в отдалении от бесконтактного элемента 106, или в качестве альтернативы может являться секцией памяти в микросхеме, которая является частью бесконтактного элемента 106. Следует отметить, что безопасное пространство данных и/или бесконтактный элемент, содержащийся в мобильном устройстве, могут быть съемным элементом или могут быть интегрированы в мобильное устройство. Примеры съемных элементов включают в себя SIM-карты, карты флэш-памяти и другие подходящие устройства.

Мобильное устройство 102 также может включать в себя одну или более прикладных программ 109, которые реализованы в виде одного или более из программного обеспечения, программно-аппаратного обеспечения и аппаратного обеспечения, и которые используются для реализации различных функциональных возможностей, желаемых пользователем. Такие функциональные возможности могут включать в себя, но без ограничения, операции транзакции электронной коммерции, операции оплаты транзакции и т.д. Как правило, прикладные программы 109 представляют собой процессы или операции, которые выделены для конкретной функциональной возможности, которая предоставляет дополнительные преимущества пользователю, и которая не является частью обычной работы устройства (то есть, например, не является частью обеспечения стандартных функциональных возможностей телефонии). Как показано на фигуре, прикладные программы 109 могут обмениваться данными с безопасным пространством 110 данных (через интерфейс 108 бесконтактного элемента) и также могут быть способными к обмену данными с компоновкой 104 схем мобильного устройства. Типичная прикладная программа 109 для задач настоящего изобретения представляет собой прикладную программу оплаты, которая дает возможность пользователю сделать оплату для транзакции, причем транзакция полностью или частично выполняется с использованием мобильного устройства. В таком примере безопасное пространство 110 данных может содержать данные аутентификации, данные идентификации пользователя, данные записи транзакции, данные баланса счета и т.д. Прикладные программы 109 обычно хранятся как набор исполняемых команд в памяти 107, которая также может включать в себя хранилище 113 данных. Процессор выполняет доступ к памяти 107 для загрузки и выгрузки команд и данных по мере необходимости для исполнения команд и выполнения функциональных возможностей прикладных программ.

Бесконтактный элемент 106 может передавать и принимать данные с использованием элемента 105 передачи данных, который реализует возможность 112 связи ближнего поля, обычно в соответствии со стандартизированным протоколом или механизмом передачи данных (идентифицированным как ISO 14443/NFC на чертеже). Возможность 112 связи ближнего поля представляет собой возможность связи малой дальности, такой как RFID, Bluetooth™, инфракрасное излучение или другая возможность передачи данных, которая может использоваться для обмена данными между мобильным устройством 102 и устройством считывания устройства или терминалом 130 точки продажи, который обычно располагается в месте ведения бизнеса продавца. Таким образом, мобильное устройство 102 способно к взаимодействию и передаче данных и/или команд управления как через сеть 122 сотовой связи, так и через возможность 112 связи ближнего поля.

Система 100 дополнительно включает в себя принимающую сторону 132, которая находится в связи с продавцом 130 или устройством считывания устройства или терминалом точки продажи продавца. Принимающая сторона 132 находится в связи с сетью 134 обработки оплаты и, как было описано, может обмениваться данными с сетью 134 обработки оплаты в качестве части процесса авторизации транзакции. Сеть 134 обработки оплаты также находится в связи с эмитентом 136. Как было описано, эмитент 136 может обмениваться данными с сетью 134 обработки оплаты в качестве части процесса авторизации транзакции или процесса согласования транзакции.

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

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

В контексте настоящего изобретения мобильное устройство 102 может являться любым устройством, способным к взаимодействию и передаче данных с сетью сотовой связи и, если желательно, с системой связи малой дальности. Как отмечено, одним примером является мобильный беспроводный телефон. Фиг.3 является функциональной блок-схемой, иллюстрирующей основные компоненты переносного потребительского устройства (например, элемента 102, показанного на фиг.2), такого как мобильный телефон, который может использоваться в качестве части системы и способа изобретения. Как проиллюстрировано на фиг.3, мобильное устройство 302 может включать в себя схему, которая используется для обеспечения возможности некоторых функциональных возможностей телефонии и других функциональных возможностей устройства. Функциональные элементы, ответственные за предоставление этих функциональных возможностей, могут включать в себя процессор 304 для исполнения команд, которые реализуют функциональные возможности и операции устройства. Процессор 304 может выполнять доступ к хранилищу 312 данных (или к другим подходящим областям или элементу памяти) для извлечения команд или данных, используемых при исполнении команд. Элементы 308 ввода/вывода данных могут использоваться, чтобы дать возможность пользователю ввести данные (например, через микрофон или клавиатуру) или принять выходные данные (например, через динамик). Устройство 306 отображения также может использоваться для вывода данных пользователю. Элемент 310 связи может использоваться для обеспечения возможности передачи данных между устройством 302 и беспроводной сетью (например, через антенну 318), чтобы содействовать предоставлению функциональных возможностей передачи данных и телефонии. Как описано со ссылкой на фиг.3, устройство 302 также может включать в себя интерфейс 314 бесконтактного элемента для обеспечения возможности передачи данных между бесконтактным элементом 316 и другими элементами устройства, причем бесконтактный элемент 316 может включать в себя безопасную память и элемент передачи данных связи ближнего поля.

Хранилище 312 данных может представлять собой память, которая хранит данные, и может быть выполнено в любом подходящем виде, в том числе в виде магнитной полосы, микросхемы памяти и т.д. Память может использоваться для хранения данных, таких как информация идентификации или аутентификации пользователя, информация счета пользователя, данные транзакции и т.д. Сохраненная финансовая информация может включать в себя информацию, такую как информация банковского счета, идентификационный номер банка (BIN), информация номера кредитной или дебетовой карты, информация баланса счета, дата истечения срока действия, информация о потребителе, такая как имя, дата рождения, и т.д. Следует заметить, что такие данные могут вместо этого или также храниться в элементе безопасного хранения данных, таком как безопасное хранилище 110 данных на фиг.2, или в безопасной памяти, которая является частью бесконтактного элемента 316. Как описано, хранилище 312 данных также может содержать команды, которые при их исполнении процессором 304 реализуют операции или процессы, которые являются частью работы устройства или прикладной программы, которая установлена в устройстве. Кроме того, безопасная память, которая является частью бесконтактного элемента 316, также может хранить команды, которые при их исполнении процессором 304 реализуют прикладную программу, операции или процессы, связанные с работой устройства или выполнением прикладной программы, установленной в устройстве.

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

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

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

I. Проведение транзакций оплаты

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

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

На этапе 402 активируется прикладная программа оплаты. Это может включать в себя "запуск" прикладной программы оплаты как результат пользовательского ввода (например, нажатия клавиши, активации функциональной клавиши, нажатия кнопки, голосового ввода или другого взаимодействия пользователя с элементом пользовательского интерфейса). В некоторых вариантах осуществления активация прикладной программы оплаты может потребовать процесса аутентификации, который гарантирует, что пользователь должным образом авторизован для использования прикладной программы (например, ввода и аутентификации пароля или других данных безопасности). На этапе 404 прикладная программа оплаты проверяет состояние или статус данных управления доступом прикладной программы. Данные управления доступом прикладной программы могут иметь любой подходящий вид, в том числе, но без ограничения, значения данных, флага индикатора, набор значений данных, алфавитно-цифровых строк данных, наличия или отсутствия данных в конкретном местоположении данных и т.д. Данные управления доступом прикладной программы могут быть сохранены в любом подходящем месте, например, в безопасном местоположении памяти в устройстве (таком как являющееся частью бесконтактного элемента) или в памяти, которая хранит данные и исполняемые команды, и которая является частью мобильного устройства. На этапе 406 процесс выполняет проверку для определения, является ли значение данных управления доступом прикладной программы оплаты таким, что использование прикладной программы оплаты разрешается. Это может включать в себя чтение данных, хранящихся в конкретном местоположении в памяти, и сравнение их с одним или несколькими предварительно определенными значениями, причем значения соответствуют возможным состояниям работы прикладной программы оплаты. Если значение данных управления доступом прикладной программы оплаты соответствует тому, которое разрешает использование прикладной программы, то пользователю предоставляется доступ к функциональным возможностям прикладной программы оплаты (этап 408), например, к тем, которые нужны для проведения оплаты для транзакции. Если значение данных управления доступом прикладной программы оплаты не соответствует тому, которое разрешает использование прикладной программы (или соответствует тому, которое лишает пользователя доступа к некоторым или всем функциональным возможностям прикладной программы оплаты), то пользователю не предоставляется доступ к некоторым или всем из функциональных возможностей прикладной программы оплаты (этап 410). Следует заметить, что, как упомянуто, данные управления доступом прикладной программы оплаты могут использоваться для разрешения или лишения доступа к некоторым функциональным возможностям (функциям) прикладной программы оплаты, например, посредством ограничения использования прикладной программы до некоторых сумм (например, максимальной суммы транзакции для одной или нескольких транзакций или во время конкретного периода), что предотвращает некоторые типы транзакций и т.д.

II. Запрещение прикладной программы оплаты

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

Как показано на фиг.5, когда мобильное устройство оплаты потеряно или украдено (или эмитент желает отключить прикладную программу оплаты по другим причинам), эмитент или оператор беспроводной сети (такой как оператор беспроводной связи) уведомляется относительно этого события. Это может произойти, например потому, что владелец мобильного телефона сообщает оператору беспроводной сети, что телефон был потерян или украден. Тогда оператор сообщает эмитенту, ответственному за счет оплаты владельца, что устройство оплаты, ассоциированное с этим счетом, больше не находится во владении зарегистрированного владельца. Затем эмитент или оператор сети формируют запрос для запрещения прикладной программы оплаты, установленной на устройстве оплаты (этап 502). Запрос может состоять в том, чтобы запретить все операции/функциональные возможности прикладной программы оплаты или отключить некоторый поднабор доступных операций прикладной программы оплаты. В ответ на запрос оператор сети формирует сообщение команды запрещения для устройства оплаты (этап 504). Сообщение команды запрещения может иметь одну из многих подходящих форм. Они включают в себя, но без ограничения, сообщение SMS (система обмена короткими сообщениями), сообщение электронной почты, формат, распознаваемый как данные управления, и т.д. Сообщение может включать в себя одно или более значений данных управления доступом прикладной программы оплаты, таких как код SMS или коды, значения данных, содержащиеся в заголовке сообщения, и т.д.

Сообщение команды запрещения затем предоставляется инфраструктуре сети сотовой связи (этап 506) и передается по сети беспроводной связи на устройство оплаты (этап 508). В случае сообщения SMS сообщение может быть "помещено" в устройство с использованием способов, хорошо известных в области техники обмена сообщениями мобильной связи. Сообщение команды запрещения принимается устройством оплаты (этап 510), которое затем может выполнить проверку для определения, является ли принятое сообщение аутентичным (этап 512). Это может включать в себя выполнение проверки для определения, было ли сообщение отправлено из действительного источника, например, от соответствующего сетевого оператора, или содержит ли сообщение данные, идентифицирующие эмитента для счета, ассоциированного с прикладной программой оплаты, и т.д. Если определено, что сообщение является аутентичным, то устройство оплаты обрабатывает принятое сообщение для извлечения данных управления прикладной программы оплаты (этап 514) и сохраняет извлеченные данные в соответствующей памяти или области хранения данных устройства оплаты (этап 516).

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

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

III. Сброс счетчика

Фиг.6 показывает блок-схему потока данных, иллюстрирующую путь взаимодействия между мобильным устройством пользователя, которое включает в себя прикладную программу 601 оплаты, и эмитентом 605 для операции сброса счетчика. В одном варианте осуществления запрос 606 сброса счетчика от прикладной программы 601 оплаты передается на мобильный шлюз 603 через пользовательский интерфейс (UI) 602 прикладной программы. Прикладная программа 601 оплаты, находящаяся на мобильном устройстве, может отправить запрос сброса к ассоциированному с ней пользовательскому интерфейсу. UI 602 может отправить запрос на мобильный шлюз 603 с использованием эфирного канала связи, например, сети сотовой связи. Мобильный шлюз 603 взаимодействует с эмитентом 605 через сеть 604 обработки оплаты, например, VisaNet, и перенаправляет запрос эмитенту 605. Фактически мобильный шлюз 603 действует как принимающая сторона для сети 604 произведения расчетов транзакции и эмитента 605. Эмитент 605 может отправить сценарий 607 ответа на мобильный шлюз 603 через сеть 604, который в свою очередь может отправить сценарий 607 ответа мобильному устройству пользователя для выполнения прикладной программой 601 оплаты. В некоторых вариантах осуществления запрос может быть отправлен непосредственно эмитенту 605 без необходимости мобильного шлюза 603.

Фиг.7 показывает блок-схему последовательности операций процесса 700 для способа обработки запроса сброса счетчика в соответствии с вариантом осуществления настоящего изобретения. На этапе 701 пользователь запрашивает автономную транзакцию. Прикладная программа оплаты проверяет, достиг ли счетчик порогового значения, на этапе 702. В некоторых вариантах осуществления эмитент может предварительно определить пороговое значение для счетчика и сконфигурировать бесконтактный элемент в мобильном устройстве соответствующим образом. В варианте осуществления пороговое значение может представлять собой количество автономных транзакций, разрешенных до того, как будет необходим сброс, например, 20 автономных транзакций. В других вариантах осуществления пороговое значение может являться максимальной накопленной суммой автономных транзакций, разрешенных до того, как будет необходим сброс счетчика, например, $100. В еще одном варианте осуществления пороговое значение может являться комбинацией нескольких критериев. Если на этапе 702 определено, что счетчик не достиг порогового значения, на этапе 711 транзакции разрешено продолжаться. Когда счетчик достиг порогового значения, как определено на этапе 702, прикладная программа оплаты отправляет запрос сброса счетчика эмитенту на этапе 703.

Как описано выше, запрос сброса счетчика может быть передан через мобильный шлюз и сеть произведения расчетов транзакции. Эмитент может определить, должен ли счетчик быть обновлен/сброшен, на этапе 704. В одном варианте осуществления эмитент может использовать один или несколько предварительно определенных критериев для оценки запроса и применения своих деловых правил для определения, должен ли счетчик быть сброшен или нет. Если эмитент определяет, что счетчик должен быть сброшен, эмитент формирует сценарий для сброса счетчика на этапе 705. Сценарий может являться исполняемым кодом, который включает в себя команды для операции, которая будет выполнена, например, для сброса счетчика. Если определено, что счетчик не должен быть сброшен, эмитентом формируется альтернативный сценарий на этапе 706. Сформированный сценарий передается прикладной программе оплаты на этапе 707. Прикладная программа оплаты на этапе 708 обрабатывает сценарий и на этапе 709 определяет, должен ли сценарий сбросить счетчик и тем самым разрешить транзакции продолжиться, или должен ли сценарий отклонить запрос сброса/обновления счетчика и тем самым отклонить транзакцию. Если сценарий предназначен для сброса/обновления счетчика, счетчик сбрасывается, и транзакции разрешают продолжаться на этапе 711. Если сценарий содержит команды для отклонения запроса сброса счетчика, счетчик не сбрасывается, и, следовательно, транзакция отклоняется на этапе 710. Когда транзакция отклоняется, пользователю придется использовать терминал POS для сброса счетчика. В некоторых вариантах осуществления пользователю может быть предоставлено сообщение на мобильном устройстве, которое просит его обратиться к эмитенту для сброса счетчика.

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

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

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

IV. Сброс пароля

Фиг.8 иллюстрирует блок-схему потока данных для процесса для эфирного запроса сброса пароля с использованием мобильного устройства, на котором установлена прикладная программа оплаты. Подобно варианту осуществления сброса счетчика прикладная программа 810 оплаты может отправить запрос 806 сброса пароля эмитенту 805. Эмитент 805 может проверить аутентичность пользователя посредством запроса некоторой информации аутентификации. Такая информация аутентификации может включать в себя персональную информацию пользователя, информацию счета и т.д. Когда пользователь аутентифицирован, эмитент 805 может определить, следует ли дать разрешение на запрос сброса, и в ответе отправляет соответствующий сценарий 808 для прикладной программы 801 оплаты через сеть 804 обработки оплаты, мобильный шлюз 803 и пользовательский интерфейс 802.

Фиг.9 является блок-схемой последовательности операций процесса 900 для сброса пароля прикладной программы оплаты в соответствии с вариантом осуществления настоящего изобретения. На этапе 901 пользователь запрашивает сброс пароля через прикладную программу оплаты на своем устройстве мобильной связи. Запрос сброса пароля передается эмитенту. На этапе 902 эмитент может проверить, что пользователь является зарегистрированным владельцем прикладной программы оплаты, и выполняет определение, следует ли разрешить или отклонить запрос сброса пароля. В варианте осуществления процесс аутентификации может быть выполнен с использованием вспомогательного канала связи. Например, когда пользователь отправляет запрос сброса пароля через мобильное устройство, пользователь может позвонить эмитенту и предоставить информацию аутентификации эмитенту. В другом варианте осуществления после приема запроса сброса эмитент может отправить сообщение пользователю либо на мобильное устройство, либо через некоторый другой канал связи и предоставить пользователю команды для установления его аутентичности. Когда аутентичность пользователя установлена, эмитент может продолжить оценку запроса сброса пароля.

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

Эмитент может использовать один или несколько предварительно определенных критериев, например, деловые правила, чтобы принять решение о том, следует ли разрешить или отклонить запрос сброса пароля. Если эмитент решает разрешить запрос сброса, эмитент формирует сценарий, который может сбросить пароль, на этапе 904. Как описано выше, сценарий может представлять собой исполняемый код, содержащий команды для выполнения операции, например, сценарий XML. В таком случае прикладная программа UI, ассоциированная с прикладной программой оплаты, может разрешить пользователю ввести новый пароль. Новый пароль может быть назначен в качестве текущего пароля, и новый пароль может быть необходим для осуществления доступа к прикладной программе оплаты с этого момента времени. Если эмитент решает отклонить запрос сбросить пароль, он формирует альтернативный сценарий на этапе 903. Альтернативный сценарий может включать в себя команды, которые сообщают прикладной программе оплаты, что запрос сброса пароля отклонен. В варианте осуществления прикладная программа оплаты через свой UI может сообщить пользователю об отклонении. Пользователю в этом случае придется лично обратиться к эмитенту, чтобы сбросить пароль. Либо сценарий, сформированный на этапе 904, либо сценарий, сформированный на этапе 903, передается прикладной программе оплаты на мобильном устройстве на этапе 905. После приема сценария на этапе 906 прикладная программа оплаты обрабатывает сценарий и выполняет действие, заданное в сценарии, например, сбрасывает пароль или сообщает об отклонении запроса.

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

V. Аутентификация пользователя

Фиг.10 иллюстрируют блок-схему потока данных для аутентификации пользователя прикладной программы оплаты, и фиг.11 является блок-схемой последовательности операций высокого уровня процесса 1100 для аутентификации пользователя прикладной программы, находящейся на мобильном устройстве, в соответствии с вариантом осуществления настоящего изобретения. Когда пользователь использует мобильное устройство для выполнения транзакции оплаты, установленная прикладная программа 1001 оплаты взаимодействует с терминалом точки продажи. В зависимости от характера транзакции у пользователя может быть запрошен ввод пароля. Если пользователь должен ввести пароль, то прикладная программа 1001 оплаты передаст тот запрос пользовательскому интерфейсу (UI) 1002, и UI 1002 запросит у пользователя пароль на этапе 1101. После того, как пользователь ввел пароль, прикладная программа оплаты принимает его от UI 1002, и определяет, является ли он правильным паролем, на этапе 1102. Если определено, что пароль является правильным, пользователю разрешают доступ к прикладной программе 1001 оплаты на этапе 1103. Если определено, что пароль является неправильным, делается определение, сколько неправильных попыток ввода пароля было сделано и было ли превышено максимальное количество попыток, на этапе 1104. В варианте осуществления эмитент может задать максимальное количество попыток ввода пароля. Если определено, что максимальное количество попыток было превышено, прикладная программа 1101 оплаты может определить, какое действие следует выполнить на этапе 1105. В соответствии с этим прикладная программа 1001 оплаты либо блокирует себя на этапе 1107, либо она может отправить запрос блокировки прикладной программы эмитенту на этапе 1106, чтобы блокировать прикладную программу оплаты. В случае, когда запрос прикладной программы блокировки отправляется эмитенту, эмитент может отправить сценарий, аналогичный описанному выше, для произведения блокировки прикладной программы оплаты. Когда прикладная программа 1001 оплаты блокируется, она не может использоваться ни для каких транзакций оплаты, пока она не будет разблокирована.

Что касается фиг.10, в зависимости от своей конфигурации прикладная программа 1001 оплаты может отправить запрос 1006 блокировки прикладной программы UI 1002. UI 1002 передает запрос 1006 блокировки на мобильный шлюз 1003 через эфирную связь. В ответ UI 1002 может принять сценарий 1007 блокировки от мобильного шлюза 1003 через эфирную связь и передать сценарий 1007 блокировки прикладной программе 1001 оплаты. Прикладная программа 1001 оплаты обрабатывает сценарий 1007 блокировки и блокирует себя.

Если прикладная программа 1001 оплаты выполнена с возможностью блокировать себя после того, как было превышено допустимое количество попыток ввода пароля, не требуется взаимодействие с сетью 1004 обработки оплаты для блокировки прикладной программы оплаты. Однако если в варианте осуществления прикладная программа оплаты выполнена с возможностью отправлять запрос 1006 блокировки эмитенту 1005, прикладная программа 1001 оплаты может отправить запрос 1006 блокировки прикладной программы UI 1002. UI 1002 может передать запрос 1006 блокировки мобильному шлюзу 1003 через эфирную связь. Мобильный шлюз 1003 связи может принять запрос 1006 блокировки по эфирной связи от прикладной программы 1001 оплаты (через UI 1002) и отправляет запрос 1006 блокировки сети 1004 обработки оплаты. Сеть 1004 обработки оплаты может передать запрос 1006 блокировки эмитенту 1005. Когда эмитент 1005 оценивает запрос блокировки, он может отправить соответствующий сценарий сети 1004 обработки оплаты. Сеть 1004 обработки оплаты может передать сценарий 1007 блокировки мобильному шлюзу 1003 (для передачи прикладной программе 1001 оплаты с использованием эфирного канала связи). Как описано здесь, сеть 1004 обработки оплаты может включать в себя серверный компьютер.

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

Когда прикладная программа 1001 оплаты заблокирована, она может быть разблокирована посредством приема и обработки соответствующего сценария разблокировки из авторизованного источника (то есть, от эмитента 1005 или агента, такого как сеть 1004 обработки оплаты, действующего от имени эмитента 1005). Эмитент 1005 может потребовать, чтобы пароль был сброшен как часть процедуры разблокировки.

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

Фиг.12 является упрощенным снимком экрана для экрана 1200 персонализации для инициализации прикладной программы 1001 оплаты. Экран 1200 персонализации может быть реализован, например, с использованием мобильного устройства и прикладной программы оплаты. Пользователь может настроить прикладную программу 1001 оплаты для сохранения/изменения пароля и/или сохранения или изменения количества допустимых попыток ввода пароля. В общем случае пользователь может ввести количество попыток ввода пароля, которое является меньше заданного по умолчанию количества, как описано выше. Экран персонализации может быть представлен пользователю посредством UI 1002 или во время отдельной инициализации на отдельной компьютерной системе, например, при использовании персонального компьютера, который безопасно соединен с прикладной программой работы в режиме реального времени с банком и кредитами эмитента 1005. UI 1002 может принять введенные данные от пользователя и передать их прикладной программе 1001 оплаты, которая может сохранить их для будущего использования.

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

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

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

Фиг.13 является блок-схемой иллюстративного вычислительного устройства, которое может использоваться для реализации любого из вариантов осуществления настоящего изобретения. Элементы вычислительного устройства, проиллюстрированного на фиг.13, могут использоваться для реализации процессов, способов или операций изобретения полностью или частично и могут являться частью сервера или другого вычислительного устройства (например, мобильного шлюза, управляемого эмитентом сервера и т.д.). Подсистемы, показанные на фиг.13, соединены через системную шину 1300. Показаны дополнительные подсистемы, такие как принтер 1310, клавиатура 1320, жесткий диск 1330 (или другая память, содержащая машиночитаемые носители), монитор 1340, который соединен с адаптером 1350 устройства отображения, и другие. Периферийные устройства и устройства ввода-вывода (I/O), которые соединены с контроллером 1360 I/O, могут быть соединены с компьютерной системой любым количеством средств, известных в области техники, например, посредством последовательного порта 1370. Например, последовательный порт 1370 или внешний интерфейс 1380 могут использоваться для соединения компьютерного устройства с глобальной сетью, такой как Интернет, мышью или сканером. Соединение через системную шину позволяет центральному процессору 1390 взаимодействовать с каждой подсистемой и управлять выполнением команд из системной памяти 1395 или жесткого диска 1330, а также выполнять обмен информацией между подсистемами. Системная память 1395 и/или жесткий диск 1330 может осуществить машиночитаемый носитель.

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

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

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

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

Используемое здесь единственное число терминов подразумевает значение "по меньшей мере один", если специально не указано иначе.

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

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

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

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

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

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

6. Способ по п.5, в котором отправка запроса эмитенту включает в себя отправку запроса на мобильный шлюз оплаты, причем мобильный шлюз перенаправляет запрос эмитенту.

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

8. Способ по п.7, в котором эфирный канал связи представляет собой сеть сотовой телефонии.

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

10. Способ по п.9, в котором до определения, достиг ли счетчик порогового значения, принимают запрос для проведения транзакции.

11. Способ по п.10, в котором транзакция является автономной транзакцией.

12. Способ по п.9, в котором операция, заданная в сценарии, не сбрасывает счетчик.

13. Способ по п.9, в котором пороговое значение является объединенным максимальным значением для всех автономных транзакций.

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

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