[2][1] Настоящее техническое решение, в общем, относится к области обработки данных для осуществления транзакций по доставке денежных средств (ДС) при взаимодействии пользователей с устройствами самообслуживания (УС), а в частности, к способам осуществления транзакций по доставке ДС при возникновении сбоев в канале связи УС.
[4][2] Из уровня техники известен патент №US8108726B2 «Система и способ для адаптивной диагностики сбоев в канале банковского автомата в режиме тонкого клиента», патентообладатель: Bank of America Corp, дата публикации: 31.01.2012. В данном решении осуществляют адаптивную диагностику сбоев в канале банковского автомата при осуществлении транзакций по доставке ДС. Особенностью решения является то, что УС включает в себя тонкий клиент и адаптивную диагностику, которую осуществляют в режиме тонкого клиента. В данном техническом решении при возникновении сбоев в канале банковского автомата пользователю сообщается о сбое и указывается причина сбоя, а также выдается информация о ближайших исправных банковских автоматах. Кроме того, адрес ближайшего местоположения исправного банкомата может быть передан банкоматом в режиме тонкого клиента на мобильный телефон пользователя.
[5][3] Предпосылки создания заявленного технического решения основываются на необходимости реализации механизма расширенного функционала при выполнении транзакций по доставке ДС при возникновении сбоев в канале УС. Существующий на сегодняшний день недостаток в уровне техники заключается в отсутствии механизма по гарантированной доставке ДС при выполнении транзакций по доставке ДС при возникновении сбоев в канале УС.
[6]СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ
[7][4] Заявленное техническое решение направлено на решение задачи по созданию механизма гарантированной доставки ДС при возникновении сбоев в канале УС без повторной авторизации и без повторного ввода параметров транзакции.
[8][5] Техническим результатом заявленного технического решения является расширение функциональных возможностей УС, за счет реализации механизма гарантированной доставки ДС при возникновении сбоев в канале УС.
[9][6] Дополнительным техническим результатом, проявляющимся при решении вышеуказанной задачи, является повышение надежности работы УС за счет осуществления гарантированной доставки ДС при возникновении сбоев в канале УС.
[10][7] Дополнительно понижается количество обращений клиентов при осуществлении данного технического решения.
[11][8] Технический результат достигается благодаря осуществлению способа гарантированного выполнения транзакции по доставке ДС при возникновении сбоев в канале связи УС, в котором:
[12]- получают в канале УС первичный пользовательский запрос на выполнение транзакции по доставке ДС;
[13]- формируют и сохраняют в памяти УС транзакционный запрос, содержащий, по меньшей мере, информацию о типе транзакции, сумме транзакции, реквизитах транзакции и идентификатор транзакции;
[14]- проверяют наличие связи между УС и удаленным сервером, в ходе которого инициируют попытку выполнения транзакционного запроса клиента;
[15]- определяют в канале УС сбой выполнения упомянутой транзакции при попытке связи с удаленным сервером;
[16]- получают на УС информацию о получении отклика от удаленного сервера;
[17]- формируют повторный транзакционный запрос на основании данных первичного транзакционного запроса и осуществляют повторную попытку выполнения транзакционного запроса;
[18]- выполняют транзакцию.
[19][9] При реализации технического решения при возникновении сбоев в канале связи между УС и удаленным сервером устанавливают таймер, определяющий количество времени на восстановление связи между УС и удаленным сервером.
[20][10] При реализации технического решения дополнительно учитывают MAC – адрес УС при запросе на выполнение транзакции.
[21][11] При реализации технического решения при обнаружении сбоя связи с сервером при обработке первичного транзакционного запроса формируется параметр временного промежутка для выполнения повторного транзакционного запроса.
[22][12] При реализации технического решения в течение заданного временного параметра осуществляется опрос удаленного сервера для активации повторного запроса на получение отклика для выполнения транзакции.
[23][13] При реализации технического решения в течение заданного временного параметра осуществляют попытку отправки транзакционного запроса на удаленный сервер, при этом учитывают количество попыток отправки транзакционного запроса;
[24][14] - при получении ответа от удаленного сервера, проверяют МАС транзакционного ответа, количество времени потребовавшегося на восстановление связи между УС и удаленным сервером и количество попыток отправки транзакционного запроса;
[25][15] - выполняют пользовательский запрос;
[26][16] При реализации технического решения при формировании пользовательского запроса осуществляется верификация пользователя УС.
[27][17] При реализации технического решения верификация осуществляется с помощью PIN-кода, биометрической информации, графической информации или удаленного устройства пользователя или их сочетания.
[28][18] При реализации технического решения биометрическая информация представляет собой отпечаток пальца, изображение сетчатки глаза, голосовые данные или их сочетания.
[29][19] При реализации технического решения графическое изображение представляет собой фотоизображение пользователя.
[30][20] Также технический результат достигается благодаря осуществлению системы гарантированного выполнения транзакции по доставке ДС при возникновении сбоев в канале связи устройства самообслуживания УС, которая содержит УС и связанный с ним удаленный сервер, причем УС выполнено с возможностью получать первичный пользовательский запрос на выполнение транзакции по доставке ДС;
[31]сохранять информацию о принятых ДС;
[32]передавать информацию о транзакции на удаленный сервер;
[33]удаленный сервер выполнен с возможностью сохранять информацию о транзакции принятых и доставленных ДС.
[34][21] При реализации технического решения УС представляет собой банкомат или информационно-платежный терминал.
[35][22] При реализации технического решения УС связано с удаленным сервером посредством проводной или беспроводной вычислительной сети.
[36][23] При реализации технического решения проводная сеть представляет собой ЛВС (LAN), WAN, PAN или Интранет.
[37][24] При реализации технического решения беспроводная сеть представляет собой WAN, Интернет, WLAN, WMAN или GSM.
[38][25] При реализации технического решения удаленный сервер представляет собой облачный сервер.
[39][26] При реализации технического решения УС содержит средства верификации пользователя.
[40][27] При реализации технического решения средства верификации УС выбираются из группы: ПИН-пад, сенсорный дисплей, камера, биометрический сканер, микрофон или их сочетания.
[41]КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[42][28] Фиг. 1 иллюстрирует процесс выполнения заявленного способа.
[43][29] Фиг. 2 иллюстрирует процесс гарантированной доставки ДС в общем виде.
[44][30] Фиг. 3 иллюстрирует общий вид системы, реализующей способ.
[45][31] Фиг. 4 иллюстрирует схему УС.
[46][32] Фиг. 5 иллюстрирует схему сервера обработки запросов от УС.
[47]ПОДРОБНОЕ ОПИСАНИЕ ТЕХНИЧЕСКОГО РЕШЕНИЯ
[48][33] Ниже будут описаны понятия и определения, необходимые для подробного раскрытия заявленного технического решения.
[49][34] Денежные средства (ДС) - специфический товар, обладающий наивысшей ликвидностью, служащий измерителем стоимости других товаров и услуг.
[50][35] Банковское устройство самообслуживания (УС) – программно-технический комплекс, предназначенный для автоматизированной выдачи и/или приёма наличных ДС как с использованием платёжных карт, так и без, а также выполнения других операций, в том числе оплаты товаров и услуг, составления документов, подтверждающих соответствующие операции. Банковские устройства самообслуживания подразделяются на два типа в зависимости от того, поддерживают ли они функцию выдачи наличных денег или нет. Если функция поддерживается, то УС является ATM (англ. automated teller machine), или банкоматом, иначе – NCS (non-cash systems), или терминалом для безналичных операций.
[51][36] Программное обеспечение (ПО) - программа или множество программ, используемых для управления УС.
[52][37] Предварительно на УС могут включить режим гарантированного выполнения транзакции по доставке ДС или выключить стандартными средствами конфигурации УС. Причем если режим выключен, УС работает в полном соответствии с форматом NDC.
[53][38] В каждый момент времени УС находится в одном из следующих режимов работы:
[55]Offline — нет связи с сервером, осуществляется подключение;
[56]Supervisor — работает инкассатор или сервис-инженер;
[57]Out of service — УС не работает, в связи с неисправностью, исчерпанием денежных средств, или принудительным переводом УС в указанный режим;
[58]In service — основной режим работы УС.
[59][39] В режиме In service УС находится в одном из состояний (стейт), с номером от 001 до 999, и 25 символьной строкой-описанием.
[60][40] Первый символ этой строки — тип стейта (обозначаются буквами A..Z, а так же a..z и некоторыми символами (,'.?)), который определяет совокупность. Остальные 24 символа — это 8 десятичных 3-значных чисел, каждое из которых является определенной настройкой стейта (номер экрана для показа, условия перехода на стейт, список действий). Стейтов одного типа может быть любое количество.
[61][41] Переходя по всем этим стейтам, рано или поздно доходят до стейта взаимодействия с удаленным сервером — стейта I (Transaction Request State). На этом стейте формируется запрос из данных, собранных на прошлых стейтах и отправляется на сервер. Запрос представляет собой идентификатор УС (Logical Unit Number), данные с дорожек карты, данные о предыдущих транзакциях, данных с буферов суммы, пин-блока, нажатий функциональных клавиш (FDK буфер). Данные разделяются символом разделителем. Удаленный сервер получает запрос и анализирует буфер FDK – именно по содержимому этого буфера удаленный сервер понимает чего хочет УС. После чего, в зависимости от принятого решения, отсылает ответ в котором содержатся:
[62]• идентификатор действия, которое нужно совершить;
[63]• номер экрана, который нужно при этом действии показывать;
[64]• содержимое чека, если чек нужно напечатать;
[65]• стейт на который нужно перейти по завершению действия.
[66][42] Как представлено на Фиг. 1, заявленный способ гарантированного выполнения транзакции по доставке ДС при возникновении сбоев в канале связи УС (100) инициируется путем получения и обработки первичного пользовательского запроса на выполнение транзакции по доставке ДС (101).
[67][43] Первичный пользовательский запрос на выполнение транзакции может формироваться в памяти УС после выбора клиентом банковской операции. Банковскую операцию пользователь может выбирать посредством использования графического интерфейса пользователя (GUI) УС. В качестве банковской операции может использоваться выдача наличных или внесение ДС на банковскую карту (запрос на зачисление внесенных средств).
[68][44] Первичный пользовательский запрос формируется с помощью взаимодействия пользователя с УС, например, банкоматом или терминалом для безналичных операций. Первичный пользовательский запрос содержит, по меньшей мере, информацию о намерении пользователя осуществить транзакцию по доставке ДС.
[69][45] При получении в системе первичного пользовательского запроса на выполнение транзакции, формируют и сохраняют в памяти УС транзакционный запрос (102), содержащий, по меньшей мере, информацию о типе транзакции, сумме транзакции, реквизитах транзакции в зависимости от типа транзакции и уникальном идентификаторе транзакции (TrID). В некоторых вариантах осуществления идентификатор транзакции является численным или символьным значением.
[70][46] Значение TrID должно быть уникальным для каждого транзакционного запроса (значение TrID обновляется при каждом переходе на транзакционный стейт в сценарии УС). Если обычный транзакционный запрос получен в новом формате, поле TrID запроса не пусто, его значение нужно сохранить в БД удаленного сервера в составе транзакционных данных.
[71][47] Во все транзакционные запросы добавляется поле «TransactionID», например, с идентификатором «3», состоящее из 12 символов.
[72][48] Для первичного запроса данные поля формируются следующим образом: ГММДДЧЧММNNN (где Г — последняя цифра текущего года, ММ — номер месяца, ДД — день, ЧЧ — час, ММ — минута, NNN — последние 3 цифры текущего значения Accumulated Transaction Count, что обеспечивает уникальность значения TransactionID для данного терминала).
[73][49] Для повторного запроса значение поля «TransactionID» должно повторять значение, сформированное в момент первичного запроса.
[74][50] После формирования и сохранения в памяти УС транзакционного запроса (102), УС формирует и направляет сообщение, содержащее, вышеупомянутый транзакционный запрос, содержащий, по меньшей мере, информацию о типе транзакции, сумме транзакции, реквизитах транзакции и уникальном идентификаторе транзакции на удаленный сервер.
[75][51] В процессе передачи сообщения, УС определяет, присутствует ли связь в канале между УС и удаленным сервером и в случае обнаружения сбоя в канале связи между УС и удаленным сервером УС предлагает пользователю отказаться от выполнения транзакции или продолжить выполнение транзакции в режиме гарантированной доставки ДС.
[76][52] В других вариантах осуществления предлагают пользователю отказаться от выполнения транзакции или продолжить выполнение транзакции в режиме гарантированной доставки ДС в случае таймаута ответа удаленного сервера на транзакционное сообщение.
[77][53] При попадании в стейт I УС производит следующую проверку:
[78][54] Если с момента входа в клиентскую сессию авторизационных запросов не проводилось, либо запросы проводились, но не был активирован режим гарантированного выполнения транзакции по доставке ДС путем вызова специального стейта f-032, УС генерирует новый идентификатор транзакции (TrID). Дополнительно УС формирует запрос «TransactionRequest» в полном соответствии с форматом NDC, дополнив его полем, например, с id = «3», содержащим данный идентификатор.
[79][55] Если с момента входа в клиентскую сессию был произведен авторизационный запрос, а после него был активирован режим гарантированного выполнения транзакции по доставке ДС путем вызова специального стейта f-032, проверяется следующее:
[80]• если все параметры готового к отправке запроса соответствуют параметрам, переданным в предыдущем запросе, УС генерирует повторный запрос. При этом сохраняется текущий идентификатор транзакции (TrID), а вот поле «MessageSubclass» вместо значения «1» («Transaction Request Message») принимает специальное значение «D» («Dublicate Transaction Request»);
[81]• если хотя бы один параметр готового к отправке запроса не соответствует параметрам, переданным в предыдущем запросе, считается, что начата новая транзакция. УС генерирует новый идентификатор транзакции (TrID) и формирует запрос «TransactionRequest» в полном соответствии с форматом NDC, дополнив его полем с id = «3», содержащим данный идентификатор.
[82][56] При возникновении коммуникационных ошибок и ошибок формата сообщений УС переходит из стейта I на номер стейта, указанного в «Central Response TimeOut Next State».
[83][57] Если в канале связи между УС и удаленным сервером присутствует связь и не выявлено сбоев в процессе передачи информации, УС передает сообщение содержащее, транзакционный запрос, содержащий, по меньшей мере, информацию о типе транзакции, сумме транзакции, реквизитах транзакции и уникальный идентификатор транзакции на удаленный сервер, с использованием данных оригинального транзакционного сообщения.
[84][58] При обработке повторного запроса УС повторная авторизация по карте не проводится.
[85][59] Отправка повторного запроса контролируется на уровне сценария УС. Для разрешения/запрета обработки повторных запросов на удаленном сервере используется специальный атрибут модуля. Управлять атрибутом можно с использованием SQL-скрипта или web-формы, при этом не внедрение web-формы является стоп-фактором для тиражирования функционала гарантированной доставки ДС на всю сеть УС.
[86][60] В данном техническом решении игнорируют повторный запрос, если удаленный сервер отправил ответ на оригинальный запрос. УС прислал сообщение, подтверждающее получение ответа от удаленного сервера.
[87][61] В некоторых вариантах осуществления игнорируют повторный запрос, если удаленный сервер отправил ответ на оригинальный запрос УС, который присылал сообщение о переходе в режим Supervisor Mode или сообщение Power Up.
[88][62] В некоторых вариантах осуществления игнорируют повторный запрос, если номера карты или суммы операции, или типы транзакции (OPCODE буфер) в оригинальном и повторном запросах различаются.
[89][63] В некоторых вариантах осуществления игнорируют повторный запрос, если возникает ошибка формата повторного запроса, в том числе пустой TrID.
[90][64] При игнорировании повторного запроса соответствующий атрибут добавляется в БД удаленного сервера данного УС.
[91][65] Удаленный сервер, получив от УС сообщение, содержащее транзакционный запрос на доставку ДС, осуществляет проверку корректности информации, содержащейся в транзакционном запросе. Удаленный сервер проверяет корректность указанного типа транзакции, реквизитов транзакции, уникального идентификатора транзакции, а также достаточно ли на счете ДС для доставки ДС.
[92][66] В некоторых вариантах осуществления в случае таймаута ответа удаленного сервера УС переустанавливает соединение с удаленным сервером, согласно текущим настройкам сети УС банка.
[93][67] Дополнительно удаленный сервер проверяет МАС транзакционного запроса, а также, не был ли данный запрос обработан ранее.
[94][68] Если все указанные параметры корректны, то удаленный сервер формирует и направляет на УС транзакционный ответ с указанием о выполнении доставки ДС.
[95][69] Если транзакционный ответ удаленного сервера на оригинальное транзакционное сообщение УС не сформирован, удаленный сервер завершает обработку оригинального сообщения, и формирует ответ на повторное транзакционное сообщение от УС. Ответ на оригинальное сообщение от УС не формируется. Если из-за особенностей распараллеливания обработки запросов УС на удаленном сервере на УС будут отправлены и ответ на оригинальный запрос, и на повторный запрос, такая ситуация не является ошибкой. УС должно проигнорировать ответ на оригинальный запрос, т.к. на момент формирования повторного запроса в УС изменились актуальные значения MCN и TVN транзакции.
[96][70] Если ответ удаленного сервера на оригинальное транзакционное сообщение УС был сформирован, на его основе формируется ответ на повторное сообщение, причем новых авторизаций по карте не производится.
[97][71] Сообщение будет иметь новые значения TVN и MCN из повторного запроса УС.
[98][72] На Фиг. 2 показан принцип работы механизма гарантированной доставки ДС (200). При выявлении сбоев в канале связи между УС и удаленным сервером (201), УС запускает режим гарантированной доставки ДС. В данном режиме УС устанавливает таймер, определяющий количество времени на восстановление связи между УС и удаленным сервером, задает параметр временного промежутка для выполнения повторного транзакционного запроса (202).
[99][73] УС в течение заданного временного параметра осуществляет опрос удаленного сервера для активации повторного запроса на получение отклика для выполнения транзакции и осуществляют попытку отправки транзакционного запроса на удаленный сервер, при этом учитывают количество попыток отправки транзакционного запроса (203).
[100][74] Стейт также позволяет ограничить максимальное количество повторных запросов на получение отклика для выполнения транзакции. В процессе его выполнения могут осуществляться следующие проверки.
[101][75] Если УС с выключенным режимом гарантированного выполнения транзакции по доставке ДС попадает в стейт f-032, то обработка производится аналогично случаю превышения максимального количества повторных запросов (подразумевается окончание клиентской сессии по причине технического сбоя).
[102][76] Если количество попыток проведения повторных запросов равно или превышает максимум, указанный в стейте f-032, осуществляется окончание клиентской сессии по причине технического сбоя.
[103][77] Если количество попыток проведения повторных запросов меньше установленного в стейте максимума, то счетчик попыток увеличивается и УС переходит на «Next State».
[104][78] Если лимит количества повторных запросов не превышен, УС по номеру стейта, указанному в поле «Next State» стейта f-032, переходит на диалог с клиентом, подразумевающий подтверждение повторного запроса на удаленный сервер. Данный диалог организуется стандартными средствами NDC.
[105][79] Если подтверждают запрос, то управление должно быть передано в стейт I. Очень важно, чтобы между окончанием предыдущего стейта I по ветке «Central Response TimeOut Next State» и вызовом нового стейта I содержимое транзакционного запроса осталось неизменным.
[106][80] При получении транзакционного ответа (204) от удаленного сервера, проверяют МАС транзакционного ответа, количество времени, потребовавшегося на восстановление связи между УС и удаленным сервером и количество попыток отправки транзакционного запроса и если все данные корректны, выполняют пользовательский запрос.
[107][81] Как представлено на Фиг. 3 общий принцип работы системы выполнения транзакций по доставке ДС осуществляется при обработке формируемых в канале УС (300) пользовательских запросов и их последующей передачи по сети (500) на удаленный сервер (400), с помощью способа (100), раскрытого выше.
[108][82] На Фиг. 4 представлена общая схема УС (300) в виде банкомата или терминала для безналичных операций. УС (300) содержит объединенные с помощью шины компоненты, такие как: процессор (301), память (302), средство сетевого взаимодействия (303), дисплей (304), органы управления (305), средство выдачи ДС (306). Дополнительно может также использоваться средство приема ДС (307).
[109][83] Процессор УС (301) выполняет все необходимые вычислительные операции при обработке транзакционных запросов. Память (302) может представлять одно или более устройств различного типа, таких как: ОЗУ, ПЗУ или их сочетания. В качестве ПЗУ может использоваться HDD, SSD диски, флэш-память и т.п. В памяти (302), как правило, хранится исполняемая процессором (301) программная логика, необходимая для реализации способа работы УС (300), и операционная система, организующая интерфейс взаимодействия и протоколы обработки данных.
[110][84] В качестве средств сетевого взаимодействия (303) могут применяться устройства, обеспечивающие связь с удаленным сервером с помощью проводного или беспроводного типа связи, например, Ethernet карта (LAN), Wi-Fi модуль, GSM модем (2G, 3G, 4G, 5G) и т.п. Дополнительно могут использоваться средства обмена данными между УС (300) и пользователем (устройством пользователя), например, Bluetooth приемо-передатчик, NFC модуль, IrDa и т.п.
[111][85] Дисплей УС (304) служит для отображения графического интерфейса пользователь, а также при его исполнении в виде сенсорного дисплея, то также обеспечивает взаимодействие с пользователем и получения от него команд управления.
[112][86] Органы управления УС (305) могут представлять собой клавиатуру, сенсорный дисплей, пин-пад, механические и сенсорные кнопки.
[113][87] Средство выдачи ДС (306) представляет собой диспенсер. Диспенсер (306) может быть различного типа, например, фрикционным или вакуумным.
[114][88] Дополнительно УС (300) может содержать средство для приема ДС (307) от пользователя.
[115][89] Также, УС (300) может содержать считыватель банковских карт, камеру, один или более биометрических сенсоров, микрофон. Данные устройства, как по отдельности, так и в совокупности, могут применяться для идентификации и верификации пользователя. Пользователь может идентифицировать начало транзакционного запроса с помощью предоставления банковской карты в специальный ридер УС (300) и ввода пин-кода с помощью клавиатуры (305) или сенсорного дисплея (304).
[116][90] В некоторых вариантах осуществления технического решения может применяться двухфакторная верификация пользователя с помощью камеры или биометрических сенсоров, например, сканера отпечатка пальца, сетчатки глаза или с помощью анализа голоса пользователя. С помощью камеры может фиксироваться изображение пользователя УС (300) для последующей обработки и сравнения с эталонной идентифицирующей информацией владельца счета при инициации транзакционной операции в УС (300).
[117][91] УС (300) может также обеспечивать обмен идентификационной информацией в полностью бесконтактном режиме, с помощью заранее создаваемого идентификационного токена с помощью устройства пользователя, например, смартфона, планшета или ноутбука, и его последующей передачи по беспроводному каналу обмена информацией, например, Bluetooth, Wi-Fi, NFC, RFID и т.п., в УС (300).
[118][92] На Фиг. 5 представлена общая схема удаленного сервера (400). Сервер (400) предназначен для обработки запросов на исполнение транзакционных запросов, поступающих в канал УС (300). Также сервер (400) осуществляет механизм гарантированной доставки ДС при возникновении сбоев в канале УС без повторной авторизации и без повторного ввода параметров транзакции.
[119][93] В общем случае сервер (400) содержит такие компоненты, как: по меньшей мере один процессор (401), по меньшей мере одну память (402), средство хранения данных (403), интерфейсы ввода/вывода (404), средство сетевого взаимодействия (405).
[120][94] Процессор (401) сервера выполняет основные вычислительные операции при его работе с УС (300). Процессор (401) исполняет необходимые машиночитаемые команды, содержащиеся в памяти (402).
[121][95] Память (402), как правило, выполнена в виде ОЗУ и содержит необходимую логику работы операционной системы, механизма гарантированной доставки ДС и иную программную логику, обеспечивающую полноценный функционал работы сервера (400).
[122][96] Средство хранения данных (403) может выполняться в виде HDD, SSD дисков, рейд массива, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средства (403) позволяют выполнять долгосрочное хранение различного вида информации, например, истории обработки транзакционных запросов (логов), идентификаторов пользователей и т.п.
[123][97] Интерфейсы (404) представляют собой стандартные средства для подключения и работы с сервером (400), например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.
[124][98] Выбор интерфейсов (404) зависит от конкретного исполнения сервера (400), который может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент и т.п.
[125][99] Средства сетевого взаимодействия (405) выбираются из устройств, обеспечивающих сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств (405) обеспечивается организация обмена данными между сервером (400) и УС (300) по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.
[126][1] Дополнительно сервер (400) может содержать средства ввода/вывода данных, например, клавиатуру, джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор, компьютерную мышь, трекбол, световое перо, динамики, микрофон и т.п.
[127][2] В настоящих материалах заявки было представлено предпочтительное раскрытие осуществление заявленного технического решения, которое не должно использоваться как ограничивающее иные, частные воплощения его реализации, которые не выходят за рамки испрашиваемого объема правовой охраны и являются очевидными для специалистов в соответствующей области техники.
