СПОСОБ И СИСТЕМА ДЛЯ МОБИЛЬНОЙ ИДЕНТИФИКАЦИИ, ОСУЩЕСТВЛЕНИЯ КОММЕРЧЕСКИХ ТРАНЗАКЦИЙ И ОПЕРАЦИЙ ЗАКЛЮЧЕНИЯ СОГЛАШЕНИЙ Российский патент 2016 года по МПК H04W4/14 

ОБЛАСТЬ ТЕХНИКИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно другому варианту осуществления изобретения телекоммуникационный протокол является любым из следующих протоколов: USSD, SMS, MMS и HTTP.

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

Далее настоящее изобретение будет подробно описано со ссылкой на прилагаемые фигуры.

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

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

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

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

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

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

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

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

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

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

На Фиг.9 представлена блок-схема, иллюстрирующая способ с использованием VSMP согласно предпочтительному варианту осуществления настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

Другие функциональные средства заключаются в том, что сервер 101 обеспечивает VSMP (передачу коротких сообщений с высокой степенью защиты). VSMP является запатентованным инструментом защищенного обмена сообщениями, основанным на протоколе USSD. VSMP предоставляется пользователям 103 в качестве приложения на сервере 101. Сообщения VSMP направляют на мобильное устройство пользователя 103. Пользователь 103 может в течение времени активного сеанса ответить на сообщение VSMP при помощи нажатия на кнопку ответа в сообщении VSMP. Сообщение VSMP автоматически исчезнет с экрана мобильного устройства пользователя (без какого-либо вмешательства пользователя) после окончания времени активного сеанса. Это происходит из-за того, что сообщения VSMP не сохраняются в мобильном устройстве, а просто направляются на мобильное устройство во время сеанса по протоколу USSD. Если пользователь 103 не может ответить в течение времени активного сеанса, то пользователь 103 может организовать связь с сервером 101 по протоколу USSD, войти в сервер 101 и затем получить доступ к приложению VSMP, извлечь сообщение VSMP и после этого ответить.

Таким образом, сообщение VSMP может предотвратить неавторизованный просмотр его содержимого, поскольку оно содержит элемент защиты с применением паролей. Сообщение VSMP предназначено для конкретного пользователя 103 с уникальным универсальным идентификационным номером и, таким образом, только этот конкретный пользователь 103 с действительным универсальным идентификационным номером и паролем может просмотреть сообщение VSMP. Сообщения VSMP могут быть доступны в любой части земного шара до тех пор, пока существует сигнал сети GSM, где с сервером 101 могут быть установлены соединения по протоколу USSD. Соединения GPRS и Wi-Fi также не являются обязательными для работы VSMP. Кроме того, если пользователь 103 потеряет свой мобильный телефон, сообщения VSMP сохраняются на сервере 101 и, следовательно, могут быть извлечены.

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

Субъект регистрируется в системе 100 в качестве пользователя 103 посредством предоставления персональных данных, таких как номер мобильного телефона GSM, номер IMEI GSM. После этого сервер 101 назначает субъекту универсальный идентификационный номер. Персональные данные и универсальный идентификационный номер субъекта затем сохраняют во входных данных в базе 102 данных. Субъект может также загрузить свою идентификационную информацию в базу 102 данных. Эта идентификационная информация может, кроме прочего, содержать: информацию об удостоверении личности, паспортные данные, информацию о членстве, медицинскую карту, водительские права и информацию о регистрации транспортного средства. Эта идентификационная информация может быть на основе текста или может быть изображением, например, изображением удостоверения личности или паспорта. База 102 данных может также содержать соглашения или контракты, загруженные субъектом.

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

После этого счета каких-либо предпочтительных или используемых по умолчанию валют (например, счет в Сингапуре, счет в Малайзии и счет в США) задают для субъекта и сохраняют в базе 102 данных. Сервер 101 назначает субъекту пароль для использования в стандартных ситуациях, а также предпочтительно пароль для использования в экстренных ситуациях. Необязательно, также для субъекта назначают пароль для проверки. Эти пароли могут быть изменены.

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

