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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

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

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

(a) Пользователь платит поставщику услуг за определенные услуги покупки билетов/обработки платежей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Патент WO 03/038719 описывает способ, когда виртуальная финансовая карта разового использования формируется в офлайн-режиме для Интернет-платежа или бесконтактной транзакции типа EMV-MSD (данные магнитной полосы). Но такое решение не может использоваться для формирования виртуальной финансовой карты разового использования для транзакции с бесконтактным чипом EMV и ПИН, так как полученный ключ должен рассчитываться со стороны сервера и отправляться на приложение мобильного телефона до попытки совершения платежа (чтобы избежать хранения ключа эмитента в мобильном телефоне); поэтому формирование виртуальной финансовой карты разового использования для транзакции с бесконтактным чипом EMV и ПИН требует обработки онлайн-/офлайн-процесса для каждой сформированной карты. Последний вариант реализации соответствует требованию онлайн-обновления, но также преимущественно соотносит мобильную вторую часть элемента идентификационных данных, сформированную в офлайн-режиме, со значением транзакции и ПИН пользователя, создавая таким образом удобное и весьма надежное платежное решение.

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

- средства регистрации для регистрации пользователей услуг покупки билетов/обработки платежей,

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

- средства формирования идентификационных данных для формирования на модуле сервера покупки билетов/обработки платежей на основании предоставленных прав покупки билетов/обработки платежей идентификационных данных покупки билетов/обработки платежей для использования зарегистрированным пользователем; средства передачи для их отправки на мобильный телефон зарегистрированного пользователя; и средства приема и хранения для получения идентификационных данных на мобильном телефоне и их хранения для использования в транспортной бесконтактной системе покупки билетов (или для использования при мобильных бесконтактных платежах, в случае идентификационных данных для платежей),

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фиг. 1.а представляет собой схему, которая в общем иллюстрирует основные функциональные блоки изобретения в качестве дополнения к традиционной транспортной системе; на данном чертеже представлена традиционная транспортная система 300а от поставщика услуг, поддерживающего бесконтактные смарт-карты (поэтому у пользователя этой системы может быть в наличии бесконтактная смарт-карта для доступа к транспортным услугам через устройства контроля доступа к покупке билетов 400а). С помощью канала веб-дистрибуции 200а пользователи 100а могут совершить необходимые приготовления для заключения договора, по меньшей мере, по одной услуге для получения, по меньшей мере, одного транспортного титра (профиля), связанного с такой, по меньшей мере, одной услугой, и для загрузки/перегрузки, по меньшей мере, одного транспортного титра. В данном общем примере канал веб-дистрибуции принадлежит банку-партнеру, и пользователь также является клиентом этого банка, поэтому он может совершать платежи через веб-страницу с помощью электронной подписи, предоставленной банком.

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

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

На этапе (1) пользователь загружает приложение мобильного телефона для покупки билетов из магазина приложений 700 на свой мобильный телефон с бесконтактной технологией.

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

На этапе (4) модуль регистрации модуля сервера покупки билетов присваивает транспортное право пользователю (представленному на рис. 1.b как карта «А» на модуле сервера) на основании полученной справки о транспортном праве, и данная информация хранится в базе данных модуля сервера покупки билетов (справка о клиенте о А). Затем модуль регистрации отправляет запрос на модуль идентификационных данных пользователя для формирования одного элемента идентификационных данных (представленного на рис. 1.b как карта «VMC(A)» на модуле сервера), который связывается со справкой о транспортном клиенте и транспорным правом в базе данных модуля сервера покупки билетов (справка о клиенте о А о VMC(A)). У сформированного элемента идентификационных данных есть срок годности, поэтому после его истечения они не могут быть использованы.

На этапе (5) модуль идентификационных данных пользователя запрашивает у модуля безопасности код активации; формируется код активации с заданным сроком годности посредством модуля безопасности и сохраняется в базе данных модуля сервера покупки билетов (справка о клиенте ⇔ A ⇔ VMC(A) ⇔ АС). Код активации не может быть использован после истечения срока годности. На этапе (6) код активации отправляется с модуля регистрации в традиционную транспортную систему в канал веб-дистрибуции и отображается у пользователя.

