СПОСОБ И СИСТЕМА ОБЕЗЛИЧЕННОЙ ОЦЕНКИ КЛИЕНТОВ ОРГАНИЗАЦИЙ ДЛЯ ПРОВЕДЕНИЯ ОПЕРАЦИЙ МЕЖДУ ОРГАНИЗАЦИЯМИ Российский патент 2023 года по МПК G06F17/40 G06F21/62 

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

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

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

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

По данным аналитического издания KPMG, опубликованным в "Глобальном исследовании по вопросам мошенничества в банковской сфере" за период 2015-2018 гг. значительно увеличилось количество мошеннических схем в банковской сфере, включая кражу личных данных и учетных записей, кибератаки, CNP-атаки ("card not present fraud" https://en.wikipedia.org/wiki/Card_not_present_transaction). В исследовании также отмечен значительный рост авторизованных платежей мошенникам: мошенники манипулируют клиентами банков и обманным путем заставляют их переводить деньги в обход системы контроля банков. Несмотря на то, что многие клиенты самостоятельно переводят деньги на счет злоумышленников, они считают, что именно банки должны заниматься предотвращением попыток мошеннических действий.

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

Одним из таких решений является патент US 10,706,423 В1 банка Capital One Services. В этом патенте описан способ анализа данных о транзакциях клиентов в реальном времени с помощью машинно-обученного алгоритма и предсказание вероятности того, что проводимая транзакция является мошеннической. При высокой вероятности мошеннической транзакции выполняется подтверждение транзакции, посредством обращения к пользователю, например через его мобильное устройство. В случае получения подтверждения от пользователя выполняется транзакция.

Другим примером является заявка на патент US 10339606 B2 от American Express Travel Related Services Co Inc. В ней описан способ циклического анализа множества транзакций пользователя и выявления значения переменной мошенничества. Анализ выполняется посредством обученной нейронной сети. При высоком значении данной переменной пользователь считается мошенником, и транзакции на его счет не выполняются.

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

Другой способ противостояния мошенничеству описан в заявке "Fraud Prevention system for transactions" US 2011/0196791 Al компанией Visa International Service Association. В ней описан способ анализа вероятности того, что проводимая транзакция является мошеннической, причем анализ является частью авторизации клиента и производится в режиме реального времени и до выполнения самой операции. В данном методе выполняется анализ CNP (Card-Not-Present) платежей. Данный метод не позволяет идентифицировать мошенника, если он использует разные реквизиты для мошеннических операций. В этом случае каждый из реквизитов мошенника будет представлен как независимая сущность. Если с нового реквизита мошенника еще никогда не выполнялось мошеннических действий, то определить новый реквизит как потенциально мошеннический не удастся. Из-за этого данный метод оказывается неэффективным для ранее упомянутых случаев мошенничества, когда жертва мошенничества самостоятельно перевела деньги по реквизиту мошенника.

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

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

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

Также из области техники известны различные способы шифрования, такие как асимметричное шифрования. Асимметричное шифрование - это способ защиты информации, при котором информация шифруется с помощью двух ключей: публичного, доступного всем, и приватного, доступного только владельцу информации. Благодаря этому способу шифрования кто угодно может зашифровать данные с помощью публично доступного ключа и безопасным способом передать зашифрованные данные получателю. Только получатель сможет расшифровать данные с помощью своего публичного ключа. Подробнее про асимметричное шифрование можно почитать здесь: https://thecode.media/asymmetric/.

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

СУЩНОСТЬ РЕШЕНИЯ

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

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

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

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

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

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

База данных для обезличивания идентификаторов клиентов - база данных, хранящаяся на сервере организации-резидента и содержащая множество идентификаторов клиентов, где каждый идентификатор клиента ассоциирован с обезличенным идентификатором клиента.

База данных реквизитов организаций-резидентов - база данных, которая хранится на координирующем сервере и содержит информацию о реквизитах организаций-резидентов.

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

Решение относится к области компьютерной безопасности. Технический результат заключается в обеспечении обезличенной оценки клиентов.

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

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

Технический результат заключается в обеспечении обезличенной оценки клиентов.

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

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

В дополнительном способе реализации url ресурс не связан с координирующим сервером. Также url ресурс может являться официальным url ресурсом организации-резидента.

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

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

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

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

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

Во второй реализации решения по меньшей мере один сервер обезличивающей организации является сервером организации получателя. По меньшей мере один сервер обезличивающей организации является по меньшей мере одним сервером организации-резидента.

В третьей реализации зашифрованный идентификатор клиента может состоять из первой части зашифрованного идентификатора клиента и второй части зашифрованного идентификатора клиента.

В четвертой реализации шифрование выполняется методом ассиметричного шифрования.

В пятой реализации шифрование выполняется методом симметричного шифрования.

В шестой реализации дополнительно используется уникальный ключ организации для шифрования.

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

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

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

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

В одиннадцатой реализации объединение первой части обезличенного идентификатора клиента и второй части обезличенного идентификатора клиента реализовано посредством конкатенации первой части обезличенного идентификатора клиента и второй части обезличенного идентификатора клиента;

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

Возможен также вариант реализации, при котором обновленную оценку клиента передают организации получателю.

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

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

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

Фиг. 1А иллюстрирует пример реализации системы обезличенной оценки клиентов.

Фиг. 1Б иллюстрирует общую схему системы обезличенной оценки клиентов.

Фиг. 2 иллюстрирует подготовительный этап способа обезличенной оценки клиентов.

Фиг. 3А-Б иллюстрируют рабочий этап способа обезличенной оценки клиентов.

Фиг. 4-5 иллюстрируют пример реализации рабочего способа обезличенной оценки клиентов.

Фиг. 6 иллюстрирует схему вычислительного устройства.

ДЕТАЛЬНОЕ ОПИСАНИЕ

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

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

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

На каждом из серверов 121, 124, 127 есть по меньшей мере две базы данных: база данных первичных оценок клиентов 122, 125, 128 и база данных для обезличивания идентификаторов клиентов 123, 125, 129. На координирующем сервере также хранится по меньшей мере две базы данных: общая база данных оценок клиентов 111 и общая база данных конфигураций организаций резидентов 112.

В системе каждый сервер 121, 124, 127 организации отнесен к первой подгруппе серверов 120 организаций резидентов. Помимо подгруппы серверов 120 на Фиг. 1А представлено еще две подгруппы серверов 130, 140 организаций резидентов.

На координирующем сервере 110 компании получают, хранят и обновляют данные клиентов организаций в обезличенном виде. При этом сотрудники компании не имеют технической возможности самостоятельно деанонимизировать данные, хранящиеся на координирующем сервере 110. Обезличивание данных выполняют на серверах, таких как сервера 121, 124, 127, организаций-резидентов, обратившихся за услугами в компанию. Организации, на серверах которых выполняется обезличивание, называются организации-резиденты.

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

На сервере организации, таком как 121, 124, 127 данные каждого из клиентов ассоциируют с уникальным идентификатором, позволяющим выполнять идентификацию клиента. Каждому уникальному идентификатору клиента в системе 100 присваивают обезличенный идентификатор клиента. Обезличенный идентификатор клиента также является уникальным, то есть соответствует только одному клиенту и не может повторяться для нескольких клиентов в системе 100. Обезличенные идентификаторы клиентов хранят на координирующем сервере 110. Обезличенный идентификатор клиента используют для анонимного сбора, анализа, хранения и обновления данных о клиентах системы. Под данными о клиентах системы подразумевается обезличенный идентификатор клиента и его оценка. Идентифицировать клиента в системе 100 по обезличенному идентификатору клиента может только та организация, которая сгенерировала обезличенный идентификатор клиента для уникального идентификатора клиента, то есть та организация-резидент, в которой данный клиент получает услуги.

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

Безопасность данных клиентов с одной стороны обеспечивают за счет хранения и обработки данных в обезличенном виде на координирующем сервере 110 компании, не имеющем возможности самостоятельно деанонимизировать данные, а с другой стороны выполнением обезличивания самими организациями-резидентами на своих серверах, таких как 121, 124, 127, при этом организации-резиденты также не имеют возможности самостоятельно деанонимизировать данные клиентов других организаций. Такое распределение позволяет обеспечить максимальную сохранность данных и предотвратить их утечку. Для компрометации хотя бы малой части данных, хранящихся на координирующем сервере 110 злоумышленникам необходимо скомпрометировать несколько участников системы 100, что значительно сложнее, чем компрометация сервера одной организации.

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

Далее будет представлено общее описание со ссылкой на Фиг 1Б того, как в системе 100 посредством отправки запроса с сервера организации отправителя получают оценку клиента организации получателя, хранящуюся на координирующем сервере 110 компании, предоставляющей услуги по оценке клиентов. На Фиг. 1Б изображена система 100 и относящиеся к ней сервера 151, 152, 153, 154, 155, 156 организаций-резидентов. И сервер 161 организации-нерезидента. Для обеспечения анонимности данных клиентов в одном из вариантов реализации используют ассиметричное шифрование. Как было ранее упомянуто, при ассиметричном шифровании на сервере 151 отправителя шифруют данные с помощью публичного ключа, доступного всем. А на сервере получателя 152 полученные зашифрованные данные расшифровывает с помощью приватного ключа. Публичный ключ доступен всем, а приватный - только получателю. Расшифровать данные можно только с помощью приватного ключа.

На сервере 151 организации отправителя, шифруют идентификатор клиента организации получателя с помощью публичного ключа организации получателя и передают его на координирующий сервер, такой как 110. На координирующем сервере, таком как 110, компании получают зашифрованный идентификатор, но технически не имеют возможности его расшифровать так как не имеют доступа к приватному ключу. Доступ к приватному ключу имеет только сервер 152 организации получателя. На Фиг 1А сервер организации отправителя представлен как сервер 121, а сервер организации получателя как сервер 124. Для расшифровки и получения обезличенного идентификатора зашифрованный идентификатор передают на сервер 152 организации получателя. На сервере 152 организации получателя расшифровывают идентификатор клиента с помощью приватного ключа и тем самым идентифицирует клиента. На сервере 152 организации получателя хранится база данных для обезличивания идентификаторов клиентов, на Фиг. 1Б не представлена, на Фиг 1А изображена как 123, которая содержит соответствие уникального идентификатора и обезличенного идентификатора. Посредством обращения к базе данных для обезличивания идентификаторов клиентов на сервере 152 организации получателя определяют обезличенный идентификатор клиента. С сервера 152 организации получателя передают обезличенный идентификатор получателя на координирующий сервер 110. На координирующем сервере 110 находят оценку клиента, соответствующую полученному обезличенному идентификатору, и возвращают эту оценку на сервер 151 организации отправителя. Таким образом, на сервере 151 организации отправителя получают оценку клиента организации получателя, при этом на координирующем сервере 110 нет технической возможности идентифицировать клиента организации получателя по базе данных оценок, так как координирующий сервер 110 имеет доступ только к обезличенным идентификаторам.

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

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

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

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

Пример данного способа описан ниже.

Давайте рассмотрим на примере, как выполняется обезличивание данных клиента организации-нерезидента. Банк "А" является организацией-резидентом и отправителем, банку "А" соответствует сервер 151. А банк "С" является организатором-нерезидентом и получателем, ему соответствует сервер 161. Обезличивание данных клиента банка "С" выполняют на серверах 153, 154 двух организаций-резидентов. В одной из реализаций банк отправитель может быть одной из двух организации-резидентов, которые будут выполнять обезличивание. А во второй реализации обезличивание может выполняться в двух других организациях-резидентах, где ни одна из организаций-резидентов не является банком-отправителем. Рассмотрим вторую реализацию, где обезличивание выполняют на стороне банка "В" и банка "D". С сервера 151 банка "А" высылают на координирующий сервер 110 запрос, который содержит реквизиты клиента банка "С". При этом реквизиты клиента банка "С" разделены на две части, и первая часть зашифрована с помощью публичного ключа банка "В", а вторая часть зашифрована с помощью публичного ключа банка "D". На координирующем сервере 110 получают запрос и пересылают первую зашифрованную часть на сервер 153 банка "В" для расшифровки и обезличивания, а вторую зашифрованную часть на сервер 154 банка "D". На сервере 153 банка "В", когда получают первую часть реквизита расшифровывают ее с помощью своего приватного ключа и выполняют обезличивание, в результате которого получают первую часть обезличенного идентификатора клиента. На сервере 154 банка "D", когда получают вторую часть реквизита расшифровывают ее с помощью своего приватного ключа банка и выполняют обезличивание, в результате которого получает вторую часть обезличенного идентификатора клиента. С сервера 153 банка "В" отправляют первую часть обезличенного идентификатора на координирующий сервер 110 компании, а с сервера 154 банка "D" отправляют вторую часть обезличенного идентификатора на координирующий сервер 110 компании. На координирующем сервере 110 компании, когда получают обе части обезличенного идентификатора клиента объединяют их и получают обезличенный идентификатор клиента и находят по нему в своей базе данных оценку клиента. С координирующего сервера 110 высылают оценку клиента банку "А" в ответ на полученный ранее запрос.

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

Далее предлагаемые к патентованию способ и система будет описаны пошагово. Способ для удобства был разделен на подготовительный 200 и рабочий 300 этапы.

Подготовительный этап 200 способа обезличенной оценки клиентов организаций для проведения транзакций между организациями представлен на Фиг. 2. Подготовительный этап 200 начинается с шага 210.

На шаге 210 с серверов организаций-резидентов, таких как 121, 124, 127 отправляют базы данных первичных оценок клиентов, такие как 122, 125, 128 и конфигурации организаций-резидентов на координирующий сервер 110. Каждый набор конфигураций организаций-резидентов содержит идентификатор организации-резидента, публичный ключ организации резидента, перечень типов и диапазоны идентификаторов клиентов (шаблоны реквизитов), для которых данная организация-резидент выполняет обезличивание, например БИНы платежных карт и т.д. Также каждый набор конфигураций организаций-резидентов содержит указатель на ресурс, где можно проверить достоверность данных независимо от координирующего сервера, например, таким ресурсом может быть url, указывающий на файл на сервере организации-резидента, либо указатель на реестр центрального банка.

В альтернативном способе реализации базы данных первичных оценок клиентов, такие как 122, 125, 128 не подготавливают и не пересылают на координирующий сервер на подготовительном этапе 200. В этом случае с серверов организаций-резидентов, таких как 121, 124, 127 на координирующий сервер отправляют только конфигурации организаций-резидентов.

Далее будет описан способ с подготовкой и отправкой баз данных первичных оценок клиентов, таких как 122, 125, 128. Базы данных первичных оценок клиентов, такие как 122, 125, 128 представляют собой массивы данных, которые содержат множество обезличенных идентификаторов клиентов, где в соответствие каждому из обезличенных идентификаторов клиентов поставлена первичная оценка благонадежности клиента.

Базы данных первичных оценок клиентов, такие как 122, 125, 128 заранее подготавливают на серверах организаций-резидентов, таких как 121, 124, 127. За основу каждой базы данных берут имеющуюся у организации-резидента базу данных клиентов, на Фиг. 1 не изображена. База данных клиентов представляет собой таблицу, где каждому из уникальных идентификаторов клиентов в соответствие поставлены его данные, например фамилия, имя, отчество, пол, возраст, реквизиты счета и оценка благонадежности клиента.

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

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

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

Из базы данных клиентов удаляют все уникальные идентификаторы клиентов. Данную копию сохраняют на сервере организации-резидента как базу данных первичных оценок клиентов, такую как 122, 125, 128. Базу данных первичных оценок клиентов, такую как 122, 125, 128 высылают на координирующий сервер на шаге 110.

Упомянутую клиентскую базу данных также используют для создания базы данных для обезличивания идентификаторов клиентов, такие как 123, 126, 129. База данных для обезличивания идентификаторов клиентов, такая как 123, 126, 129 создается таким же образом, как и база данных первичных оценок клиентов, такая как 122, 125, 128, но включает в себя уникальные идентификаторы клиентов и соответствующие им обезличенные идентификаторы клиентов. На рабочем этапе 300 база данных для обезличивания идентификаторов клиентов, такая как 123, 126, 129 используется для определения обезличенных идентификаторов клиентов на серверах организаций-резидентов, таких как 121, 124, 127.

На этом шаг 210 заканчивается и алгоритм переходит к шагу 220.

На шаге 220 на координирующем сервере 110 получают конфигурации организаций-резидентов и базы данных первичных оценок клиентов, такие как 122, 125, 128 с серверов, таких как 121, 124, 127 нескольких организаций-резидентов. Базы данных первичных оценок клиентов, такие как 122,125, 128, полученные с нескольких серверов, таких как 121, 124, 127 организаций-резидентов, сохраняют в общую базу данных обезличенных оценок клиентов 111. На этом шаг 220 завершается и способ переходит к шагу 230.

На шаге 230 на координирующем сервере 110 конфигурации организаций-резидентов, полученные на шаге 220, сохраняют в общую базу данных конфигураций организаций-резидентов 112. Доступ к общей базе данных конфигураций организаций-резидентов 112 предоставляют всем серверам, таким как 121, 124, 127 организаций-резидентов. Доступ к общей базе данных предоставляют любым известным способом. Таким образом, с сервера, такого как 121 каждой из организаций-резидентов, посредством отправки обращения к координирующему серверу 110, можно загрузить или обновить конфигурации других организаций-резидентов. После создания общей базы данных конфигураций организаций-резидентов 112, общую базу данных конфигураций организаций-резидентов высылают на все сервера, такие как 121,124,127 организаций-резидентов. Полученную на всех серверах, таких как 121, 124, 127 общую базу данных конфигураций организаций-резидентов сохраняют. На этом шаг 230 завершается и способ переходит к следующему шагу 240.

На шаге 240 на координирующем сервере 110 все сервера организаций-резидентов делят на подгруппы серверов организаций-резидентов, такие как 120, 130, 140, таким образом, чтобы сервера организаций-резидентов в каждой из подгрупп серверов организаций резидентов, такой как 120, 130, 140 не повторялись. Разделение на подгруппы серверов организаций-резидентов, такие как 120, 130, 140, может быть выполнено посредством запуска заранее подготовленного скрипта. Состав подгрупп серверов организаций-резидентов, таких как 120, 130, 140, сохраняют в общую базу данных конфигураций организаций-резидентов, такую как 112. На этом шаг 240 завершается и алгоритм переходит к шагу 250.

На шаге 250 на координирующем сервере 110 для каждой из подгрупп серверов организаций-резидентов, таких как 120, 130, 140, выбирают мастера подгруппы, такой как 121. Мастер подгруппы 121 - это сервер организации-резидента, на котором генерируют публичный и приватный ключ для всей подгруппы организаций-резидентов. На мастера подгрупп, такие как 121, с координирующего сервера 110 отправляют запросы на генерацию приватных и публичных ключей для соответствующих подгрупп серверов организаций-резидентов, таких как 120, 130, 140. На этом шаг 250 заканчивается и способ переходит к следующему шагу 260.

На шаге 260 на каждом из мастеров подгрупп, таком как 121, генерируют публичный и приватный ключ. Пары сгенерированных ключей сохраняют на мастерах подгрупп, таких как 121. Сгенерированные публичный и приватные ключи для каждой подгруппы серверов организаций-резидентов, такой как 120, 130, 140, передают на координирующий сервер. Каждый приватный и ключ перед передачей на координирующий сервер 110 защищают шифрованием или передают по закрытому каналу связи. Дополнительно к этому и публичный, и приватный ключи подгруппы подписывают приватным ключом мастера подгруппы. Благодаря этому получатели публичного и приватного ключей могут проверить, что ключи подгруппы были сгенерированы мастером подгруппы серверов организаций-резидентов.

В одном из способов реализации приватный ключ подгруппы серверов организаций-резидентов асимметрично зашифровывают для передачи каждой из организаций-резидентов, состоящих в подгруппе серверов организаций-резидентов, такой как 120, 130, 140. Так приватный ключ одной подгруппы серверов организаций-резидентов зашифровывают для передачи несколько раз с помощью публичных ключей каждой из организации-резидента, входящей в подгруппу организаций-резидентов 120, 130, 140 за исключением мастера подгруппы. В этом случае на координирующий сервер 110 отправляют несколько зашифрованных файлов, каждый из которых предназначается разным серверам организаций-резидентов 124, 127. На этом шаг 260 заканчивается и способ переходит к следующему шагу 270.

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

На шаге 270 на координирующем сервере 110 получают публичные и зашифрованные приватные ключи для подгрупп серверов организаций-резидентов, таких как 120, 130, 140. Полученные ключи сохраняют в общей базе данных конфигураций организаций-резидентов 112 на координирующем сервере 110. При этом каждый и приватных ключей в общей базе данных конфигураций организаций-резидентов 112 ассоциируется с сервером организации-резидента, которому данный приватный ключ предназначается. А публичный ключ в базе данных ассоциируется с подгруппой серверов организаций резидентов, такой как 124, для которой он был сгенерирован. На этом шаг 270 завершается и способ переходит к шагу 280.

На шаге 280 с каждого из серверов, такого как 124, 127 организаций-резидентов, кроме мастера подгруппы, отправляют запрос на координирующий сервер 110 для загрузки ключей подгруппы серверов организаций-резидентов. В ответ на каждый запрос в общей базе данных конфигураций организаций-резидентов 112 находят публичный ключ, соответствующий подгруппе серверов организаций резидентов 120, 130, 140 к которой относится организация-резидент, приславшая запрос. Также в общей базе данных конфигураций организаций-резидентов находят зашифрованный приватный ключ, ассоциированный с сервером данной организации-резидента. Найденные публичный и приватный ключи отправляют на сервер, такой как 124, 127 организации-резидента. Описанным образом ключи высылают на все сервера, такие как 124, 127 организаций-резидентов. На серверах, таких как 124, 127, организаций-резидентов сохраняют полученные публичные ключи. Приватные ключи подгрупп серверов организаций-резидентов расшифровывают с помощью приватных ключей серверов организаций-резидентов. Расшифрованные приватные ключи подгрупп серверов организаций резидентов также сохраняют. На этом шаг 280 и подготовительный этап 200 завершаются и способ переходит к рабочему этапу 300.

Рабочий этап 300 представлен на Фиг 3А и 3Б. Рабочий этап начинается с шага 310.

На шаге 310 на сервере организации отправителя получают запрос на проведение операции от клиента. Организация отправитель является организацией-резидентом, которая выполняет запрос на проведение операции. Запрос на проведение операции включает реквизиты клиента в организации получателе и реквизиты самой организации получателя, идентификатор операции. Далее определяют, является ли организация получатель организацией-резидентом или нет, для этого реквизиты организации получателя из запроса на проведение операции сверяют с реквизитами организаций-резидентов в базе данных конфигураций организаций-резидентов, сохраненной на шаге 230. Если организация получатель является организацией-резидентом, то способ переходит к шагу 311. Если организация получатель не является организацией-резидентом, то способ переходит к шагу 321.

Сначала будет описана одна часть способа, реализуемая, если организация получатель является организацией-резидентом. Данная часть состоит из шагов 311-314 и начинается с шага 311.

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

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

Запрос на получение оценки передают на координирующий сервер 110. На этом шаг 311 завершается и способ переходит к шагу 312.

На шаге 312 запрос на получение оценки получают на координирующем сервере 110. Из запроса на получение оценки извлекают данные: реквизиты организации, идентификатор операции, зашифрованный идентификатор клиента. По реквизитам организации получателя в общей базе данных конфигураций организаций-резидентов находят ее конфигурации, например, такие как ip-адрес сервера организации получателя, идентификатор операции и сохраняют во временной памяти сервера. Формируют запрос на обезличивание идентификатора клиента. Запрос на обезличивание содержит зашифрованный идентификатор клиента, ip-адрес сервера организации получателя.

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

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

На шаге 314 на сервере организации получателя по идентификатору получателя в базе данных для обезличивания идентификаторов клиентов определяют обезличенный идентификатор клиента. Обезличенный идентификатор клиента передают на координирующий сервер 110 в ответ на запрос на обезличивание идентификатора клиента, полученный на шаге 313. На этом шаг 314 завершается. Шаг 314 - это заключительный шаг одного способа реализации, который выполняется в случае, если организация получатель является организацией-резидентом. Следующий шаг - это шаг 330.

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

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

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

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

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

Далее для простоты будет описана реализация, при которой выбирают две подгруппы серверов организаций-резидентов на сервере организации отправителя. Шаг 321 завершается выбором двух подгрупп серверов организаций-резидентов и способ переходит к шагу 322.

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

Идентификатор клиента = "+79680148862", то:

первая часть идентификатора клиента = hash("+98186"), т.е. хэш от всех нечетных

символов из идентификатора клиента,

вторая часть идентификатора клиента = hash("760482"), т.е. хэш от всех четных

символов из идентификатора клиента

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

В другом дополнительном способе реализации для достижения большей надежности на шаге 322, при подготовке запроса на получение оценки, помимо зашифрованной первой части реквизита получателя, отправляют значение общей функции от хэш-значения. Например, если исходный реквизит "+79680148862", то первая часть реквизита может выглядеть так "+98186", а значение общей функции от хэш значения sha256(""+98186")=294fe3b55de4f271 е 15e2086d88b55a152с0с88b6е1с871362 сасе2b81f75c21, может быть определена как количество цифр в строковом представлении зашифрованной первой части идентификатора, то есть 41. В этом случае по полученному значению общей функции от хэш-значения первой части идентификатора на координирующем сервере на шаге 323 выбирают обезличивающую организацию, или несколько обезличивающих организаций из подгруппы для получения избыточных частей обезличенных идентификаторов для обеспечения отказоустойчивости системы.

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

На этом шаг 322 завершается и способ переходит к шагу 323.

На шаге 323 на координирующем сервере 110 получают два запроса на получение оценки. Если на шаге 322 передавался один запрос, содержащий две части идентификатора, то на шаге 323 на координирующем сервере 110 получают один запрос на получение оценки.

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

По идентификатору подгруппы серверов организаций-резидентов из первого запроса на получение оценки в общей базе данных конфигураций организаций-резидентов находят первую обезличивающую организацию. Первая обезличивающая организация - это первая доступная организация из первой подгруппы серверов организаций-резидентов. Формируют первый запрос на обезличивание. Первый запрос на обезличивание содержит первую часть идентификатора клиента, зашифрованную с помощью публичного ключа первой подгруппы серверов организаций-резидентов, выбранной на шаге 321. Сформированный первый запрос на обезличивание идентификатора клиента сохраняют на координирующем сервере 110. Аналогичные действия выполняются для второго запроса на обезличивание идентификатора клиента. Для второго запроса на обезличивание идентификатора клиента находят вторую обезличивающую организацию из второй подгруппы серверов организаций-резидентов. Сформированный второй запрос на обезличивание идентификатора клиента также сохраняют на координирующем сервере 110. На этом шаг 323 заканчивается и способ переходит к шагу 324.

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

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

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

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

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

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

Вторую часть обезличенного идентификатора клиента с сервера второй обезличивающей организации передают на координирующий сервер 110.

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

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

На этом шаг 327 завершается и алгоритм переходит к шагу 328.

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

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

На шаге 340 обезличенную оценку клиента организации получателя отправляют в ответ на запрос на получение оценки на сервер организации отправителя. На этом шаг 340 завершается и способ переходит к шагу 350.

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

В альтернативном способе реализации очередность шагов может отличаться от представленной на Фиг. 3А и 3Б. Так, способ может начаться с шага 350, а потом перейти к выполнения шагов 310-328. Другие последовательности исполнения шагов описываемого способа также возможны и будут очевидны для специалиста в уровне техники.

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

Шаги 350 и 360 являются опциональными и в некоторых реализациях могут не выполняться.

На Фиг. 4 изображен пример реализации 400 рабочего этапа 300. Далее пример реализации 400 будет описан подробно.

На вычислительном устройстве клиента отправителя 410, обслуживающегося в организации отправителе 420, выполняют аутентификацию 461, например, посредством запуска приложения организации отправителя. Организация отправитель может быть банком, коммерческой организацией или государственным учреждением. На сервере организации отправителя 420 получают запрос на авторизацию 461 и в ответ на получение запроса на авторизацию высылают данные сессии 462 на координирующий сервер 430. Если авторизация прошла успешно, то с вычислительного устройства клиента отправителя высылают запрос на проведение операции 463 через интерфейс приложения организации отправителя. Запрос на проведение операции содержит реквизиты клиента получателя в организации получателе, реквизиты организации получателя и детали операции, такие как сумма перевода. Реквизитами получателя в зависимости от типа организации могут быть любые данные позволяющие идентифицировать пользователя в организации получателе, например, фамилия, имя, отчество, логин, номер телефона, банковский счет, номер счета, уникальный номер, идентификатор электронного или криптовалютного кошелька и т.д. В ответ на получение запроса на проведение операции на сервере организации отправителя 420 выполняют анти-фрод анализ 464. Анти-фрод анализ 464 может быть любым известным алгоритмом для определения вероятности мошенничества, например, на сервере организации может быть запущен скрипт, посредством которого проверят, не находятся ли реквизиты клиента получателя в черном списке мошенников.

Если по результатам анти-фрод анализа 464 операция была классифицирована как подозрительная, то с сервера организации отправителя высылают запрос на получение оценки клиента 465 на координирующий сервер 430. Запрос на получение оценки клиента 465 содержит идентификатор сессии, идентификатор операции, идентификатор клиента отправителя, идентификатор организации получателя и зашифрованный идентификатор отправителя. Способ шифрования идентификатора отправителя был подробно описан со ссылкой на Фиг. 3А.

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

В ответ на получение запроса на обезличивание идентификатора клиента 466 на сервере организации получателя выполняют расшифровку зашифрованного идентификатора клиента и обезличивание идентификатора клиента 468. Подробно способ обезличивание идентификатора клиента был описан ранее со ссылкой на Фиг. 3А.

Обезличенный идентификатор клиента 469 с сервера организации получателя высылают на координирующий сервер. На координирующем сервере получают обезличенный идентификатор клиента 469. По полученному обезличенному идентификатору клиента в базе данных оценок клиентов на координирующем сервере определяют оценку клиента.

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

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

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

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

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

В ответ на получение дополнительной информации 476 на сервере организации отправителя запускают анти-фрод анализ 477 с целью подтвердить подлинность дополнительных данных, полученных от клиента отправителя. В случае если результаты анти-фрод анализа 477 подтверждают подлинность дополнительной информации 476, создают запрос на обновление оценки клиента получателя 478. Запрос на обновление оценки клиента получателя 478 содержит идентификатор операции, обновленную оценку и причину изменения оценки. В ответ на получение запроса на обновление оценки клиента отправителя 478 на координирующем сервере выполняют обновление оценки клиента отправителя и обновление оценки клиента получателя 479. Обновленные оценки клиентов сохраняют в общей базе данных оценок клиентов.

Дополнительно на шаге 479 с координирующего сервера на сервер организации-получателя отправляют сообщение об оценке клиента получателя.

На этом описываемый пример реализации 400 завершается.

Далее со ссылкой на Фиг. 5 будет описан второй пример реализации способа 300.

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

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

На сервере 503 организации отправителя получают запрос на аутентификацию 502 и в ответ на получение запроса на аутентификацию 502 высылают данные сессии на координирующий сервер 503. Если аутентификация прошла успешно, то на вычислительном устройстве 501 клиента отправителя создают запрос на проведение операции 505 через интерфейс приложения организации отправителя. Запрос на проведение операции 505 содержит данные клиента получателя, данные клиента отправителя и данные сессии. С вычислительного устройства 501 клиента посылают запрос на проведение операции 505.

В ответ на получение запроса на проведение операции 505 на сервере 503 организации отправителя выполняют анти-фрод анализ 506 с целью подтвердить подлинность запроса на проведение операции 505. Анти-фрод анализ 506 может быть выполнен любым известным методом. Далее на сервере 503 организации отправителя создают запрос на получение оценки 507. Для создания запроса на получение оценки 507 определяют подгруппы организаций-резидентов, которые будут выполнять обезличивание. Подробно процесс определения подгрупп организаций-резидентов описан ранее со ссылкой на Фиг. 3А. Идентификатор получателя разделяют две или более части. Каждую из частей идентификатора зашифровывают. Способы разделения идентификатора на части описаны ранее со ссылкой на Фиг. 3А. Первую часть идентификатора клиента получателя зашифровывают с помощью публичного ключа первой обезличивающей организации, где первая обезличивающая организация - это организация из первой подгруппы организаций-резидентов. Вторую часть идентификатор клиента получателя зашифровывают с помощью публичного ключа второй обезличивающей организации, где вторая обезличивающая организация - это организация из второй подгруппы организаций-резидентов. Запрос на получение оценки 507 содержит зашифрованную первую часть идентификатора клиента получателя, зашифрованную вторую часть идентификатора клиента получателя, идентификатор сессии, идентификатор операции, идентификатор клиента отправителя. Запрос на получение оценки 507 пересылают с сервера 503 организации отправителя на координирующий сервер 504.

На координирующем сервере 504 в ответ на получение запроса на получение оценки 507 запрос на получение оценки 507 сохраняют. На основании данных, полученных в запросе на получение оценки 507 создают два запроса на обезличивание, первый запрос на обезличивание 508 и второй запрос на обезличивание 509. Первый запрос на обезличивание 508 содержит зашифрованный первый идентификатор клиента получателя. Второй запрос на обезличивание 509 содержит зашифрованный второй идентификатор клиента получателя. Первый запрос на обезличивание 508 отправляют на сервер 510 первой обезличивающей организации. Второй запрос на обезличивание 509 отправляют на сервер 511 второй обезличивающей организации.

На сервере 510 первой обезличивающей организации получают первый запрос на обезличивание 508 от координирующего сервера 504. Из первого запроса на обезличивание

508 извлекают зашифрованный первый идентификатор клиента получателя и расшифровывают с помощью приватного ключа первой подгруппы серверов организаций-резидентов. Расшифрованную первую часть идентификатора обезличивают. Подробно способ обезличивания описан со ссылкой на Фиг. 3А. Обезличенную первую часть идентификатора клиента получателя 512 передают на координирующий сервер 504.

На сервере второй обезличивающей организации 511 получают второй запрос на обезличивание 509 от координирующего сервера 504. Из второго запроса на обезличивание

509 извлекают зашифрованный второй идентификатор клиента получателя и расшифровывают с помощью приватного ключа второй подгруппы серверов организаций-резидентов. Расшифрованную вторую часть идентификатора обезличивают. Подробно способ обезличивания описан со ссылкой на Фиг. 3А. Обезличенную вторую часть идентификатора клиента получателя 513 передают на координирующий сервер 504.

На координирующем сервере 504 получают первую часть обезличенного идентификатор клиента получателя 512 и вторую часть обезличенного идентификатора клиента получателя 513. Обе части обезличенного идентификатора клиента получателя объединяют, например, посредствам конкатенации и получают обезличенный идентификатор клиента получателя 514. По обезличенному идентификатору клиента получателя 514 в общей базе данных оценок клиентов находят соответствующую оценку 515. Оценку 515 высылают на сервер 503 организации отправителя в ответ на ранее полученный запрос на получение оценки 507. Ответ на запрос на получение оценки содержит оценку 515 клиента получателя и идентификатор операции.

На сервере организации отправителя 503 выполняют анти-фрод анализ 516 с целью подтверждения того, что полученная оценка 515 клиента получателя не является мошеннической. Анти-фрод анализ 516 может быть выполнен любым известным способом.

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

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

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

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

В ответ на получение дополнительной информации 521 на сервере 503 организации отправителя запускают анти-фрод анализ 522 с целью подтвердить подлинность дополнительных данных, полученных от клиента отправителя. В случае если результаты анти-фрод анализа 522 подтверждают подлинность дополнительной информации создают запрос на обновление оценки 523. Запрос на обновление оценки 523 содержит идентификатор операции, обновленную оценку и причину изменения оценки. В ответ на получение запроса на обновление оценки 523 на координирующем сервере 504 выполняют обновление оценки клиента получателя 524. Дополнительно может быть выполнено и обновление оценки клиента отправителя. Обновленные оценки клиентов сохраняют в общей базе данных клиентов.

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

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

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

В общем случае устройство (600) содержит такие компоненты, как: один или более процессоров (601), по меньшей мере одну память (602), средство хранения данных (603), интерфейсы ввода/вывода (604), средство В/В (605), средства сетевого взаимодействия (606).

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

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

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

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

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

В качестве средств В/В данных (605) может использоваться клавиатура. Помимо клавиатуры, в составе средств В/В данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.

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

Компоненты устройства (600) сопряжены посредством общей шины передачи данных (610).

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

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

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

на подготовительном этапе:

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

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

на рабочем этапе:

- получают запрос от сервера организации отправителя, где запрос включает:

- идентификатор организации отправителя;

- идентификатор организации получателя;

- зашифрованный идентификатор клиента;

- в ответ на то, что идентификатор организации получателя является идентификатором организации-резидента:

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

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

- в ответ на то, что идентификатор организации получателя является идентификатором организации-нерезидента:

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

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

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

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

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

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

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

- сохраняют обновленную оценку клиента.

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

- идентификатор организации-резидента;

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

- url организации-резидента;

- шаблоны идентификаторов клиентов, которые обезличиваются на сервере организации.

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

4. Способ по п. 3, где url ресурса не связан с координирующим сервером.

5. Способ по п. 3, где url ресурс является официальным url ресурсом организации-резидента.

6. Способ по п. 1, где на подготовительном этапе разделяют сервера организаций-резидентов на подгруппы серверов организаций-резидентов.

7. Способ по п. 6, где на подготовительном этапе получают публичный ключ от подгруппы серверов организаций-резидентов из подгрупп серверов организаций резидентов.

8. Способ по п. 7, где ассоциируют полученный публичный ключ с подгруппой серверов организаций-резидентов.

9. Способ по п. 7, где создают скрипт для выбора нескольких подгрупп организаций-резидентов.

10. Способ по п. 9, где скрипт для выбора нескольких подгрупп организаций-резидентов передают на сервер организации отправителя.

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

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

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

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

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

16. Способ по п. 15, где общая база данных обезличенных оценок клиентов включает:

- обезличенный идентификатор клиента;

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

- идентификатор организации-нерезидента;

- идентификатор организации-резидента.

17. Способ по п. 16, где обезличенный идентификатор клиента, ассоциирован с по меньшей мере одним избыточным обезличенным идентификатором клиента.

18. Способ по п. 17, где по меньшей мере один избыточный обезличенный идентификатор клиента аналогичен обезличенному идентификатору клиента.

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

20. Способ по п. 19, где дополнительный запрос инициирован сервером.

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

22. Способ по п. 1, где по меньшей мере один сервер обезличивающей организации является по меньшей мере одним сервером организации-резидента.

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

24. Способ по п. 1, где шифрование выполняется методом ассиметричного шифрования.

25. Способ по п. 1, где шифрование выполняется методом симметричного шифрования.

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

27. Способ по пп. 24 и 25, где ключ подгруппы дополнительно используется для шифрования.

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

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

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

31. Способ по п. 1, где объединение первой части обезличенного идентификатора клиента и второй части обезличенного идентификатора клиента реализовано посредством конкатенации первой части обезличенного идентификатора клиента и второй части обезличенного идентификатора клиента.

32. Способ по п. 1, где организация-резидент является организацией, заранее передающей по меньшей мере одно из:

- данные на сервер для создания базы данных обезличенных клиентских оценок;

- конфигурации организации.

33. Способ по п. 1, где обновленную оценку клиента передают организации получателю.

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

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

- вычислительное устройство, выполненное с возможностью выполнения способа по любому из пп. 1-33.