Регистрация компании в системе происходит посредством предоставления корпоративных данных, основных и дополнительных пользователей (т.е. корпоративных пользователей), а также номеров мобильных телефонов GSM, номеров IMEI GSM всех корпоративных пользователей. После этого сервер 101 назначает каждому корпоративному пользователю универсальный идентификационный номер. Персональные данные и универсальные идентификационные номера корпоративных пользователей затем сохраняют во входных данных в базе 102 данных. Корпоративный пользователь может также загрузить свою идентификационную информацию в базу 102 данных. Эта идентификационная информация может, кроме прочего, содержать: информацию об удостоверении личности, паспортные данные, информацию о членстве, медицинскую карту, водительские права и информацию о регистрации транспортного средства. Эта идентификационная информация может быть на основе текста или может быть изображением, например, изображением удостоверения личности или паспорта. База 102 данных может также содержать соглашения или контракты, загруженные корпоративным пользователем.

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

После этого счета каких-либо предпочтительных или используемых по умолчанию валют (например, счет в Сингапуре, счет в Малайзии и счет в США) задают для каждого корпоративного пользователя и сохраняют в базе 102 данных. Сервер 101 назначает каждому корпоративному пользователю пароль для использования в стандартных ситуациях, а также предпочтительно пароль для использования в экстренных ситуациях. Необязательно, также для субъекта назначают пароль для проверки. Эти пароли могут быть изменены.

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

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

Сервер регистрирует особенности мобильного устройства пользователя, такие как номер мобильного телефона и номер IMEI.

На этапе 202 сервер направляет приложение «Основное меню» на мобильное устройство пользователя при помощи протокола USSD. Приложение «Основное меню» будет выглядеть как интерфейс на мобильном устройстве пользователя. Интерфейс будет содержать подменю, из которых пользователь может выбрать. Подменю могут быть следующими: «Наличные деньги», «Счет», «Идентификационная информация», «Соглашение», «Передача коротких сообщений с высокой степенью защиты», «Рекламные объявления», «Валютный курс», «MGT пароль» и «Помощь».

На этапе 203 пользователь перемещается к приложению «NRIC» при помощи выбора подменю «Идентификационная информация» и выбора приложения «NRIC».

На этапе 204 пользователь вводит свой пароль и свой универсальный идентификационный номер в приложение «NRIC», после чего нажимает «ОК», тем самым, осуществляя посылку этой информации на сервер при помощи протокола USSD. Сервер обрабатывает полученную информацию как запрос информации идентификационной карты.

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

На этапе 206 сервер направляет визуальное представление данных, которое содержит информацию идентификационной карты, на мобильное устройство пользователя через телекоммуникационный протокол. Информация идентификационной карты может содержать следующее: универсальный идентификационный номер, номер идентификационной карты, фамилию и имя, национальность, расу, пол, дату рождения, дату выдачи. Телекоммуникационный протокол может быть одним из следующих протоколов: USSD, SMS, MMS (служба отправки мультимедийных сообщений) и HTTP (протокол передачи гипертекстовых документов). Визуальное представление данных также содержит для пользователя опцию, позволяющую осуществить выбор, если пользователь желает получить изображение его идентификационной карты через MMS.

На этапе 207 пользователь запрашивает отправку изображения его идентификационной карты.

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

Согласно другому варианту осуществления изобретения пользователь может использовать приложение «NRIC» для извлечения идентификационной информации другого пользователя. Согласно дальнейшим вариантам осуществления пользователь может вместо выбора приложения «NRIC» выбрать из подменю «Идентификационная информация» приложение «Паспорт», приложение «Членство», приложение «Медицинская карта», приложение «Водительские права» или приложение «Регистрация транспортного средства», если пользователь желает получить идентификационную информацию, касающуюся паспорта, членства, медицинской карты, водительских прав или регистрации транспортного средства.

