Способ автоматического зачисления внесенных денежных средств при возникновении сбоев

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

 

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

[0001] Настоящее техническое решение, в общем, относится к области обработки данных для осуществления транзакций по внесению денежных средств (ДС) при взаимодействии пользователей с устройствами самообслуживания (УС), а в частности, к способам осуществления транзакций по внесению ДС при возникновении различных сбоев в канале УС при обмене данными с сервером обработки транзакций.

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

[0002] Из уровня техники известна система и способ для адаптивной диагностики сбоев в канале УС в режиме тонкого клиента (патент US 8108726B2, 31.01.2012, Bank of America Corporation). В данном решении осуществляют адаптивную диагностику сбоев в канале УС при осуществлении транзакций по внесению ДС. Особенностью решения является то, что УС включает в себя тонкий клиент и адаптивную диагностику осуществляют в режиме тонкого клиента. В данном решении при возникновении сбоев в канале УС пользователю сообщается о сбое и указывается причина сбоя, а также выдается информация о ближайших исправных УС. Кроме того, УС может координировать информацию о ближайших исправных УС посредством мобильного телефона пользователя.

[0003] Также известна система и способ обнаружения сбоев в банкомате (заявка US 2007131757 A1, 14.06.2007, NCR Corporation). В данном решении при осуществлении транзакций, в том числе транзакций по внесению ДС генерируют журнал транзакций, в который записываются все сведения о транзакции. Между банкоматом и компьютером устанавливается связь. Журнал транзакций генерируется в формате на основе XML. В случае возникновения сбоев транзакция осуществляется на основании сведений о транзакции, содержащихся в журнале транзакций.

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

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

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

[0006] Техническим результатом является расширение функционала УС, за счет реализации механизма автоматизированной обработки транзакционных запросов при возникновении проблем в канале УС при обмене данными с сервером обработки транзакций.

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

[0008] В предпочтительном варианте осуществления заявленного решения представлен способ автоматического зачисления внесенных денежных средств (ДС) при возникновении сбоев, включающий в себя этапы, на которых:

- получают в канале устройства самообслуживания (УС) пользовательский запрос на выполнение транзакции по приему (ДС), содержащий параметры транзакции;

- направляют предварительный транзакционный запрос на удаленный сервер для проверки параметров транзакции;

- получают ответ от сервера и сохраняют его в УС;

- инициируют прием УС ДС согласно параметрам транзакции;

- фиксируют в ходе приема данные принимаемых ДС;

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

- автоматически инициируют опрос удаленного сервера УС;

и

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

[0009] В одном из частных вариантов реализации способа при формировании пользовательского запроса осуществляется верификация пользователя УС.

[0010] В другом частном варианте реализации способа верификация осуществляется с помощью PIN-кода, биометрической информации, графической информации или удаленного устройства пользователя или их сочетания.

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

[0012] В другом частном варианте реализации способа графическое изображение представляет собой фотоизображение пользователя.

[0013] В другом частном варианте реализации способа данные принимаемых ДС представляют собой код валюты, номинал денежной единицы, количество принятых УС денежных единиц или данные разбивки купюр по группам.

[0014] Заявленное решение предпочтительно осуществляется за счет системы автоматического зачисления внесенных ДС при возникновении сбоев, которая содержит УС и связанный с ним удаленный сервер, причем

УС выполнено с возможностью

получать пользовательский запрос на выполнение транзакции по приему ДС;

сохранять информацию о принятых ДС;

передавать информацию о транзакции на удаленный сервер;

удаленный сервер выполнен с возможностью проверять параметры транзакции, поступившей от УС;

сохранять информацию о транзакции и принятых ДС;

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

[0015] В частном варианте реализации системы УС представляет собой банкомат или терминал.

[0016] В другом частном варианте реализации системы УС связано с удаленным сервером посредством проводной или беспроводной вычислительной сети.

[0017] В другом частном варианте реализации системы проводная сеть представляет собой ЛВС (LAN), WAN, PAN или Интранет.

[0018] В другом частном варианте реализации си беспроводная сеть представляет собой WAN, Интернет, WLAN, WMAN или GSM.

[0019] В другом частном варианте реализации системы удаленный сервер представляет собой облачный сервер.

[0020] В другом частном варианте реализации си УС содержит средства верификации пользователя.

[0021] В другом частном варианте реализации системы средства верификации УС выбираются из группы: ПИН-пад, сенсорный дисплей, камера, биометрический сканер, микрофон или их сочетания.

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

