Способ обработки запросов на обслуживание, который выполняется узлом поставщика услуг

Изобретение относится к области платежных протоколов. Технический результат заключается в повышении эффективности защиты обработки запроса на обслуживание от атак типа «Отказ в Обслуживании (DOS)». Способ (100, 200) обработки запросов (1) на обслуживание посредством узла (2) поставщика услуг содержит этапы, на которых: принимают (120, 220) первый запрос (3) на обслуживание, который пересылается пользователем (4); принимают (110, 210) первые данные (5) управления, указывающие первый финансовый депозит (6), который переводится пользователем (4), при этом первые данные (5) управления ссылаются по меньшей мере на один запрос (1) на обслуживание; и обрабатывают (130, 230) принятый первый запрос (3) на обслуживание, если принятые первые данные (5) управления ссылаются на принятый первый запрос (3) на обслуживание; раздают (270) третьи данные (12) управления, указывающие третий финансовый депозит (13), пользователю (4) в ответ на прием (110, 210) первых данных (5) управления и на основании оценки критерия пользователя, при этом критерий пользователя включает в себя поведения пользователя (4). 2 н. и 12 з.п. ф-лы, 5 ил.

 

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

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

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

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

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

Известны различные методики для того, чтобы защищать обработку запросов на обслуживание от атак типа «Отказ в Обслуживании». Например, могут быть предусмотрены дополнительные ресурсы аппаратного обеспечения. Однако, это затратное решение и требует дополнительной административной работы. Таким образом, масштабируемость ограничена и, как правило, даже крупномасштабные ресурсы аппаратного обеспечения могут быть перегружены, когда атака использует множество узлов для пересылки запросов на обслуживание.

Дополнительная методика реализует узел поставщика услуг с использованием основанных на облаке вычислительных ресурсов. Тогда, в случае атаки типа «Отказ в Обслуживании» дополнительные ресурсы аппаратного обеспечения могут быть динамически предоставлены для обработки всех запросов на обслуживание. Однако, такая методика также является затратной, в частности, когда дополнительные ресурсы аппаратного обеспечения распределяются динамически. Часто требуются пороговые величины для дополнительных ресурсов аппаратного обеспечения, чтобы избежать непредвиденных расходов.

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

Документ WO 2017/145018 A1 раскрывает безопасный способ для осуществления обмена объектами через блокчейн. Таким образом, включаются методики снабжения токенами и методики встраивания метаданных в сценарий погашения транзакции блокчейн. Способ содержит формирование первого сценария, причем первый сценарий содержит: первый набор метаданных, ассоциированный с первым приглашением для обмена первым объектом посредством первого пользователя, первый набор метаданных, содержащий указание первого объекта, который будет предложен для обмена, и первое условие местоположения для обмена, первый открытый ключ пользователя (P1A), ассоциированный с первым пользователем, при этом первый открытый ключ пользователя (P1A) является частью асимметричной криптографической пары, содержащей первый открытый ключ пользователя (P1A) и первый закрытый ключ пользователя (V1A).

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

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

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

Цель состоит в предоставлении способа для обработки запросов на обслуживание управляемым и надежным образом.

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

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

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

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

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

Запрос на обслуживание по смыслу настоящего изобретения может относиться к любому основанному на пользователе запросу, который может подразумевать предоставление определенной услуги. Такая услуга может относиться к основанной на IT услуге, например, вызову веб-страницы, управлению датчиком, управлению исполнительным механизмом, доступу к Прикладному Интерфейсу (API), транзакциям HTTP GET или POST и т.д. Запрос на обслуживание может быть переслан пользователем, т.е. инициирован и принят от пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

В другом варианте осуществления способа первые данные управления и третьи данные управления являются идентичными.

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

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

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

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

В связи с этим, способ конфигурируется более гибким образом.

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

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

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

В другом варианте осуществления способа использование базы данных на основании технологии распределенного реестра учета включает в себя осуществление доступа к услуге Смарт- Контрактов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Фигура 3 представляет собой блок-схему другого способа обработки запросов на обслуживание посредством узла поставщика услуг в соответствии с различными примерами.