На Фиг.3 представлена операция заключения соглашения, инициируемая лицом, делающим предложение, для лица, которому делается предложение. Как лицо, делающее предложение, так и лицо, которому делается предложение, могут быть субъектами или корпоративными пользователями. На этапе 301 лицо, делающее предложение, загружает соглашение или контракт на сервер через интернет-сайт. Лицо, делающее предложение, выполняет это посредством доступа на интернет-сайт при помощи браузера и ввода своего пароля для использования в стандартных ситуациях и универсального идентификационного номера. После этого лицо, делающее предложение, переходит к URL (унифицированный указатель ресурса) загрузить соглашение, а затем загружает соглашение посредством прикрепления соглашения (в формате PDF, Word или другом формате документа) и нажимает загрузить.

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

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

На этапе 304 сервер направляет приложение «Основное меню» на мобильное устройство лица, делающее предложение, при помощи протокола USSD. Приложение «Основное меню» будет выглядеть как интерфейс на мобильном устройстве лица, делающего предложение. Интерфейс будет содержать подменю, из которых лицо, делающее предложение, может выбрать. Подменю могут быть следующими: «Наличные деньги», «Счет», «Идентификационная информация», «Соглашение», «Передача коротких сообщений с высокой степенью защиты», «Рекламные объявления», «Валютный курс», «MGT пароль» и «Помощь».

На этапе 305 лицо, делающее предложение, перемещается к приложению «Предложение» при помощи выбора подменю «Соглашение» и выбора приложения «Предложение».

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

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

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

На этапе 309 лицо, делающее предложение, подтверждает предложение и подтверждение отправляется на сервер через протокол USSD.

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

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

После прочтения соглашения лицом, которому делается предложение, лицо, которому делается предложение, должно нажать на кнопку «Сгенерировать номер подтверждения» в качестве индикации подтверждения. Нажатие на кнопку «Сгенерировать номер подтверждения» не является индикацией того, что лицо, которому делается предложение, согласилось или не согласилось с соглашением. Оно просто указывает на то, что лицо, которому делается предложение, прочло соглашение.

После нажатия лицом, которому делается предложение, на кнопку «Сгенерировать номер подтверждения», на этапе 402 сервер генерирует номер подтверждения и направляет его в сообщении VSMP через протокол USSD на номер мобильного устройства лица, которому делается предложение, причем этот номер мобильного устройства извлечен из базы данных, поскольку он прикреплен к универсальному идентификационному номеру лица, которому делается предложение. Одновременно, номер подтверждения будет также отображен в браузере лица, которому делается предложение. Поскольку сообщение VSMP исчезнет с экрана мобильного устройства лица, которому делается предложение, после окончания времени активного сеанса, в случае, если лицо, которому делается предложение, забудет номер подтверждения, сервер предоставляет приложение «Входящая почта» и приложение «Исходящая почта» для того, чтобы лицо, которому делается предложение, могло просмотреть последние сообщения VSMP.

На этапе 403 лицо, которому делается предложение, использует свое мобильное устройство для установления связи по протоколу USSD с сервером. Это может быть выполнено лицом, которому делается предложение, либо путем звонка на конкретный номер телефона, либо путем посылки последовательности сокращенного кода через протокол USSD. Сервер регистрирует особенности мобильного устройства лица, которому делается предложение, такие как номер мобильного телефона/устройства и номер IMEI.

На этапе 404 сервер направляет приложение «Основное меню» на мобильное устройство лица, которому делается предложение, при помощи протокола USSD.

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

На этапе 405 лицо, которому делается предложение, перемещается к приложению «Согласие» при помощи выбора подменю «Соглашение» и выбора приложения «Согласие».

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

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

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

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

На этапе 410 сервер обрабатывает и обновляет базу данных.

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

На Фиг.5 представлен сценарий, когда соглашение не принимается лицом, которому делается предложение. Этапы 501, 502, 503, 504 являются зеркальным отражением этапов 401, 402, 403 и 404, представленных на Фиг.4.

На этапе 505 лицо, которому делается предложение, перемещается к приложению «Несогласие» при помощи выбора подменю «Соглашение» и выбора приложения «Несогласие».

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

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

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

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

На этапе 510 сервер обрабатывает и обновляет базу данных.

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