[0022] Признаки и преимущества настоящего технического решения станут очевидными из приводимого ниже подробного описания изобретения и прилагаемых чертежей, на которых:

[0023] Фиг. 1 иллюстрирует блок-схему выполнения заявленного способа.

[0024] Фиг. 2 иллюстрирует

[0025] Фиг. 3 иллюстрирует пример системы обмена данными между УС и удаленным сервером.

[0026] Фиг. 4 иллюстрирует пример схемы УС.

[0027] Фиг. 5 иллюстрирует пример схемы удаленного сервера.

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

[0028] В настоящем описании будут использоваться следующие термины и определения.

[0029] В данном техническом решении под системой подразумевается, в том числе компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций).

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

[0031] Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройств хранения данных. В роли устройства хранения данных могут выступать, но не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.

[0032] TSN (Transaction Serial Number) - номер последней успешно завершенной транзакции.

[0033] NDC протокол (NCR Direct Protocol) - протокол обмена данными между УС и сервером обработки транзакций.

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

[0035] Банковское устройство самообслуживания (УС) - программно-технический комплекс, предназначенный для автоматизированной выдачи и/или приема наличных ДС как с использованием платежных карт, так и без, а также выполнения других операций, в том числе оплаты товаров и услуг, составления документов, подтверждающих соответствующие операции. Банковские устройства самообслуживания подразделяются на два типа в зависимости от того, поддерживают ли они функцию выдачи наличных денег или нет. Если функция поддерживается, то УС является ATM (англ. automated teller machine), или банкоматом, иначе - NCS (non-cash systems), или терминалом для безналичных операций.

[0036] Программное обеспечение (ПО) или программная логика - программа или множество программ, используемых для управления УС и серверными средствами для осуществления требуемых операций.

[0037] На Фиг. 1 представлены основные шаги заявленного способа автоматизированного внесения ДС (100). На первом этапе (101) УС получает запрос от пользователя по выполнению финансовой транзакции по внесению ДС. Запрос содержит в себе, как правило, идентификатор счета зачисления ДС, сумму ДС, время начала запроса на выполнение операции. Запрос также содержит идентификатор транзакционного запроса (TrID).

[0038] Запрос дополнительно может содержать идентификатор УС (Logical Unit Number), данные с дорожек карты, данные о предыдущих транзакциях, данных с буферов суммы, пин-блока, нажатий функциональных клавиш (FDK буфер).

[0039] Значение TrID является уникальным для каждого транзакционного запроса (значение TrID обновляется при каждом переходе на транзакционный стейт в сценарии УС). Если обычный транзакционный запрос получен в новом формате, поле TrID запроса не пусто, его значение сохраняется в БД удаленного сервера в составе транзакционных данных выполняемых операций.

[0040] Во все транзакционные запросы добавляется поле «TrID», например, с идентификатором «3», состоящее из 12 символов.

[0041] Для первичного запроса данные поля формируются следующим образом: ГMMДДЧЧMMNNN (где Г - последняя цифра текущего года, ММ - номер месяца, ДД - день, ЧЧ - час, ММ - минута, NNN - последние 3 цифры текущего значения Accumulated Transaction Count, что обеспечивает уникальность значения TrID для данного УС). Значение Accumulated Transaction Count определяет общее количество обнаруженных попыток выполнения транзакций с момента установки УС или после того как энергонезависимая память УС полностью занята. Счетчик сбрасывается до 0 после 9999999 транзакций.

[0042] Для повторного запроса значение поля «TrID» должно повторять значение, сформированное в момент первичного запроса.

[0043] В каждый момент времени УС находится в одном из следующих режимов работы:

Power Up - загрузка;

Offline - нет связи с сервером, осуществляется подключение;

Supervisor - работает инкассатор или сервис-инженер;

Out of service - УС не работает, в связи с неисправностью, исчерпанием денежных средств, или принудительным переводом УС в указанный режим;

[0044] In service - основной режим работы УС. В режиме In service УС находится в одном из состояний (стейт), с номером от 001 до 999, и 25 символьной строкой-описанием.