Фигура 4 схематично иллюстрирует схему сигнализации пользователя и узла поставщика услуг в соответствии с различными примерами.

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

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

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

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

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

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

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

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

Фигура 1 схематично иллюстрирует сеть 18 обработки в соответствии с различными примерами, которая выполнена с возможностью взаимодействия со множеством пользователей 4 и узлом 2 поставщика услуг. Взаимодействие множества пользователей 4 и узла 2 поставщика услуг через линии 19 передачи данных может либо быть реализовано в непосредственном виде (не изображено на Фигуре 1), либо быть реализовано через базу 16 данных, собирающую данные соответствующего пользователя 4 организованным образом. Таким образом, может быть использована распределенная база данных или база 16 данных на основании технологии блокчейн, или, в целом, другой вид технологии распределенного реестра учета. Что касается последнего, то также предполагается включение работы в соответствии с услугой Смарт- Контрактов. Кроме того, база 16 данных также может функционировать на основе Ориентированного Ациклического Графа, такого как IOTA. Узел поставщика услуги может содержать блок 17 управления, который может быть выполнен с возможностью выполнения способа 100, 200 обработки в соответствии с различными примерами настоящего изобретения. Для этого любой запрос 1 на обслуживания может пересылаться пользователем 4 и затем может приниматься для обработки узлом 2 поставщика услуг.

Фигура 2 представляет собой блок-схему способа 100 обработки запросов 1 на обслуживание узлом 2 поставщика услуг в соответствии с различными примерами.

На этапе 110 узел 2 поставщика услуг может принимать первые данные 5 управления, указывающие первый финансовый депозит 6, который может быть переведен пользователем 4. Таким образом, первые данные управления могут ссылаться по меньшей мере на один запрос 1 на обслуживание.

На этапе 120 узел 2 поставщика услуг может принимать первый запрос 1 на обслуживание, который может быть переслан пользователем 4. Таким образом, прием 120 первого запроса 1 на обслуживание может быть выполнен после приема 110 первых данных 5 управления. Однако, также предполагается, что прием 120 первого запроса 1 на обслуживание и прием 110 первых данных 5 управления могут быть выполнены одновременно.

На этапе 125 узел 2 поставщика услуг может исследовать, могут ли принятые первые данные 5 управления ссылаться на или быть ассоциированы с принятым первым запросом 1 на обслуживание. Следовательно, может быть проверено, совпадает ли по меньшей мере один запрос на обслуживание, ассоциированный с первыми данными управления, с первым запросом на обслуживание. Например, могут быть определены и сравнены контрольные суммы или токены. Могут быть проверены связи между первыми данными 5 управления и первым запросом на обслуживание. Если принятые первые данные 5 управления могут ссылаться на принятый первый запрос на обслуживание 3, то принятый первый запрос 3 на обслуживание может быть обработан 130 узлом 2 поставщика услуг. В противном случае, узел 2 поставщика услуг может сохранять 135 или может не сохранять принятые первые данные 5 управления.

Фигура 3 представляет собой блок-схему другого способа 200 обработки запросов 1 на обслуживание посредством узла 2 поставщика услуг в соответствии с различными примерами.

На этапе 210 узел 2 поставщика услуг может принимать первые данные 5 управления, указывающие первый финансовый депозит 6, который может быть переведен пользователем 4. Таким образом, первые данные управления могут ссылаться по меньшей мере на один запрос 1 на обслуживание.

На этапе 220 узел 2 поставщика услуг может принимать первый запрос 3 на обслуживание, который может быть переслан пользователем 4. Как можно понять по Фигуре 3, можно предположить, что прием 220 первого запроса 3 на обслуживание и прием 210 первых данных 5 управления могут быть выполнены одновременно.