На Фиг.6 представлена платежная транзакция между покупателем (индивидуальным пользователем) и продавцом (корпоративным пользователем). На стадии 601 покупатель использует свое мобильное устройство для установления связи по протоколу USSD с сервером. Это может быть выполнено покупателем либо путем звонка на конкретный номер телефона, либо путем посылки последовательности сокращенного кода через протокол USSD. Сервер регистрирует особенности мобильного устройства покупателя, такие как номер мобильного телефона/устройства и номер IMEI.

На этапе 602 сервер направляет приложение «Основное меню» на мобильное устройство покупателя при помощи протокола USSD. Приложение «Основное меню» будет выглядеть как интерфейс на мобильном устройстве покупателя. Интерфейс будет содержать подменю, из которых пользователь может выбрать. Подменю могут быть следующими: «Наличные деньги», «Счет», «Идентификационная информация», «Соглашение», «Передача коротких сообщений с высокой степенью защиты», «Рекламные объявления», «Валютный курс», «MGT пароль» и «Помощь».

На этапе 603 покупатель перемещается к приложению «Направление платежа» (модуль направления платежа) при помощи выбора подменю «Наличные деньги» и выбора приложения «Направление платежа».

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

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

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

На этапе 607 покупатель подтверждает осуществление платежа, и подтверждение отсылается на сервер через протокол USSD.

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

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

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

Кроме того, сервер содержит приложение «Возврат» (модуль возврата), который работает противоположно приложению «Направление платежа», когда продавец возвращает денежные средства обратно покупателю.

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

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

На этапе 702 сервер направляет приложение «Основное меню» на мобильное устройство плательщика при помощи протокола USSD. Приложение «Основное меню» будет выглядеть как интерфейс на мобильном устройстве плательщика. Интерфейс будет содержать подменю, из которых пользователь может выбрать. Подменю могут быть следующими: «Наличные деньги», «Счет», «Идентификационная информация», «Соглашение», «Передача коротких сообщений с высокой степенью защиты», «Рекламные объявления», «Валютный курс», «MGT пароль» и «Помощь».

На этапе 703 плательщик перемещается к приложению «XFER-TO» (модуль перевода) при помощи выбора подменю «Наличные деньги» и выбора приложения «XFER-TO».

На этапе 704 плательщик вводит свой пароль, сумму платежа в долларах и центах, валюту платежа и универсальный идентификационный номер получателя в приложение «XFER-TO», после чего нажимает «ОК.», тем самым, осуществляя посылку этой информации на сервер при помощи протокола USSD. Сервер обрабатывает полученную информацию как запрос на осуществление платежа.

Плательщик может ввести валюту платежа посредством набора на клавиатуре соответствующего кода страны из трех цифр. Например, если плательщик желает, чтобы валюта платежа была «USD», он наберет на клавиатуре 001, или если он желает, чтобы валюта платежа была «SGD», он наберет на клавиатуре 065. Для стран, которые совместно используют общий код страны, может быть разработан специальный код. Плательщик может только ввести валюту платежа, которую он уже имеет на счету. Например, если плательщик имеет только счет в USD и счет в SGD, то плательщик может выбрать только USD или SGD в качестве валюты платежа.

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

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

На этапе 707 плательщик подтверждает осуществление платежа, и подтверждение отсылается на сервер через протокол USSD.

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

На этапе 709 сервер направляет на мобильное устройство плательщика через телекоммуникационный протокол новый баланс счета плательщика и номер транзакции.

На этапе 710 сервер направляет на мобильное устройство получателя через телекоммуникационный протокол универсальный идентификационный номер плательщика, имя плательщика, сумму платежа с его валютой и номер транзакции для получателя с тем, чтобы выполнить приложение «CLCT-FR» (модуль получения).

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

На этапе 802 получатель направляет приложение «Основное меню» на мобильное устройство получателя при помощи протокола USSD. Приложение «Основное меню» будет выглядеть как интерфейс на мобильном устройстве получателя. Интерфейс будет содержать подменю, из которых пользователь может выбрать. Подменю могут быть следующими: «Наличные деньги», «Счет», «Идентификационная информация», «Соглашение», «Передача коротких сообщений с высокой степенью защиты», «Рекламные объявления», «Валютный курс», «MGT пароль» и «Помощь».

На этапе 803 получатель перемещается к приложению «CLCT-FR» при помощи выбора подменю «Наличные деньги» и выбора приложения «CLCT-FR».