[0045] Первый символ этой строки - тип стейта (обозначаются буквами A..Z, а так же a..z и некоторыми символами (,'.?)), который определяет совокупность. Остальные 24 символа - это 8 десятичных 3-значных чисел, каждое из которых является определенной настройкой стейта (номер экрана для показа, условия перехода на стейт, список действий). Стейтов одного типа может быть любое количество.

[0046] Переходя по всем этим стейтам, рано или поздно доходят до стейта взаимодействия с удаленным сервером - стейта I (Transaction Request State). На этом стейте формируется запрос из данных, собранных на прошлых стейтах, и отправляется на сервер. Данные разделяются символом разделителем. Удаленный сервер получает запрос и анализирует буфер FDK - именно по содержимому этого буфера удаленный сервер определяет необходимые операции, исполнение которых запрашивает УС. После чего, в зависимости от принятого решения, отсылает ответ, в котором содержатся:

^~ идентификатор действия, которое нужно совершить;

^~ номер экрана, который нужно при этом действии показывать;

^~ содержимое чека, если чек нужно напечатать;

^~ стейт на который нужно перейти по завершению действия.

[0047] После того как УС фиксирует полученную сумму ДС, выполняется определение и сохранение следующих данных:

^~ сумма принятых банкнот;

^~ код валюты;

^~ количество принятых банкнот с разбивкой по типам.

[0048] Указанные на этапе (101) данные транзакционной операции обрабатываются логикой УС (102) и формируются для передачи на удаленный сервер для выполнения транзакции (103).

[0049] Согласно Фиг. 2 после получения ДС УС и записи параметров суммы ДС, логикой УС осуществляется формирование предварительного транзакционного запроса для отправки на сервер (201).

[0050] Внесение ДС в УС осуществляется покупюрно и фиксация данных ДС выполняется при приеме ДС модулем приема наличных средств (МПН). МПН может выполняться Escrow типа (предварительное депонирование купюр).

[0051] Сформированный предварительный запрос посылается на сервер (202) после внесения определенной суммы ДС. Это может происходить после обработки параметров каждой купюры, либо после получения нескольких купюр или после получения всей суммы ДС, указанной в транзакционном запросе на этапе (101).

[0052] Этот этап позволяет предварительно проверять устойчивость и работоспособность канала передачи данных между УС и сервером для выполнения транзакций.

[0053] Сервер в ответ на получение данных от УС (203) с текущим состоянием транзакции сохраняет полученные параметры. Параметры транзакции также сохраняются в памяти УС.

[0054] Сервер на этапе (203) также отсылает ответное сообщение, подтверждающее наличие канала связи, пригодного для выполнения дальнейшей транзакции.

[0055] Возвращаясь к Фиг. 1, на этапе (104) выполняется проверка канала связи для осуществления необходимой транзакции, введенной на этапе (101).

[0056] Если связь с сервером присутствует и УС получило всю необходимую сумму ДС для выполнения транзакционного запроса, то данные транзакции направляются на сервер, где обрабатываются и перечисляются на указанный в упомянутом запросе счет (этап 108).

[0057] В случае, когда на этапе (104) УС не получает ответа от сервера, то логика УС сохраняет параметры транзакции в момент отсутствия отклика от сервера (105) и активирует программный механизм сценария автоматического зачисления средств (106).

[0058] При выполнении этапа (106), как было указано выше, УС направляет и сохраняет параметры предварительного запроса, которое содержит параметр TSN и параметры полученного ответа от сервера (Transaction Reply) на запрос с соответствующем TSN, причем упомянутый запрос является последним перед фиксацией наличия сбоя в канале передачи данных между УС и сервером.

[0059] Выполнение этапа (106) осуществляется до момента получения отклика от сервера, что позволяет без участия пользователя выполнить транзакционный запрос на основании идентификатора счета, полученного на этапе (101), на который необходимо перевести ДС.

[0060] Выполнение этапа (106) активации автоматизированного исполнения транзакции осуществляется, в частности, если УС не получило ответ (Transaction Reply) от сервера (например, разрыв сетевого соединения, обесточивание УС), либо не смогло корректно разобрать отклик сервера, либо произошла ошибка проверки МАС-подписи транзакции. Для защиты целостности технического решения используется механизм макирования транзакции МАС-адресом. Для расчета и проверки МАС-адреса используется команда, на вход которой подаются данные, которые могут меняться в зависимости от настроек:

- способ расчета MAC, например, посредством ANSI Х9.19;

- тип ключа, которым шифруется хэш, например ZAK/TAK (должна быть возможность выбора типа ключа).

- данные, на которых рассчитывается хэш (поля сообщения, помеченные в xsd-схеме знаком ).

[0061] MAC ключ должен быть уникальным для каждого УС, причем контроль уникальности осуществляется на стороне сервера. При попытке ввести в веб-форму повторяющийся ключ, должно появляться предупреждение о несовпадении.

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

[0063] Сервер, со своей стороны, может инициировать отправку текущих счетчиков специализированной командой, в частности, Send supply counters. Если значение суммы ранее принятых банкнот больше нуля, то, наряду с информацией, предусмотренной протоколом NDC, на сервер будет отправлена от УС информация со значениями: сумма принятых банкнот, код валюты, количество принятых банкнот с разбивкой по типам. Эти данные также используются для выполнения транзакционной операции после восстановления канала связи с сервером.

[0064] Ниже в таблице 1 приведен пример данных, сохраненных в части идентификации суммы внесенных ДС и подтвержденных в полученном ответе от сервера. В указанной таблице отображен пример внесения 1750 рублей в УС.

[0065] Как представлено на Фиг. 3 общий принцип работы заявленного способа (100) осуществляется с помощью системы выполнения транзакций, которая реализуется за счет обработки формируемых в канале УС (300) пользовательских запросов и их последующей передачи по вычислительной сети (500) на удаленный сервер (400).

[0066] Сеть (500) может быть проводного или беспроводного типа, например, Интернет, Интранет, ЛВС, WAN, WLAN, GSM, GPRS, Wi-Fi и т.п.

[0067] На Фиг. 4 представлена общая схема УС (300) в виде банкомата или платежного терминала. УС (300) содержит объединенные с помощью универсальной шины (310) компоненты, такие как: процессор (301), память (302), средство сетевого взаимодействия (303), дисплей (304), органы управления (305), средство выдачи ДС (306) (в случае банкомата), средство приема ДС (307).

[0068] Процессор УС (301) выполняет все необходимые вычислительные операции при обработке транзакционных запросов. Память (302) может представлять одно или более устройств различного типа, таких как: ОЗУ, ПЗУ или их сочетания. В качестве ПЗУ может использоваться HDD, SSD диски, флэш-память и т.п. В памяти (302), как правило, хранится исполняемая процессором (301) программная логика, необходимая для реализации способа работы УС (300), и операционная система, организующая интерфейс взаимодействия и протоколы обработки данных.

[0069] В качестве средств сетевого взаимодействия (303) могут применяться устройства, обеспечивающие связь с удаленным сервером с помощью проводного или беспроводного типа связи, например, Ethernet карта (LAN), Wi-Fi модуль, GSM модем (2G, 3G, 4G, 5G) и т.п. Дополнительно могут использоваться средства обмена данными между УС (300) и пользователем (устройством пользователя), например, Bluetooth приемо-передатчик, NFC модуль, irDa и т.п.

[0070] Дисплей УС (304) служит для отображения графического интерфейса пользователь, а также при его исполнении в виде сенсорного дисплея, то также обеспечивает взаимодействие с пользователем и получения от него команд управления.

[0071] Органы управления УС (305) могут представлять собой клавиатуру, сенсорный дисплей, пин-пад, механические и сенсорные кнопки.

[0072] Средство выдачи ДС (306) представляет собой диспенсер. Диспенсер (306) может быть различного типа, например, вакуумный, спрей типа и т.п.

[0073] Дополнительно УС (300) может содержать средство для приема ДС (307) от пользователя.

[0074] Также, УС (300) может содержать считыватель банковских карт, камеру, один или более биометрических сенсоров, микрофон. Данные устройства, как по отдельности, так и в совокупности, могут применяться для идентификации и верификации пользователя. Пользователь может идентифицировать начало транзакционного запроса с помощью предоставления банковской карты в специальный ридер УС (300) и ввода пин-кода с помощью клавиатуры (305) или сенсорного дисплея (304).

[0075] Может применяться двухфакторная верификация пользователя с помощью камеры или биометрических сенсоров, например, сканера отпечатка пальца, сетчатки глаза или с помощью анализа голоса пользователя. С помощью камеры может фиксировать изображение пользователя УС (300) для последующей обработки и сравнения с эталонной идентифицирующей информацией владельца счета при иницииации транзакционной операции в УС (300).

[0076] УС (300) может также обеспечивать обмен идентификационной информацией в полностью бесконтактном режиме, с помощью заранее создаваемого идентификационного токена с помощью устройства пользователя, например, смартфона, планшета или ноутбука, и его последующей передачи по беспроводному каналу обмена информацией, например, Bluetooth, Wi-Fi, NFC, RFID и т.п., в УС (300) (как пример, данная технология раскрыта в источниках US 20110238573, US 20110066552).

[0077] Для усиления режима безопасного осуществления транзакции в канале УС (300) может применяться счетчик повторного выполнения операций, который по достижению заданного порога будет уведомлять пользователя, что ответ от сервера (400) еще не был получен и что информация о выполнении транзакционного запроса будет направлено пользователю по ее выполнению.

[0078] Передача данных на устройство пользователя, например, смартфон или планшет, осуществляется посредством стандартных средств и методов, таких как: SMS-сообщения, PUSH-уведомления, e-mail письмо и т.п. Заданный способ уведомления пользователя выбирается исходя из идентификационной информации, связанной с аккаунтом пользователя, например, его номером телефона, номером карты или биометрической информацией.

[0079] На Фиг. 5 представлена общая схема удаленного сервера (400). Сервер (400) предназначен для обработки запросов на исполнение транзакционных запросов по зачислению ДС, поступающих в канал УС (300).

[0080] В общем случае сервер (400) содержит такие компоненты, как: один или более процессоров (401), по меньшей мере одну память (402), средство хранения данных (403), интерфейсы ввода/вывода (404), средство сетевого взаимодействия (405).

[0081] Процессор (401) сервера выполняет основные вычислительные операции при его работе с УС (300). Процессор (401) исполняет необходимые машиночитаемые команды, содержащиеся в памяти (402).

[0082] Память (402), как правило, выполнена в виде ОЗУ и содержит необходимую логику работы операционной системы, механизма реверсалов и иную программную логику, обеспечивающую полноценный функционал работы сервера (400).

[0083] Средство хранения данных (403) может выполняться в виде HDD, SSD дисков, рейд массива, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средства (403) позволяют выполнять долгосрочное хранение различного вида информации, например, истории обработки транзакционных запросов (логов), идентификаторов пользователей и т.п.

[0084] Интерфейсы (404) представляют собой стандартные средства для подключения и работы с сервером (400), например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.

[0085] Выбор интерфейсов (404) зависит от конкретного исполнения сервера (400), который может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент и т.п.

[0086] Средства сетевого взаимодействия (405) выбираются из устройств, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств (405) обеспечивается организация обмена данными между сервером (400) и УС (300) по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.

[0087] Дополнительно сервер (400) может содержать средства В/В данных, например, клавиатура, джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.

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

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

- получают в канале устройства самообслуживания (УС) пользовательский запрос на выполнение транзакции по приему ДС, содержащий параметры транзакции;

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

- получают ответ от сервера и сохраняют его в УС;

- инициируют прием УС ДС согласно параметрам транзакции;

- фиксируют в ходе приема данные принимаемых ДС;

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

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

- автоматически инициируют опрос удаленного сервера УС; и

- при получении отклика от удаленного сервера передают упомянутые сохраненные параметры транзакции на упомянутый сервер для ее выполнения;

- зачисляют ДС на указанный счет пользователя.

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

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

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

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

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

7. Система автоматического зачисления внесенных денежных средств (ДС) при возникновении сбоев, содержащая УС и связанный с ним удаленный сервер, причем

УС выполнено с возможностью

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

сохранять информацию о принятых ДС;

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

автоматически инициировать опрос удаленного сервера;

при получении отклика от удаленного сервера передавать упомянутые сохраненные параметры транзакции на упомянутый сервер для ее выполнения;

удаленный сервер выполнен с возможностью

проверять параметры транзакции, поступившей от УС;

сохранять информацию о транзакции и принятых ДС;

осуществлять автоматическое выполнение транзакции в случае выявления сбоя в канале передачи данных между УС и удаленным сервером; и

зачислять ДС на указанный счет пользователя.

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

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

10. Система по п. 7, характеризующаяся тем, что проводная сеть представляет собой ЛВС (LAN), WAN, PAN или Интранет.

11. Система по п. 7, характеризующаяся тем, что беспроводная сеть представляет собой WAN, Интернет, WLAN, WMAN или GSM.

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

13. Система по п. 7, характеризующаяся тем, что УС содержит средства верификации пользователя.

14. Система по п. 7, характеризующаяся тем, что средства верификации УС выбираются из группы: ПИН-пад, сенсорный дисплей, камера, биометрический сканер, микрофон или их сочетания.