На этапе 225 узел 2 поставщика услуг может исследовать, могут ли принятые первые данные 5 управления ссылаться на принятый первый запрос 3 на обслуживание. Если принятые первые данные 5 управления могут ссылаться на принятый первый запрос 3 на обслуживание, то принятый первый запрос 3 на обслуживание может быть обработан 230 узлом 2 поставщика услуг. В противном случае узел 2 поставщика услуг может сохранять 235 или может не сохранять принятые первые данные 5 управления.

На этапе 240 узел 2 поставщика услуг может принимать 240 вторые данные 8 управления, указывающие второй финансовый депозит 9, который может быть переведен пользователем 4, при этом вторые данные 8 управления могут ссылаться по меньшей мере на один запрос 1 на обслуживание. Таким образом, прием 210, 240 первых данных 5 управления и вторых данных 8 управления может быть обеспечен посредством токена 10, который раздается узлом 2 поставщика услуг пользователю 4 в ответ на коллективный финансовый перевод 11, выполненный пользователем 4 на узел поставщика услуг.

На этапе 250 узел 2 поставщика услуг может принимать 250 второй запрос 7 на обслуживание, который может быть переслан пользователем 4. Таким образом, прием 250 второго запроса 7 на обслуживание посредством узла 2 поставщика услуг и прием 240 вторых данных 8 управления посредством узла 2 поставщика услуг могут быть выполнены одновременно.

На этапе 255 узел 2 поставщика услуг может исследовать, могут ли принятые вторые данные 8 управления ссылаться на принятый второй запрос 7 на обслуживание.

На этапе 260 принятый второй запрос 7 на обслуживание может быть выборочно обработан узлом 2 поставщика услуг, если принятые вторые данные 8 управления могут ссылаться на принятый второй запрос 7 на обслуживание.

На этапе 270 узел 2 поставщика услуг может раздавать третьи данные 12 управления пользователю. Такие третьи данные 12 управления могут указывать третий финансовый депозит 13. Таким образом, раздача третьих данных 12 управления может быть выполнена в ответ на прием 210 первых данных 5 управления на основании оценки критерия пользователя. Такой критерий пользователя может включать в себя по меньшей мере одно из следующего: a) по меньшей мере один запрос 1 на обслуживание, который пересылается пользователем 4, b) по меньшей мере одну попытку входа в систему пользователя 4 и c) информацию о финансовых ресурсах пользователя 4. Первые данные 5 управления и третьи данные 12 управления могут быть идентичными: Соответствующие финансовые депозиты могут быть сбалансированы.

На этапе 280 узел 2 поставщика услуг может раздавать четвертые данные 14 управления пользователю 4. Таким образом, четвертые данные 14 управления могут указывать четвертый финансовый депозит 15. Четвертые данные 14 управления могут раздаваться в ответ на прием 240 вторых данных 8 управления на основе оценки по меньшей мере одного критерия пользователя. Таким образом, раздачи 270, 280 третьих данных 12 управления и четвертых данных 14 управления могут быть выполнены одновременно.

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

Сначала коллективный финансовый перевод 11 может быть передан от пользователя 4 к узлу 2 поставщика услуг. По причинам компромиссной сделки узел 2 поставщика услуг может впоследствии передавать токен 10 к пользователю 4. Такой токен 10 может быть использован пользователем 4, чтобы пересылать первые данные 5 управления для передачи к узлу 2 поставщика услуг, при этом эти первые данные 5 управления указывают первый финансовый депозит. Одновременно или последовательно пользователь 4 может пересылать передачу первого запроса 3 на обслуживание узлу 2 поставщика услуг.

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