На этапе 804 получатель вводит свой пароль, свой универсальный идентификационный номер, номер транзакции и универсальный идентификационный номер плательщика в приложение «CLCT-FR», после чего нажимает «ОК», тем самым, осуществляя посылку этой информации на сервер при помощи протокола USSD. Сервер обрабатывает полученную информацию как запрос получения переведенного количества.

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

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

На этапе 807 получатель подтверждает то, что он желает получить сумму платежа, и подтверждение отсылается на сервер через протокол USSD.

На этапе 808 сервер списывает сумму платежа с баланса счета для хранения и зачисляет на баланс счета получателя указанную сумму платежа.

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

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

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

Если приложение «CLCT-FR» не будет выполнено в течение некоторого периода времени выполнения приложения «XFER-TO», то сумма платежа будет автоматически зачислена обратно на счет плательщика. Например, указанный период времени может составлять 24 часа, причем сервер может устанавливать любой период времени.

Сервер содержит тандем из приложений: приложение «РРОО» (модуль предварительной оплаты по заказу) и приложение «CLOD» (модуль запроса на доставку), которые работают аналогично тандему из приложения «XFER-TO» и приложения «CLCT-FR», за исключением того, что в приложение «РРОО» валюта платежа является используемой по умолчанию валютой плательщика, причем валюта платежа не может быть уточнена плательщиком, а номер транзакции направляют только к плательщику, а не к получателю (в отличие от XFER-TO, где номер транзакции направляют, как плательщику, так и получателю). Таким образом, плательщик может не сообщить номер транзакции и, следовательно, отложить выполнение получателем приложения «CLOD» для получения денежных средств до тех пор, пока получатель не передаст ему товары.

На Фиг.9 представлен сценарий, когда используют VSMP. Продавец (индивидуальный пользователь) желает послать звуковой сигнал покупателю (индивидуальный пользователь) с тем, чтобы сообщить ему, что его еда готова и что он может прийти и забрать ее. На этапе 901 продавец использует мобильное устройство для установления связи по протоколу USSD с сервером. Это может быть выполнено продавцом, либо путем звонка на конкретный номер телефона, либо путем посылки последовательности сокращенного кода через протокол USSD. Сервер регистрирует особенности мобильного устройства продавца, такие как номер мобильного телефона и номер IMEI.

На этапе 902 сервер направляет приложение «Основное меню» на мобильное устройство продавца при помощи протокола USSD. Приложение «Основное меню» будет выглядеть как интерфейс на мобильном устройстве продавца. Интерфейс будет содержать подменю, из которых продавец может выбрать. Подменю могут быть следующими: «Наличные деньги», «Счет», «Идентификационная информация», «Соглашение», «Передача коротких сообщений с высокой степенью защиты», «Рекламные объявления», «Валютный курс», «MGT пароль» и «Помощь».

На этапе 903 продавец перемещается к приложению «послать VSMP» при помощи выбора подменю «Передача коротких сообщений с высокой степенью защиты» и выбора приложения «Послать VSMP».

На этапе 904 продавец вводит свой пароль, свой контактный номер, универсальный идентификационный номер покупателя, а также текстовое сообщение в приложение «Послать VSMP», после чего нажимает «ОК», тем самым, осуществляя посылку этой информации на сервер при помощи протокола USSD. Сервер обрабатывает полученную информацию как запрос отправки сообщения VSMP. Текстовое сообщение будет образовывать текст в сообщении VSMP. Текстовое сообщение может быть введено с помощью клавиатуры продавцом или выбрано из подготовленных шаблонов.

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

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

На этапе 907 продавец подтверждает, что сообщение VSMP должно быть послано покупателю.

На этапе 908 сервер направляет на мобильное устройство продавца сообщение VSMP через протокол USSD.

На этапе 909 сервер направляет на мобильное устройство покупателя сообщение VSMP через протокол USSD.

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

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

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

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

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

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

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

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

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

5. Способ по любому из пп.1-4, в котором телекоммуникационный протокол является любым из следующих протоколов: USSD, SMS, MMS и HTTP.

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