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

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

Иллюстрации

Показать все

Реферат

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

Настоящее изобретение относится к способу и системе, в которых используют протокол 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 лицо, которому делается предложение, вводит свой пароль, номер подтверждения, универсальный идентификационный номер лица, делающего пред