Сначала коллективный финансовый перевод 11 может быть передан от пользователя 4 к узлу 2 поставщика услуг. По причинам компромиссной сделки узел 2 поставщика услуг может впоследствии перемещать токен 10 к пользователю 4. Такой токен 10 может быть использован пользователем 4, чтобы пересылать первые данные 5 управления для п передачи к узлу 2 поставщика услуг, при этом эти первые данные 5 управления указывают первый финансовый депозит. Одновременно, пользователь 4 может пересылать передачу первого запроса 3 на обслуживание к узлу 2 поставщика услуг. Такой токен 10 также может быть использован пользователем 4, чтобы пересылать вторые данные 8 управления для передачи к узлу 2 поставщика услуг, при этом вторые данные 8 управления указывают второй финансовый депозит 9. Одновременно пользователь 4 может пересылать передачу второго запроса 7 на обслуживание к узлу 2 поставщика услуг. Узел 2 поставщика услуг затем может раздавать третьи данные 12 управления, указывающие третий финансовый депозит 13, пользователю 4 на основе оценки критерия пользователя, как, впрочем, и четвертые данные 14 управления, указывающие четвертый финансовый депозит 15, пользователю 4 на основе оценки по меньшей мере одного критерия пользователя. Таким образом, раздача третьих данных 12 управления и четвертых данных 14 управления может быть выполнена одновременно.

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

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

В дополнительном примере пользователь первоначально передает адрес биткоин-кошелька узлу поставщика услуг. Затем узел поставщика услуг может создать сеанс пользователя, привязанный к или ассоциированный с этим адресом кошелька. Во время сеанса пользователя пользователь переводит до или по существу одновременно с каждым запросом на обслуживание финансовый депозит в блокчейн, например, несколько центов или долларов. Узел поставщика услуг обрабатывает услугу только если был переведен и принят соответствующий финансовый депозит. Если пользователь идентифицируется как законный, то может быть осуществлена обратная выплата финансового депозита; или в ином случае заблокирована. В такой реализации доступные векторы атаки применительно к атакам типа «Отказ в Обслуживании» эффективно уменьшаются до первоначального запроса; первоначальный запрос может быть реализован эффективным для ресурсов образом и поддерживаться достаточными вычислительными ресурсами. Для того чтобы избегать преднамеренного спама применительно к созданию большого количества сеансов пользователя со случайными адресами кошельков, может потребоваться доказательство от пользователя того, что он/она является законным владельцем кошелька; такое доказательство может быть реализовано с использованием подписанного сообщения с соответствующего адреса или иным образом.

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

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

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

принимают (120, 220) первый запрос (3) на обслуживание, который пересылается пользователем (4);

принимают (110, 210) первые данные (5) управления, указывающие первый финансовый депозит (6), который переводится пользователем (4), при этом первые данные (5) управления ссылаются по меньшей мере на один запрос (1) на обслуживание; и

обрабатывают (130, 230) принятый первый запрос (3) на обслуживание, если принятые первые данные (5) управления ссылаются на принятый первый запрос (3) на обслуживание;

при этом способ (100, 200) отличается тем, что:

раздают (270) третьи данные (12) управления, указывающие третий финансовый депозит (13), пользователю (4) в ответ на прием (110, 210) первых данных (5) управления и на основании оценки критерия пользователя,

при этом критерий пользователя включает в себя поведения пользователя (4), и способ (100, 210) дополнительно содержит этап, на котором анализируют поведения пользователя (4).

2. Способ (100, 200) по п.1, дополнительно содержащий этап, на котором сохраняют (135, 235) принятые первые данные (5) управления, если принятые первые данные (5) управления не ссылаются на принятый первый запрос (3) на обслуживание.

3. Способ (100, 200) по любому из пп.1, 2, в котором этап, на котором принимают (120, 200) первый запрос (3) на обслуживание, выполняют после этапа, на котором принимают (110, 210) первые данные (5) управления.

4. Способ (100, 200) по любому из пп.1, 2, в котором этап, на котором принимают (120, 220) первый запрос (3) на обслуживание, и этап, на котором принимают (110, 210) первые данные (5) управления, выполняют одновременно.

5. Способ (100, 200) по п.4, дополнительно содержащий этапы, на которых:

принимают (250) второй запрос (7) на обслуживание, который пересылается пользователем (4);