На этапе (7) пользователь вводит код активации в приложение мобильного телефона для покупки билетов, а на этапе (8) мобильный телефон отправляет на модуль безопасности модуля сервера покупки билетов, например, через https, [код активации и hash(идентификационный номер мобильного телефона и код активации)].

На этапе (9) модуль безопасности проверяет правильность кода активации; затем модуль безопасности сохраняет хеш-значение в базе данных модуля сервера покупки билетов, и теперь ссылки выглядят следующим образом: справка о клиенте ⇔ А ⇔ VMC(A) ⇔ АС ⇔ hash(ID&AC).

На этапе (10) карта «А» подвергается предварительной персонализации в приложении мобильного телефона.

Предварительная персонализация относится к этапу, предшествующему персонализации; и предварительная персонализация/персонализация карты «А» относится к предварительной персонализации/персонализации приложения мобильной бесконтактной покупки билетов из изобретения для работы в «режиме имитации карты» для услуг мобильной бесконтактной покупки билетов, что аналогично работе приложения для покупки билетов на основе SIM-карты в «режиме имитации карты» для услуг мобильной бесконтактной покупки билетов (например, имитация базовой технологии карт mifare DESFIRE). Полная персонализация карты «А» в приложении мобильного телефона для покупки билетов требует загрузки идентификационных данных с модуля сервера покупки билетов на приложение мобильного телефона для покупки билетов, как описано ниже.

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

На этапе (11) пользователю предлагается выбрать персональный идентификационный номер (ПИН) для услуг мобильной бесконтактной покупки билетов. Значение ПИН не хранится в приложении мобильного телефона для покупки билетов, а безопасным образом отправляется на этапе (12) в модуль безопасности модуля сервера покупки билетов, наряду с одноразовым паролем (ОРП), рассчитанным с помощью значения ПИН (и кода активации и значений hash(AC&ID), чтобы присвоить на модуле сервера покупки билетов выбранный ПИН и результат ОРП правильной справке о клиенте).

На этапе (13) модуль безопасности хранит ПИН в базе данных модуля сервера покупки билетов, наряду с ключами и параметрами для расчета ОРП на основе ПИН. Все такие сохраненные данные обозначены в базе данных фиг. 1.b как данные «ОРП(ПИН)». Теперь в базе данных хранятся следующие ссылки и данные: справка о клиенте ⇔ А ⇔ VMC(A) ⇔ АС о hash(ID&AC) ⇔ ΟΡΠ(ΡΙΝ).

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

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

Зарегистрированный пользователь может на этапе (15) использовать мобильный телефон для доступа к транспортным услугам. На этапе (15) пользователь вводит свой ПИН-код в приложение мобильного телефона для покупки билетов перед попыткой доступа к системе контроля доступа для покупки билетов 400; поэтому адаптация мобильного телефона для каждого бесконтактного доступа для покупки билетов также требует ввода персонального идентификационного кода (ПИН) пользователем в приложении мобильного телефона для покупки билетов.

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

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

Данный вариант реализации берет в качестве примера фиг. 1.b с некоторыми изменениями, которые описаны ниже. Этапы (1), (2) и (3) такие же, как на фиг. 1.b.

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

Поэтому на этапе (4) модуль сервера покупки билетов присваивает транспортное право пользователю (представленному на рис. 1.с как карта «А» на модуле сервера), связанное с набором идентификационных данных (представленным на рис. 1.с как карты «VMC(A)i» - «VMC(A)_n» на модуле сервера) и справкой о транспортном клиенте, и сохраняет эти связи в базе данных модуля сервера покупки билетов (справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…n).

На этапе (5) формируется код активации, который сохраняется в базе данных модуля сервера покупки билетов (справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…no АС). На этапе (6) код активации отправляется с модуля регистрации в традиционную транспортную систему в канал веб-дистрибуции и отображается у пользователя.

Этапы (7), (8) и (9) такие же, как на фиг. 1.b, и ссылки после этапа (9) представлены следующим образом: справка о клиенте ⇔ А ⇔ VMC(A)i, i=1…n ⇔ AC ⇔ hash(ID&AC).

На этапе (10) карта «А» подвергается предварительной персонализации в приложении мобильного телефона.

Как в варианте реализации