принимают (240) вторые данные (8) управления, указывающие второй финансовый депозит (9), который переводится пользователем (4), при этом вторые данные (8) управления ссылаются по меньшей мере на один запрос (1) на обслуживание; и

обрабатывают (260) принятый второй запрос (7) на обслуживание, если принятые вторые данные (8) управления ссылаются на принятый второй запрос (7) на обслуживание,

при этом этап, на котором принимают (250) второй запрос (7) на обслуживание, и этап, на котором принимают (240) вторые данные (8) управления, выполняют одновременно, и

при этом этап, на котором принимают (110, 210, 240) первые данные (5) управления и вторые данные (8) управления, обеспечивается посредством токена (10), который раздается узлом (2) поставщика услуг пользователю (4) в ответ на коллективный финансовый перевод (11), который выполняется пользователем (4) на узел (2) поставщика услуг.

6. Способ по любому из пп.1-5, в котором критерий пользователя включает в себя по меньшей мере одно из следующего: a) по меньшей мере один запрос (1) на обслуживание, который пересылается пользователем (4), b) по меньшей мере одну попытку входа в систему пользователя (4) и c) информацию о финансовых ресурсах пользователя (4).

7. Способ (200) по любому из пп.1-6, в котором первые данные (5) управления и третьи данные (12) управления являются идентичными.

8. Способ (200) по п.5, дополнительно содержащий этап, на котором раздают (280) четвертые данные (14) управления, указывающие четвертый финансовый депозит (15), пользователю (4) в ответ на прием (240) вторых данных (8) управления, на основании оценки по меньшей мере одного критерия пользователя, при этом этапы, на которых раздают (270, 280) третьи данные (12) управления и четвертые данные (14) управления, выполняют одновременно.

9. Способ (100, 200) по любому из пп.1-8, в котором этап, на котором принимают (120, 220) первый запрос (3) на обслуживание, и этап, на котором принимают (110, 210) первые данные (5) управления, обеспечиваются путем передачи данных с использованием распределенной базы данных.

10. Способ (100, 200) по любому из пп.1-8, в котором этап, на котором принимают (120, 220) первый запрос (3) на обслуживание, и этап, на котором принимают (110, 210) первые данные (5) управления, обеспечиваются посредством передачи данных с использованием базы (16) данных, основанной на технологии распределенного реестра учета.

11. Способ (100, 200) по п.10, в котором использование базы (16) данных, основанной на технологии распределенного реестра учета, включает в себя осуществление доступа к услуге Смарт-Контрактов.

12. Способ (100, 200) по любому из пп.1-8, в котором этап, на котором принимают (120, 220) первый запрос (3) на обслуживание, и этап, на котором принимают (110, 210) первые данные (5) управления, обеспечиваются посредством передачи данных с использованием базы (16) данных, основанной на Ориентированном Ациклическом Графе.

13. Узел (2) поставщика услуг, выполненный с возможностью обработки запросов (1) на обслуживание и содержащий блок (17) управления, который выполнен с возможностью:

приема первого запроса (3) на обслуживание, который пересылается пользователем (4);

приема первых данных (5) управления, указывающих первый финансовый депозит (6), который переводится пользователем (4), при этом первые данные (5) управления ссылаются по меньшей мере на один запрос (1) на обслуживание; и

обработки принятого первого запроса (3) на обслуживание, если принятые первые данные (5) управления ссылаются на принятый первый запрос (3) на обслуживание;

при этом узел (2) поставщика услуг дополнительно отличается тем, что:

блок (17) управления дополнительно выполнен с возможностью раздачи (270) третьих данных (12) управления, указывающих третий финансовый депозит (13), пользователю (4) в ответ на прием (110, 210) первых данных (5) управления и на основании оценки критерия пользователя,

при этом критерий пользователя включает в себя поведения пользователя (4), и способ (100, 210) дополнительно содержит этап, на котором анализируют поведения пользователя (4).

14. Узел (2) поставщика услуг по п.13, который выполнен с возможностью выполнения способа (100, 200) по любому из пп.2-12.