СЕТЕВАЯ СИСТЕМА ДЛЯ ВЫБОРКИ СВЯЗАННЫХ С КОНФИГУРИРОВАНИЕМ ДАННЫХ
NETWORK SYSTEM FOR SAMPLING CONFIGURATION RELATED DATA

Область изобретения
Настоящее изобретение относится к области сетевых систем и, прежде всего, к сетевым системам, содержащим клиентский модуль, который делает запрос на получение связанных с конфигурированием данных.
Уровень техники
Обычно связанные с конфигурированием данные для клиентских модулей, такие как лицензионные ключи, сетевые адреса провайдера, зарегистрированные имена, персонализация и корпоративный стиль и т.д., поставляются клиентскому модулю, то есть пользователю, управляющему клиентским модулем, по электронной почте.
Однако обычные способы поставки связанных с конфигурированием данных иногда обеспечивают пользователю недостаточный комфорт.
Ввиду вышеописанной ситуации существует потребность в улучшенной технике, которая делает возможным предоставление сетевой системы с улучшенными характеристиками.
Сущность изобретения
Эта потребность может быть удовлетворена посредством предмета согласно независимым пунктам. Предпочтительные варианты осуществления предложенного в данном документе предмета описаны посредством зависимых пунктов.
Согласно одному варианту осуществления предложенного в данном документе предмета, предоставлена сетевая система, которая сетевая система содержит: поисковый модуль (например, сервер поиска провайдера, в данном документе также называемый СПП), согласующий модуль, имеющий запоминающее устройство, и клиентский модуль, выполненный для поставки связанных с пользователем данных в поисковый модуль, причем связанные с пользователем данные, основаны на данных пользователя (например, на первой идентификационной метке данных пользователя), данные пользователя (например, адрес электронной почты, номер телефона, и т.д.) ассоциированы с пользователем и связанные с пользователем данные (например, первая идентификационная метка данных пользователя) обеспечивают однозначную идентификацию данных пользователя, причем поисковый модуль (например, СПП) выполнен для осуществления выборки идентификационных данных (например, идентификатора провайдера) из согласующего модуля с использованием связанных с пользователем данных (например, первой идентификационной метки данных пользователя), и причем идентификационные данные (например, идентификатор провайдера) ассоциированы с данными пользователя (например, с адресом электронной почты пользователя), и причем согласующий модуль, выполнен для осуществления выборки из запоминающего устройства идентификационных данных (например, идентификатора провайдера), ассоциированных с данными пользователя, и причем согласующий модуль выполнен для поставки идентификационных данных (например, идентификатора провайдера) поисковому модулю (например, СПП), и причем поисковый модуль (например, СПП) выполнен для осуществления выборки связанных с конфигурированием данных (унифицированного определителя местонахождения ресурса провайдера, зарегистрированного имени и т.д.) для поставляемого пользователю обслуживания, и причем поисковый модуль выполнен для осуществления выборки связанных с конфигурированием данных (например, URL провайдера) с использованием идентификационных данных (например, идентификатора провайдера).
Этот аспект предложенного в данном документе предмета основан на той идее, что посредством разделения процессов выборки связанных с конфигурированием данных для специфического для пользователя обслуживания, и идентификации соответствующего пользователя может быть предоставлена сетевая система, которая обеспечивает высокий уровень пользовательского комфорта и безопасности. Разделение процессов выборки связанных с конфигурированием данных и идентификации пользователя может быть обеспечено посредством поискового модуля и согласующего модуля согласно вариантам осуществления предложенного в данном документе предмета.
Согласно одному варианту осуществления данные пользователя идентифицируют пользователя однозначно. Например, согласно одному варианту осуществления данные пользователя могут быть представлены адресом электронной почты пользователя или номером телефона пользователя (или идентификационными метками таких данных). Однако другие данные пользователя также могут быть использованы в связи с вариантами осуществления предложенного в данном документе предмета.
Предоставляемое пользователю обслуживание может быть представлено специфическим для пользователя обслуживанием (предоставляемым только единственному пользователю) или специфическим для провайдера обслуживанием (предоставляемым нескольким пользователям).
Согласно одному варианту осуществления выборка связанных с конфигурированием данных с использованием идентификационных данных является выборкой связанных с конфигурированием данных, которые ассоциированы с идентификационными данными. То обстоятельство, что выбранные связанные с конфигурированием данные ассоциированы с идентификационными данными, не обязательно подразумевает, что связанные с конфигурированием данные однозначно идентифицированы посредством идентификационных данных. Скорее, связанные с конфигурированием данные могут быть однозначно идентифицированы посредством идентификационных данных и некоторых других данных, например связанных с пользователем данных (например, идентификационной метки адреса электронной почты пользователя) и/или иных связанных с пользователем данных (например, идентификационной метки пароля пользователя).
Согласно одному варианту осуществления поисковый модуль выполнен для осуществления выборки связанных с конфигурированием данных локально, то есть в пределах поискового модуля. Согласно другому варианту осуществления поисковый модуль выполнен для осуществления выборки связанных с конфигурированием данных из удаленного модуля.
Согласно одному варианту осуществления связанные с пользователем данные являются анонимными данными, то есть данными, которые не обеспечивают возможность восстановления данных пользователя из связанных с пользователем данных, по меньшей мере, с приемлемой вычислительной мощностью. Например, согласно одному варианту осуществления связанные с пользователем данные являются идентификационной меткой данных пользователя. Эта идентификационная метка данных пользователя может быть рассмотрена как первая идентификационная метка данных пользователя. Следовательно, согласно вышеупомянутому техническому описанию связанных с пользователем данных, первая идентификационная метка данных пользователя основана на данных пользователя, и первая идентификационная метка обеспечивает однозначную идентификацию данных пользователя.
Характеристики сетевой системы и безопасности могут быть повышены с использованием идентификационной метки данных пользователя для осуществления выборки связанных с конфигурированием данных для специфического для пользователя обслуживания. Согласно другому варианту осуществления связанные с пользователем данные могут быть представлены зашифрованной версией данных пользователя. Другие типы связанных с пользователем данных также являются возможными. Однако использование идентификационных меток способно обеспечить более высокую безопасность сетевой системы.
Согласно одному варианту осуществления идентификационная метка «входных данных» является данными, полученными из входных данных однозначным способом. Согласно одному варианту осуществления термин «идентификационная метка» подразумевает нахождение идентификационной метки посредством математической функции, которая воспроизводимо создает идентификационную метку из входных данных.
Таким образом, идентификационная метка обеспечивает однозначную идентификацию идентификационной метки. Согласно одному варианту осуществления идентификационная метка не обеспечивает возможность вычисления входных данных из идентификационной метки, по меньшей мере, с приемлемой вычислительной мощностью. Поэтому, такая функция для нахождения идентификационной метки может быть рассмотрена как вычислительно необратимая функция. Типичными функциями для нахождения идентификационной метки являются так называемыми хеш-функции, например MD5, SHA1, SHA2, и т.д. Необходимо принять во внимание, что используемая для вычисления идентификационной метки функция должна быть доступной для модулей, которые оценивают (например, проверяют) входные данные на основании идентификационной метки входных данных. С этой целью, используемая для вычисления идентификационной метки функция может быть представлена (например, жестко задана или сохранена) в соответствующих модулях. Согласно другому варианту осуществления используемая для вычисления идентификационной метки функция может быть поставлена в том же цикле передачи, который передает идентификационную метку приемному модулю, или в отдельном цикле передачи конфигурации.
Согласно одному варианту осуществления идентификационная метка может быть представлена соленой идентификационной меткой, которая вычислена посредством комбинирования входных данных с криптографической солью, и вычисления идентификационной метки комбинации соли и входных данных (то есть идентификационной метки для (соль + входные данные)). Согласно одному варианту осуществления данные пользователя являются входными данными в вышеупомянутом смысле. Обычно в данном документе следует понимать, что, если используется соленая идентификационная метка входных данных, наряду с обеспечением посредством соленой идентификационной метки однозначной идентификации входных данных, кроме того, криптографическая соль необходима для фактической идентификации данных пользователя.
Согласно одному варианту осуществления идентификационная метка является итеративной идентификационной меткой. Например, итеративная идентификационная метка может быть сгенерирована посредством двукратного или многократного хеширования входных данных. Образец итеративной идентификационной метки получен посредством комбинирования соли с входными данными и многократного хеширования результата. Например, идентификационная метка других данных пользователя может быть представлена идентификационной меткой соленой идентификационной метки пароля пользователя (=хеш (соль|хеш (пароль)).
Осуществление выборки идентификационных данных из согласующего модуля с использованием связанных с пользователем данных может быть выполнено любым подходящим способом, например посредством поставки связанных с пользователем данных в согласующий модуль или посредством поставки данных, которые получены из связанных с пользователем данных, в согласующий модуль.
Согласно одному варианту осуществления поисковый модуль, кроме того, выполнен для поставки идентификационной метки данных пользователя в согласующий модуль. Эта идентификационная метка данных пользователя, которая поставлена в согласующий модуль, может быть рассмотрена как вторая идентификационная метка данных пользователя. Согласно одному варианту осуществления вторая идентификационная метка данных пользователя основана на первой идентификационной метке данных пользователя. Согласно другому варианту осуществления вторая идентификационная метка обеспечивает однозначную идентификацию данных пользователя. Следует заметить, что термин «первая идентификационная метка» использован для идентификационной метки, посланной из клиентского модуля в поисковый модуль, а термин «вторая идентификационная метка» использован для идентификационной метки, посланной из поискового модуля в согласующий модуль. Однако использование терминов «первая» и «вторая» в этом отношении нельзя рассматривать как ограничение.
Обычно в данном документе термин «основан» предназначен для включения в себя значения «отличен, но получен из» и значения «идентичен». Другими словами, термин «основан» должен быть интерпретирован как включающий в себя значения «получен из» и «является».
Следовательно, в варианте осуществления вторая идентификационная метка данных пользователя является первой идентификационной меткой данных пользователя. Другими словами, согласно одному варианту осуществления поисковый модуль может быть выполнен для получения первой идентификационной метки данных пользователя из клиентского модуля и для направления первой идентификационной метки данных пользователя в согласующий модуль.
Согласно другому варианту осуществления вторая идентификационная метка данных пользователя может быть получена из первой идентификационной метки данных пользователя.
Согласно одному варианту осуществления согласующий модуль выполнен для осуществления выборки из запоминающего устройства ассоциированных с данными пользователя идентификационных данных с использованием второй идентификационной метки данных пользователя. Например, согласующий модуль может сохранять в запоминающем устройстве несколько идентификационных меток данных пользователя (например, нескольких пользователей) и ассоциированные идентификационные данные. Следовательно, в таком варианте осуществления идентификационные данные могут быть выбраны посредством согласующего модуля путем поиска в запоминающем устройстве идентификационной метки, которая соответствует второй идентификационной метке данных пользователя, и отбора идентификационных данных, ассоциированных с этой соответствующей идентификационной меткой.
Согласно одному варианту осуществления согласующий модуль содержит систему баз данных, которая хранит в запоминающем устройстве первую идентификационную метку данных пользователя и ассоциированные идентификационные данные для нескольких пользователей. За счет сохранения первой идентификационной метки данных пользователя согласующий модуль не должен сохранять данные пользователя как таковые. Это может улучшить безопасность сетевой системы.
Связанные с конфигурированием данные могут быть представлены данными, необходимыми для конфигурирования доступа клиентского модуля к удаленному модулю, например к модулю провайдера. Например, связанные с конфигурированием данные могут быть представлены информацией о домене (например, URL) модуля провайдера.
Согласно одному варианту осуществления сетевая система содержит модуль провайдера. Согласно одному варианту осуществления модуль провайдера доступен посредством клиентского модуля. Например, согласно одному варианту осуществления провайдер является провайдером специфического для пользователя обслуживания, для которого предназначены связанные с конфигурированием данные. Согласно одному варианту осуществления поисковый модуль выполнен для поставки связанных с конфигурированием данных по меньшей мере в один компонент системы, который должен быть конфигурирован для обеспечения клиентскому модулю возможности получения доступа к модулю провайдера, или для выполнения специфической для провайдера персонализации, маркировки или отображения. Согласно другому варианту осуществления поисковый модуль выполнен для поставки связанных с конфигурированием данных в клиентский модуль. Согласно другим вариантам осуществления связанные с конфигурированием данные могут быть поставлены в различные компоненты системы для использования посредством клиентского модуля. Согласно одному варианту осуществления связанные с конфигурированием данные (например, URL провайдера) являются частью ответного цикла передачи, поставляемого посредством поискового модуля, причем ответный цикл передачи, кроме того, содержит индикатор состояния, указывающий на состояние данных пользователя, соответствующих связанным с пользователем данным. Например, согласно одному варианту осуществления индикатор состояния указывает на принятие или на непринятие данных пользователя, соответствующих связанным с пользователем данным (например, соответствующих первой идентификационной метке), в качестве действительных.
Согласно одному варианту осуществления поисковый модуль выполнен для поставки идентификационной метки данных пользователя в модуль провайдера, например, для проверки правильности данных пользователя посредством модуля провайдера и/или для осуществления выборки связанных с конфигурированием данных из модуля провайдера. Эта идентификационная метка данных пользователя, которая поставлена из поискового модуля в модуль провайдера, также упоминается в данном документе как третья идентификационная метка.
Согласно одному варианту осуществления третья идентификационная метка основана (например, получена из или идентична) на первой идентификационной метке данных пользователя. Например, третья идентификационная метка может быть представлена идентификационной меткой первой идентификационной метки. Согласно другому варианту осуществления третья идентификационная метка идентична первой идентификационной метке. Другими словами, в таком варианте осуществления поисковый модуль выполнен для направления полученной от клиентского модуля первой идентификационной метки в модуль провайдера.
Согласно одному варианту осуществления модуль провайдера выполнен для поставки некоторой информации о состоянии относительно действительности данных пользователя в поисковый модуль в ответ на третью идентификационную метку, полученную от поискового модуля. Например, согласно одному варианту осуществления модуль провайдера выполнен для поставки информации о состоянии, которая указывает на то, что третья идентификационная метка соответствует действительным данным пользователя, в поисковый модуль, если третья идентификационная метка соответствует действительным данным пользователя. Подтверждение правильности данных пользователя может повысить безопасность сетевой системы.
Согласно одному варианту осуществления модуль провайдера выполнен для поставки связанных с конфигурированием данных или, по меньшей мере, части связанных с конфигурированием данных в ответ на получение третьей идентификационной метки из поискового модуля.
Согласно другому варианту осуществления поисковый модуль выполнен для осуществления выборки связанных с конфигурированием данных с использованием идентификационных данных. Например, поисковый модуль может использовать идентификационные данные для идентификации модуля провайдера и для передачи в идентифицированный модуль провайдера третьей идентификационной метки данных пользователя. Идентификация провайдера включает в себя в варианте осуществления выборку сетевого адреса модуля провайдера, ассоциированного с модулем провайдера. Согласно одному варианту осуществления поисковый модуль выполнен для выборки связанных с конфигурированием данных из модуля провайдера с использованием третьей идентификационной метки, например посредством поставки третьей идентификационной метки в модуль провайдера. Согласно одному варианту осуществления модуль провайдера содержит запоминающее устройство или базу данных, причем запоминающее устройство или база данных сохраняют идентификационные данные и ассоциированные сетевые адреса для нескольких провайдеров.
Согласно одному варианту осуществления клиентский модуль выполнен для поставки других связанных с пользователем данных (например, соленой идентификационной метки пользовательского пароля или идентификационной метки пользовательского пароля) в поисковый модуль, причем другие связанные с пользователем данные основаны на других данных пользователя (например, на пользовательском пароле), другие данные пользователя ассоциированы с пользователем, и другие связанные с пользователем данные обеспечивают однозначную идентификацию других данных пользователя. Согласно одному варианту осуществления другие данные пользователя являются пользовательским паролем пользователя. Например, пароль может быть представлен паролем пользователя, необходимым пользователю для регистрации в модуле провайдера, в модуле подпровайдера, ассоциированном с модулем провайдера, или в другом компоненте системы. Согласно другим вариантам осуществления также и другие зашифрованные данные могут быть использованы в качестве других данных пользователя.
Согласно другому варианту осуществления другие связанные с пользователем данные являются идентификационной меткой других данных пользователя. Эта идентификационная метка других связанных с пользователем данных, поставляемых из клиентского модуля в поисковый модуль, также упоминается в дальнейшем как первая идентификационная метка других связанных с пользователем данных. Согласно вариантам осуществления первая идентификационная метка других связанных с пользователем данных может быть представлена соленой идентификационной меткой и/или может быть представлена идентификационной меткой связанных с пользователем данных. За счет поставки других связанных с пользователем данных в поисковый модуль безопасность сетевой системы и производительность ее работы могут быть повышены.
Согласно одному варианту осуществления поисковый модуль выполнен для поставки данных, которые основаны на других связанных с пользователем данных, в модуль провайдера и для получения в ответ на это информации о состоянии относительно действительности по меньшей мере одних данных из числа других данных пользователя, других связанных с пользователем данных и данных, основанных на других связанных с пользователем данных. Согласно одному варианту осуществления данные, основанные на других связанных с пользователем данных, являются идентификационной меткой других данных пользователя. Эта идентификационная метка других связанных с пользователем данных, которые поставлены из поискового модуля в модуль провайдера, также в дальнейшем упоминается как вторая идентификационная метка других связанных с пользователем данных. Согласно одному варианту осуществления вторая идентификационная метка других данных пользователя основана (например, идентична или получена из) на первой идентификационной метке данных пользователя. Например, эта вторая идентификационная метка может быть представлена идентификационной меткой первой идентификационной метки других данных пользователя. Согласно другому варианту осуществления вторая идентификационная метка является первой идентификационной меткой. Другими словами, в таком варианте осуществления поисковый модуль выполнен для направления первой идентификационной метки полученных от клиентского модуля других данных пользователя в модуль провайдера. Согласно одному варианту осуществления данные, которые основаны на других связанных с пользователем данных, поставляются, наравне с идентификационной меткой данных пользователя, в модуль провайдера, и, факультативно, модуль провайдера выполнен для поставки связанных с конфигурированием данных или, по меньшей мере, части связанных с конфигурированием данных в ответ на получение из поискового модуля данных, которые основаны на других связанных с пользователем данных (например, на соленом хеше хеша пароля пользователя), и идентификационной метки данных пользователя (например, адреса электронной почты пользователя).
Согласно одному варианту осуществления модуль провайдера может быть выполнен для проверки действительности данных пользователя и/или других данных пользователя. Это может быть выполнено любым подходящим способом. Например, согласно одному варианту осуществления модуль провайдера может сохранять другие данные пользователя и/или данные пользователя и может быть выполнен для генерации соответствующей идентификационной метки данных пользователя и/или соответствующей идентификационной метки других данных пользователя. С целью проверки действительности данных пользователя, модуль провайдера может быть выполнен для сравнения идентификационной метки полученных от поискового модуля данных пользователя с соответствующей идентификационной меткой данных пользователя, сгенерированной посредством модуля провайдера. С целью проверки других данных пользователя, модуль провайдера может быть выполнен для сравнения идентификационной метки полученных от поискового модуля других данных пользователя с соответствующей идентификационной меткой других данных пользователя, сгенерированной посредством модуля провайдера. В результате сличения сравниваемых идентификационных меток модуль провайдера может поставить информацию о состоянии и/или связанные с конфигурированием данные (связанные с конфигурированием данные могут, например, быть ассоциированы с пользователем, с данными пользователя и/или с другими данными пользователя) в поисковый модуль. Однако следует понимать, что произвольный подходящий способ для проверки может также использоваться для проверки на то, что поставленная посредством поискового модуля идентификационная метка других данных пользователя соответствует другим данным пользователя, сохраненным в запоминающем устройстве модуля провайдера.
В то время как согласно одному варианту осуществления модуль провайдера может поставлять связанные с конфигурированием данные, согласно другим вариантам осуществления связанные с конфигурированием данные могут быть сохранены в различных компонентах системы, например в поисковом модуле, и могут быть отобраны после подтверждения успешной проверки других данных пользователя в модуле провайдера. Согласно другому варианту осуществления проверка в модуле провайдера исключена, и поисковый модуль в таком случае может быть выполнен для поставки связанных с конфигурированием данных после получения идентификатора провайдера из согласующего модуля.
Согласно одному варианту осуществления осуществление выборки связанных с конфигурированием данных из модуля провайдера включает в себя поставку идентификационной метки данных пользователя и, факультативно, идентификационной метки других данных пользователя в модуль провайдера, а также получение из модуля провайдера связанных с конфигурированием данных. Согласно одному варианту осуществления поисковый модуль выполнен для того, что он не поставляет идентификационную метку других данных пользователя в согласующий модуль. Например, согласно одному варианту осуществления другие данные пользователя или полученные из них данные поставляются только в модуль провайдера, который уже хранит в себе другие данные пользователя или полученные из них данные (например, идентификационную метку данных пользователя). Прежде всего, в случае, когда другие данные пользователя являются зашифрованными данными (например, паролем), безопасность сетевой системы улучшена за счет непоставки идентификационной метки других данных пользователя в согласующий модуль.
Согласно одному варианту осуществления модуль провайдера выполнен для осуществления выборки зарегистрированного имени пользователя на основе идентификационной метки данных пользователя (например, из базы данных модуля провайдера). Кроме того, в варианте осуществления, где другие данные пользователя являются паролем пользователя в модуле провайдера, модуль провайдера может быть выполнен для проверки идентификационной метки пароля для выбранного зарегистрированного имени. Согласно одному варианту осуществления модуль провайдера выполнен для поставки зарегистрированного имени, ассоциированного с данными пользователя и/или с другими данными пользователя, в поисковый модуль в ответ на получение из поискового модуля данных, которые основаны на связанных с пользователем данных и/или данных, которые основаны на других связанных с пользователем данных.
В то время как выше были описаны коммуникации между клиентским модулем, поисковым модулем и согласующим модулем с целью поставки связанных с конфигурированием данных для клиентского модуля, в последующем описана регистрация модуля провайдера в поисковом модуле и в согласующем модуле.
Согласно одному варианту осуществления второго аспекта, который отнесен к регистрации модуля провайдера в поисковом модуле и в согласующем модуле, модуль провайдера выполнен для поставки регистрационного запроса в поисковый модуль, причем регистрационный запрос содержит, по меньшей мере, часть идентификационных данных (например, идентификатор провайдера) и связанные с проверкой данные (например, идентификационную метку согласующего пароля), и причем связанные с проверкой данные основаны на проверочных данных (например, на согласующем пароле), и причем связанные с проверкой данные обеспечивают однозначную идентификацию проверочных данных, поисковый модуль, кроме того, выполнен для получения регистрационного запроса, и поисковый модуль, кроме того, выполнен для поставки, по меньшей мере, части идентификационных данных провайдера (например, идентификатора провайдера) и данных, которые основаны на связанных с проверкой данных (например, идентификационной метки связанных с проверкой данных, например идентификационной метки согласующего пароля) в согласующий модуль, например, в ответ на полученный регистрационный запрос.
Согласно одному варианту осуществления связанные с проверкой данные являются идентификационной меткой (например, соленой идентификационной меткой) проверочных данных. Проверочные данные могут, например, быть представлены согласующими зашифрованными данными, которые известны согласующему модулю и модулю провайдера, который стремится к регистрации в согласующем модуле. Согласно одному варианту осуществления проверочные данные (например, согласующие зашифрованные данные) подвергаются обмену между согласующим модулем и модулем провайдера посредством зашифрованной электронной почты или, в другом варианте осуществления, посредством ручного способа по телефону. Согласно одному варианту осуществления проверочные данные сгенерированы посредством согласующего модуля и поставлены в модуль провайдера.
Согласно одному варианту осуществления данные, которые основаны на связанных с проверкой данными, являются идентификационной меткой связанных с проверкой данных и связанные с проверкой данные обеспечивают однозначную идентификацию проверочных данных. Согласно другому варианту осуществления данные, которые основаны на связанных с проверкой данных, являются идентичными со связанными с проверкой данными. Другими словами, согласно одному варианту осуществления поисковый модуль выполнен для направления связанных с проверкой данных в согласующий модуль.
Согласно одному варианту осуществления регистрационный запрос содержит адрес провайдера, под которым можно контактировать с модулем провайдера. Адрес провайдера может быть представлен, например, универсальным указателем ресурса (URL) модуля провайдера. Согласно одному варианту осуществления поисковый модуль выполнен для сохранения, по меньшей мере, части идентификационных данных и ассоциированного адреса провайдера.
Согласно одному варианту осуществления поисковый модуль, кроме того, выполнен для получения регистрационного запроса. Кроме того, согласно одному варианту осуществления поисковый модуль выполнен для сохранения, по меньшей мере, части идентификационных данных провайдера и ассоциированного адреса провайдера в запоминающем устройстве поискового модуля. В таком случае, поисковый модуль может поставлять в клиентский модуль адрес провайдера в виде связанных с конфигурированием данных. В этом случае, коммуникация с модулем провайдера для выборки связанных с конфигурированием данных не является необходимой, однако может быть выполнена, например, с целью проверки данных пользователя и других данных пользователя. Вместо адреса провайдера или в дополнение к нему, другие связанные с конфигурированием данные могут содержаться в регистрационном запросе и могут быть сохранены посредством поискового модуля или быть поставлены в согласующий модуль.
Согласно одному варианту осуществления поисковый модуль может быть выполнен для поставки пароля в согласующий модуль, причем пароль является необходимым для согласующего модуля для принятия, по меньшей мере, части идентификационных данных провайдера и идентификационной метки проверочных данных, поставляемой посредством поискового модуля.
Согласно одному варианту осуществления проверочные данные согласованы между модулем провайдера и согласующим модулем перед регистрацией модуля провайдера в поисковом модуле. Таким образом, в варианте осуществления согласующий модуль может вычислять идентификационную метку проверочных данных и сравнивать результат с идентификационной меткой проверочных данных, полученной от поискового модуля. Если, например, соленая идентификационная метка поставлена посредством поискового модуля, также и криптографическая соль поставлена посредством поискового модуля таким образом, что согласующий модуль способен вычислять идентификационную метку комбинации криптографической соли с проверочными данными с целью проверки проверочных данных.
Согласно одному варианту осуществления согласующий модуль выполнен для проверки проверочных данных и для поставки элемента информации о состоянии в поисковый модуль, причем элемент информации о состоянии указывает на успешность или неуспешность проверки проверочных данных.
Если, по меньшей мере, часть идентификационных данных провайдера является полной, то есть, если идентификационные данные провайдера обеспечивают однозначную идентификацию модуля провайдера, согласующий модуль может быть выполнен, в таком случае, для поставки элемента информации о состоянии в поисковый модуль, причем элемент информации о состоянии указывает на успешность или неуспешность проверки проверочных данных.
Согласно одному варианту осуществления только часть идентификационных данных провайдера поставляется посредством модуля провайдера в поисковый модуль, и, следовательно, только эта часть идентификационных данных провайдера поставляется посредством поискового модуля в согласующий модуль. Таким образом, поисковый модуль не должен получать полные идентификационные данные провайдера для регистрации модуля провайдера в согласующем модуле. Это может улучшить безопасность сетевой системы в целом. В варианте осуществления предложенного в данном документе предмета, где только часть идентификационных данных провайдера поставляется в согласующий модуль посредством поискового модуля, согласующий модуль может быть выполнен для восполнения идентификационных данных провайдера и для поставки восполненных идентификационных данных провайдера или недостающей части идентификационных данных провайдера в поисковый модуль, если проверка проверочных данных является успешной.
Согласно одному варианту осуществления согласующий модуль выполнен для поставки элемента информации об ошибке в поисковый модуль в случае, когда ошибка происходит в процессе поиска идентификационных данных провайдера и/или проверки проверочных данных. Кроме того, согласно одному варианту осуществления согласующий модуль выполнен для поставки информационного элемента в поисковый модуль в случае, когда проверка проверочных данных потерпела неудачу, причем информационный элемент указывает поисковому модулю, что идентификационная метка данных о проверке была недействительной.
Согласно одному варианту осуществления поисковый модуль выполнен для сохранения в запоминающем устройстве поискового модуля идентификационных данных (например, идентификационных данных провайдера) и ассоциированных связанных с конфигурированием данных (например, ассоциированного URL провайдера).
Согласно одному варианту осуществления третьего аспекта предоставлен клиентский модуль сетевой системы, причем клиентский модуль выполнен для инициирования конфигурирования поставляемого пользователю обслуживания посредством поставки связанных с пользователем данных в поисковый модуль, причем связанные с пользователем данные ассоциированы с пользователем, связанные с пользователем данные основаны на данных пользователя, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя.
Согласно вариантам осуществления третьего аспекта клиентский модуль выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого и второго аспекта. Кроме того, согласно одному варианту осуществления клиентский модуль согласно третьему аспекту выполнен, как описано, с учетом одного или нескольких из вариантов осуществления первого и второго аспекта.
Согласно одному варианту осуществления четвертого аспекта предоставлен поисковый модуль сетевой системы, причем поисковый модуль выполнен для получения связанных с пользователем данных из клиентского модуля, причем связанные с пользователем данные основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя, причем поисковый модуль, выполнен для осуществления выборки идентификационных данных (например, идентификатора провайдера) из согласующего модуля с использованием связанных с пользователем данных (например, идентификационной метки адреса электронной почты пользователя), которые идентификационные данные ассоциированы с данными пользователя, и причем поисковый модуль выполнен для осуществления выборки связанных с конфигурированием данных для поставляемого пользователю обслуживания, и причем поисковый модуль выполнен для осуществления выборки связанных с конфигурированием данных с использованием идентификационных данных.
Согласно вариантам осуществления четвертого аспекта поисковый модуль выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого и второго аспекта. Кроме того, согласно одному варианту осуществления поисковый модуль согласно четвертому аспекту выполнен, как описано, с учетом одного или нескольких из вариантов осуществления первого и второго аспекта. Например, согласно одному варианту осуществления поисковый модуль выполнен для получения идентификационной метки данных пользователя, причем данные пользователя ассоциированы с пользователем, а идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, причем поисковый модуль, кроме того, выполнен для осуществления выборки связанных с конфигурированием данных с использованием идентификационной метки данных пользователя. Например, согласно одному варианту осуществления поисковый модуль выполнен для осуществления выборки связанных с конфигурированием данных из модуля провайдера с использованием идентификационной метки данных пользователя.
Согласно одному варианту осуществления пятого аспекта предложенного в данном документе предмета предоставлен согласующий модуль сетевой системы, причем согласующий модуль содержит запоминающее устройство и который согласующий модуль выполнен для получения связанных с пользователем данных из поискового модуля сетевой системы, причем связанные с пользователем данные основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя, причем согласующий модуль, выполнен для осуществления выборки из запоминающего устройства идентификационных данных, ассоциированных с данными пользователя, и причем согласующий модуль, кроме того, выполнен для поставки идентификационных данных в поисковый модуль.
Согласно вариантам осуществления пятого аспекта согласующий модуль выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого и второго аспекта. Кроме того, согласно одному варианту осуществления согласующий модуль согласно пятому аспекту выполнен, как описано, с учетом одного или нескольких из вариантов осуществления первого и второго аспекта. Например, согласно одному варианту осуществления пятого аспекта предоставлен согласующий модуль сетевой системы, причем согласующий модуль выполнен для получения идентификационной метки данных пользователя из поискового модуля, причем данные пользователя ассоциированы с пользователем, а идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, причем согласующий модуль, кроме того, выполнен для осуществления выборки идентификационных данных провайдера, ассоциированных с полученной идентификационной меткой данных пользователя, и причем идентификационные данные провайдера идентифицируют модуль провайдера. Согласно одному варианту осуществления модуль провайдера выполнен для поставки специфического для пользователя обслуживания пользователю.
Согласно одному варианту осуществления шестого аспекта предложенного в данном документе предмета предоставлен модуль провайдера сетевой системы, причем модуль провайдера выполнен для получения связанных с пользователем данных из поискового модуля сетевой системы, причем связанные с пользователем данные основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя, причем модуль провайдера выполнен для проверки действительности данных пользователя с использованием полученных связанных с пользователем данных, и причем модуль провайдера выполнен для проверки действительности данных пользователя с использованием полученных связанных с пользователем данных и/или для осуществления выборки связанных с конфигурированием данных для поставляемого пользователю обслуживания.
Согласно одному варианту осуществления модуль провайдера выполнен для поставки информации о состоянии в поисковый модуль, которая информация о состоянии является показательной в отношении действительности данных пользователя, соответствующих идентификационной метке.
Согласно другому варианту осуществления модуль провайдера выполнен для поставки связанных с конфигурированием данных в поисковый модуль.
Согласно вариантам осуществления шестого аспекта модуль провайдера выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого и второго аспекта. Кроме того, согласно одному варианту осуществления модуль провайдера согласно шестому аспекту выполнен, как описано, с учетом одного или нескольких из вариантов осуществления первого и второго аспекта. Например, согласно одному варианту осуществления модуль провайдера выполнен для получения идентификационной метки данных пользователя, причем данные пользователя ассоциированы с пользователем, а идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, причем модуль провайдера, кроме того, выполнен для осуществления выборки связанных с конфигурированием данных с использованием идентификационной метки данных пользователя, которые связанные с конфигурированием данные ассоциированы с данными пользователя.
Согласно седьмому аспекту предложенного в данном документе предмета, предоставлен способ использования клиентского модуля сетевой системы, причем способ включает в себя: инициирование конфигурации поставляемого пользователю обслуживания посредством поставки связанных с пользователем данных в поисковый модуль, причем связанные с пользователем данные ассоциированы с пользователем, связанные с пользователем данные основаны на данных пользователя, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя.
Согласно вариантам осуществления седьмого аспекта способ выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого, второго, третьего и четвертого аспекта.
Например, согласно вариантам осуществления седьмого аспекта способ включает в себя поставку идентификационной метки данных пользователя в поисковый модуль, причем данные пользователя ассоциированы с пользователем, а идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, а также получение связанных с конфигурированием данных для поставляемого пользователю обслуживания из поискового модуля.
Согласно одному варианту осуществления восьмого аспекта предложенного в данном документе предмета предоставлен способ использования поискового модуля сетевой системы, причем способ включает в себя: получение связанных с пользователем данных из клиентского модуля, причем связанные с пользователем данные основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя, осуществление выборки идентификационных данных (идентификатора провайдера) из согласующего модуля с использованием связанных с пользователем данных (идентификационной метки адреса электронной почты), причем идентификационные данные ассоциированы с данными пользователя, осуществление выборки связанных с конфигурированием данных для поставляемого пользователю обслуживания, осуществление выборки связанных с конфигурированием данных, выполняемым с использованием идентификационных данных.
Согласно вариантам осуществления восьмого аспекта способ выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого и второго аспекта предложенного в данном документе предмета.
Например, согласно вариантам осуществления восьмого аспекта способ включает в себя: получение идентификационной метки данных пользователя из клиентского модуля, причем данные пользователя ассоциированы с пользователем, а идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, осуществление выборки идентификационных данных провайдера из согласующего модуля с использованием идентификационной метки данных пользователя, причем идентификационные данные ассоциированы с данными пользователя, осуществление выборки связанных с конфигурированием данных для поставляемого пользователю обслуживания, причем осуществление выборки связанных с конфигурированием данных выполнено с использованием идентификационных данных провайдера.
Согласно одному варианту осуществления девятого аспекта предложенного в данном документе предмета, предоставлен способ использования согласующего модуля сетевой системы, причем способ включает в себя получение связанных с пользователем данных из поискового модуля сетевой системы, причем связанные с пользователем данные основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя, осуществление выборки ассоциированных с данными пользователя идентификационных данных, поставку идентификационных данных в поисковый модуль.
Согласно вариантам осуществления девятого аспекта способ выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого и второго аспекта предложенного в данном документе предмета.
Например, согласно вариантам осуществления девятого аспекта способ включает в себя получение идентификационной метки данных пользователя из поискового модуля, причем данные пользователя ассоциированы с пользователем, а идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, осуществление выборки идентификационных данных провайдера, ассоциированных с идентификационной меткой данных пользователя, причем идентификационные данные провайдера идентифицируют модуль провайдера, и поставку идентификационных данных провайдера в поисковый модуль.
Согласно одному варианту осуществления десятого аспекта предложенного в данном документе предмета предоставлен способ использования модуля провайдера сетевой системы, причем способ включает в себя: получение связанных с пользователем данных из поискового модуля сетевой системы, причем связанные с пользователем данные основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя, подтверждение действительности данных пользователя с использованием полученных связанных с пользователем данных и/или осуществление выборки связанных с конфигурированием данных для поставляемого пользователю обслуживания, и, факультативно, поставку информации о состоянии и/или связанных с конфигурированием данных в поисковый модуль, причем информация о состоянии является показательной в отношении действительности данных пользователя, соответствующих идентификационной метке.
Согласно вариантам осуществления десятого аспекта способ выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления первого и второго аспекта предложенного в данном документе предмета.
Например, согласно вариантам осуществления десятого аспекта способ включает в себя получение идентификационной метки данных пользователя из поискового модуля, причем данные пользователя ассоциированы с пользователем, а полученная идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, проверку действительности полученной идентификационной метки данных пользователя, и поставку информации о состоянии в поисковый модуль, если информационный элемент соответствует действительным данным пользователя, причем информация о состоянии указывает на соответствие информационного элемента действительным данным пользователя.
Согласно одному варианту осуществления одиннадцатого аспекта предложенного в данном документе предмета, предоставлен способ использования сетевой системы, которая сетевая система содержит поисковый модуль, согласующий модуль и клиентский модуль, причем способ включает в себя: поставку связанных с пользователем данных из клиентского модуля в поисковый модуль, причем связанные с пользователем данные основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные обеспечивают однозначную идентификацию данных пользователя, задействование поискового модуля для осуществления выборки идентификационных данных (например, идентификатора провайдера) из согласующего модуля с использованием связанных с пользователем данных (например, идентификационной метки адреса электронной почты пользователя), которые идентификационные данные ассоциированы с данными пользователя, задействование согласующего модуля для осуществления выборки идентификационных данных, ассоциированных с данными пользователя, поставку идентификационных данных из согласующего модуля в поисковый модуль, задействование поискового модуля для осуществления выборки связанных с конфигурированием данных для поставляемого пользователю обслуживания, задействование поискового модуля для осуществления выборки связанных с конфигурированием данных с использованием идентификационных данных.
Согласно вариантам осуществления одиннадцатого аспекта способ выполнен для предоставления функций одного или нескольких из вышеупомянутых вариантов осуществления и/или для предоставления функций по потребности посредством одного или нескольких из вышеупомянутых вариантов осуществления, прежде всего, вариантов осуществления от первого до десятого аспекта предложенного в данном документе предмета.
Например, согласно вариантам осуществления одиннадцатого аспекта способ включает в себя поставку идентификационной метки данных пользователя из клиентского модуля в поисковый модуль, причем данные пользователя ассоциированы с пользователем и идентификационная метка данных пользователя обеспечивает однозначную идентификацию данных пользователя, задействование согласующего модуля для осуществления выборки ассоциированных с идентификационной меткой данных пользователя идентификационных данных провайдера, и задействование поискового модуля для осуществления выборки ассоциированных с идентификационными данными провайдера связанных с конфигурированием данных с использованием идентификационной метки данных пользователя.
Согласно одному варианту осуществления двенадцатого аспекта предложенного в данном документе предмета предоставлена компьютерная программа, которая компьютерная программа выполнена для управления (например, путем реализации) способом согласно одному или нескольким вариантам осуществления седьмого, девятого, десятого и/или одиннадцатого аспекта, при выполнении компьютерной программы посредством процессорного устройства. Прежде всего, для каждого описанного здесь способа может быть предоставлена соответствующая компьютерная программа, которая выполнена, при ее исполнении посредством процессорного устройства, для управления соответствующим способом.
Как принято в данном документе, отсылка на компьютерную программу предполагается эквивалентной отсылке на элемент программы и/или на машиночитаемый носитель, содержащий инструкции для управления компьютерной системой с целью осуществления и/или координации выполнения вышеописанного способа.
Компьютерная программа может быть реализована в виде машиночитаемой системы команд при помощи любого подходящего языка программирования, такого как, например, Java, C++, и может быть сохранена на машиночитаемом носителе (съемном диске, в энергозависимом или в энергонезависимом запоминающем устройстве, во встроенном запоминающем устройстве/процессоре и т.д.). Система команд может быть использована для программирования компьютера или любого другого программируемого устройства с целью выполнения намеченных функций. Компьютерная программа может быть доступной из сети, такой как Всемирная паутина, из которой она может быть загружена.
Предложенный в данном документе предмет может быть осуществлен посредством компьютерной программы или, соответственно, программного обеспечения. Однако предложенный в данном документе предмет может также быть осуществлен посредством одной или нескольких специальных электронных схем или, соответственно, аппаратных средств. Кроме того, предложенный в данном документе предмет может также быть осуществлен в гибридной форме, то есть в виде комбинации модулей аппаратных средств и программных модулей.
Например, каждый описанный в данном документе модуль может быть реализован в виде программного обеспечения и/или аппаратных средств, например посредством соответствующего устройства или посредством выполняемых компьютером операций. Устройство может быть представлено компьютером, например сервером, имеющим выполняемое на нем программное обеспечение, которое предоставляет описанное выполнение функций модуля. Обычно устройство может быть представлено, например, процессорным устройством, имеющим по меньшей мере один процессор для выполнения инструкций с целью предоставления функций, как они описаны относительно вариантов осуществления соответствующего компонента системы.
Согласно одному варианту осуществления функции описанных в данном документе модулей, например клиентского модуля, поискового модуля, согласующего модуля и модуля провайдера, могут быть осуществлены посредством соответствующего компонента программного обеспечения, например РНР-компонента.
Выше были описаны и в последующем будут описаны примерные варианты осуществления предмета, описанного в данном документе со ссылками на сетевую систему, отдельные ее модули и соответствующие способы применения. Необходимо отметить, что, безусловно, возможна также любая комбинация признаков, относящихся к различным аспектам предложенного в данном документе предмета. Прежде всего, некоторые признаки были или будут описаны со ссылками на варианты осуществления устройства, тогда как другие признаки были или будут описаны со ссылками на варианты осуществления способа. Однако, специалистам в данной области техники из вышеприведенного и последующего описания, если иное не указано, очевидно, что в дополнение к произвольной комбинации признаков, принадлежащих одному аспекту, настоящей заявкой также предложена к раскрытию и произвольная комбинация признаков, относящихся к различных аспектам или вариантам осуществления, например, также и комбинация признаков вариантов осуществления устройства и признаков вариантов осуществления способа.
Согласно соответствующим примерным вариантам осуществления данные пользователя являются адресом электронной почты пользователя, другими данными пользователя является идентификационная метка соленой идентификационной метки пользовательского пароля, причем соленая идентификационная метка пользовательского пароля является пользовательским паролем, объединенным с криптографической солью, а клиентский модуль выполнен для поставки криптографической соли в поисковый модуль, связанные с конфигурированием данные содержат универсальный указатель ресурса (URL) модуля провайдера и зарегистрированное имя пользователя в модуле провайдера, связанные с пользователем данные, поставленные из клиентского модуля в поисковый модуль, переданы в поисковый модуль в поисковом запросе, причем, факультативно, эти связанные с пользователем данные являются идентификационной меткой данных пользователя, а поисковый запрос, факультативно, кроме того, содержит соленую идентификационную метку идентификационной метки пользовательского пароля, требуемого от пользователя для начала сеанса обслуживания на модуле провайдера, а также криптографическую соль, используемую для генерации соленой идентификационной метки, связанные с пользователем данные, поставленные из поискового модуля в согласующий модуль, переданы в согласующий модуль в цикле передачи запроса, причем, факультативно, эти связанные с пользователем данные являются идентификационной меткой данных пользователя, а цикл передачи запроса, факультативно, кроме того, содержит пароль для начала сеанса на согласующем модуле, связанные с пользователем данные, поставленные в модуль провайдера, переданы в модуль провайдера в запросе провайдера, причем, факультативно, эти связанные с пользователем данные, факультативно, содержат идентификационную метку данных пользователя, а запрос провайдера, факультативно, содержит соленую идентификационную метку идентификационной метки пользовательского пароля, требуемого от пользователя для начала сеанса обслуживания на модуле провайдера, и криптографическую соль, используемую для генерации соленой идентификационной метки.
Ответы на запросы (поисковый запрос, цикл передачи запроса, запрос провайдера) могут быть поставлены посредством отвечающего модуля в соответствующем цикле передачи ответа.
Согласно одному варианту осуществления модули, которые сообщаются друг с другом согласно вариантам осуществления предложенного в данном документе предмета, коммуникативно соединены посредством произвольного подходящего соединения/протокола, например, посредством защищенного соединения, по которому элемент передается в зашифрованном виде, такого как соединение виртуальной частной сети (соединение VPN) или соединение по безопасному протоколу (соединение SSL). Необходимо принять во внимание, что обычно поставка элемента (например, идентификационной метки данных пользователя) по защищенному соединению из передающего модуля в приемный модуль подразумеваемым образом раскрывает шифровку элемента, передачу зашифрованного элемента из передающего модуля в приемный модуль и расшифровку зашифрованного элемента в приемном модуле для обеспечения доступности элемента в приемном модуле. Таким образом, передающий модуль и приемный модуль могут быть представлены любым подходящим модулем, как описано в данном документе. Следует заметить, что любая коммуникация между модулями, как раскрыто в данном документе, может быть представлена коммуникацией по защищенному соединению между модулями.
Необходимо принять во внимание, что раскрытие коммуникации между различными модулями подразумеваемым образом раскрывает передачу, прием и выборку соответствующих циклов передачи посредством вовлеченных модулей, и наоборот. Например, раскрытие получения некоторых входных данных и поставки в ответ на это некоторых возвратных данных подразумеваемым образом раскрывает выборку возвратных данных, посредством поставки входных данных, передачу входных данных, получение возвратных данных и т.д. Кроме того, каждый цикл передачи из первого модуля в другой, второй модуль может содержать операционный идентификатор, который задает выполняемую посредством второго модуля операцию. Кроме того, раскрытие поставки возвратных данных, например информации о состоянии, идентичности, связанных с конфигурированием данных и т.д., из первого модуля во второй модуль раскрывает, как считается согласно одному варианту осуществления, что получающий возвратные данные второй модуль выполнен для поставки соответствующего запроса в первый модуль и, что первый модуль выполнен для получения запроса и для поставки, в ответ на него, возвратных данных.
Согласно одному варианту осуществления поставка возвратных данных подразумевает поставку возвратных данных с заданной задержкой. Таким образом, атака прямым подбором и синхронная атака на соответствующий модуль, который передает возвратные данные, могут быть предотвращены и, таким образом, безопасность сетевой системы может быть повышена.
Обычно в данном документе термин «поставка данных» охватывает поставку данных в незашифрованном виде или поставку данных в зашифрованном виде. Так или иначе, термин «поставка данных» относится обычно к поставке данных в таком представлении, которое делает возможным восстановление данных в их оригинальном виде из представления.
Кроме того, если согласно одному варианту осуществления первый компонент системы (например, идентификационные данные) задан в данном документе как ассоциированный со вторым компонентом системы (например, данными пользователя), термин «ассоциированный с» охватывает также ассоциацию первого компонента системы и второго компонента системы в том смысле, что связанные с первым компонентом системы данные (например, идентификационная метка) могут быть получены из данных, назначенных ко второму компоненту системы, например, посредством базы данных.
Всякий раз, когда действие или способ выполняются посредством раскрытого в данном документе модуля, нужно подразумевать, что согласно одному варианту осуществления модуль выполнен для выполнения соответствующего действия или способа.
Согласующий модуль и поисковый модуль отличаются друг от друга. Однако, несмотря на то что они являются различными модулями, согласно одному варианту осуществления согласующий модуль и поисковый модуль реализованы в единственном устройстве. Для согласующего модуля и поискового модуля могут быть предоставлены два различных компонента программного обеспечения, выполняемых на единственном процессорном устройстве. Кроме того, в другом варианте осуществления один модуль из числа согласующего модуля и поискового модуля может быть представлен компонентом программного обеспечения, выполняемым на виртуальной машине, которая виртуальная машина реализована на процессорном устройстве. Другой из числа согласующего модуля и поискового модуля может быть представлен компонентом программного обеспечения, выполняемым непосредственно на процессорном устройстве или на другой, отличной виртуальной машине.
Согласно другому варианту осуществления согласующий модуль и поисковый модуль могут быть пространственно отдалены друг от друга.
Примерный вариант осуществления предложенного в данном документе предмета может содержать следующие признаки (например, в виде примерных способов (А), (В)):
СПП-процесс (выполняемый каждый раз, когда связанные с конфигурированием данные затребованы со стороны клиентского модуля):
1. Клиентский модуль генерирует первую идентификационную метку данных пользователя и первую идентификационную метку других данных пользователя, и передает их в СПП.
2. СПП использует первую идентификационную метку данных пользователя для получения числового идентификатора для провайдера пользователя из согласующего модуля.
3. СПП использует его собственную базу данных для определения URL назначенного провайдера.
4. СПП контактирует с провайдером (с использованием URL) и посылает первую идентификационную метку данных пользователя и первую идентификационную метку других данных пользователя, а также используемую соль.
5. Провайдер проверяет данные (пользователь с такой идентификационной меткой адреса электронной почты существует, а пользовательская идентификационная метка пароля с данной солью согласуется с заданной меткой). Результатом является либо «ОК» с предоставлением URL для контакта с провайдером, либо «INVALID». Результат может быть отличным для различных подпровайдеров. Провайдер задает правильный URL (например, https://portal.regify.com) из его пользовательской базы данных.
6. СПП возвращает URL в клиентский модуль для использования.
7. Клиентский модуль контактирует с провайдером по данному URL для получения требуемой информации (например, конфигурации клиента).
Наконец, СПП все еще не имеет пользовательского пароля или адреса электронной почты. Согласующий модуль не имеет адреса электронной почты пользователя.
Процесс регистрации СПП (выполняемый, по меньшей мере, однократно для каждого нового провайдера):
СПП изучает ассоциацию между идентификатором провайдера и правильным URL посредством регистрации. Для осуществления этого процесса:
1. Модуль провайдера запрашивает СПП совместно с его URL, идентификатором, идентификационной меткой его согласующего пароля (clearingPassword) и используемой соленой идентификационной меткой (=хеш (соль|согласующий пароль)).
2. СПП проверяет эту информацию посредством согласующего модуля, путем передачи идентификатора провайдера и идентификационной метки в согласующий модуль.
3. При успешном прохождении проверки СПП обновляет свою базу данных. Теперь он имеет идентификатор провайдера и его ассоциированный URL (необходимый для вышеупомянутых этапов 3 и 4).
Наконец, СПП не имеет согласующего пароля провайдер, но теперь имеет ассоциацию с идентификатором провайдера и URL, подтвержденную посредством согласующего модуля.
Заданные выше аспекты и варианты осуществления, а также другие аспекты и варианты осуществления предложенного в данном документе предмета очевидны из вариантов, которые будут описаны в дальнейшем и объяснены со ссылками на чертежи, но не ограничивают при этом изобретение.
Краткое описание чертежей
Фиг. 1 показывает сетевую систему согласно вариантам осуществления предложенного в данном документе предмета.
Фиг. 2 показывает протокол поиска согласно вариантам осуществления предложенного в данном документе предмета.
Фиг. 3 схематично показывает функционирование сетевой системы согласно вариантам осуществления предложенного в данном документе предмета.
Иллюстрация на чертежах является схематичной. Следует заметить, что на различных чертежах подобные или идентичные элементы снабжены одинаковыми ссылочными обозначениями или ссылочными обозначениями, которые отличаются от соответствующих ссылочных обозначений только дополнительным символом.
Фиг. 1 показывает сетевую систему 100 согласно вариантам осуществления предложенного в данном документе предмета.
Согласно одному варианту осуществления сетевая система 100 содержит клиентский модуль 102, такой как пользовательское устройство (ПУ). Кроме того, сетевая система 100 содержит поисковый модуль 104, например поисковый сервер (который может также быть обозначен как сервер поиска провайдера, СПП). Клиентский модуль 102 выполнен для поставки связанных с пользователем данных 106 в виде идентификационной метки данных пользователя в поисковый модуль 104. Данные пользователя ассоциированы с пользователем, например пользователем, который управляет клиентским модулем, а идентификационная метка 106 обеспечивает однозначную идентификацию данных пользователя. Например, идентификационная метка может быть представлена хеш-кодом (например, криптографическим хеш-кодом) данных пользователя, полученным посредством соответствующей хеш-функции. Хеш-код может быть сгенерирован из данных пользователя посредством любой подходящей хеш-функции, некоторые из которых известны из уровня техники (например, MD5, защищенные алгоритмы хэширования, такие как SHA-x, см. например, публикацию федерального стандарта обработки информации (FIPS PUB) 180-2, доступную на http://csrc.nist.gov/publications/, однако также могут быть использованы и другие функции для генерирования идентификационной метки согласно вариантам осуществления предложенного в данном документе предмета. В предпочтительном варианте осуществления идентификационная метка сгенерирована посредством криптографической хеш-функции.
Согласно другому варианту осуществления клиентский модуль 102 выполнен для поставки других связанных с пользователем данных 108 в виде идентификационной метки других данных пользователя в поисковый модуль 104, причем идентификационная метка 108 других данных пользователя обеспечивает однозначную идентификацию других данных пользователя.
Согласно одному варианту осуществления данные пользователя являются адресом электронной почты пользователя из клиентского модуля 102, а другие данные пользователя являются паролем пользователя. Таким образом, когда в последующем изложении сделана отсылка на адрес электронной почты и пароль пользователя, нужно подразумевать, что любой из приведенных ниже вариантов осуществления обычно может быть осуществлен с использованием любых данных пользователя и других данных пользователя. Согласно одному варианту осуществления по меньшей мере одни данные из числа данных пользователя и других данных пользователя однозначно идентифицируют пользователя.
Согласно одному варианту осуществления клиентский модуль 102 содержит вводное устройство 103, которым пользователь может управлять для ввода данных пользователя и других данных пользователя в клиентский модуль 102. Согласно одному варианту осуществления клиентский модуль 102 выполнен для генерации идентификационной метки 106 из данных пользователя с использованием защищенного алгоритма хэширования. Согласно одному варианту осуществления клиентский модуль 102 выполнен для генерации идентификационной метки 108 из других данных пользователя с использованием защищенного алгоритма хэширования.
Согласно одному варианту осуществления идентификационная метка 108 пароля является соленой идентификационной меткой. Как известно из уровня техники, это означает, что например, если хеш-функция используется для генерации идентификационной метки, на вход хеш-функции поставляется не один только пароль, но в качестве входных величин для хеш-функции используются пароль совместно с криптографической солью. Другими словами, соленая идентификационная метка пароля является идентификационной меткой комбинации пароля и криптографической соли. Согласно другому варианту осуществления соленая идентификационная метка пароля является идентификационной меткой комбинации криптографической соли и идентификационной метки пароля. Кроме того, следует понимать, что этапы генерации идентификационной метки, соления идентификационной метки и генерации соленой идентификационной метки комбинации соли и предшествующей идентификационной метки могут быть повторены два или большее число раз, как известно из уровня техники, с целью повышения безопасности за счет достижения неосуществимости для третьего лица попытки генерации идентификационной метки пароля посредством вычисления идентификационных меток для нескольких предполагаемых паролей.
Клиентский модуль 102 выполнен для поставки идентификационной метки 106 из данных пользователя, равно как идентификационной метки 108 из других данных пользователя в поисковый модуль 104. Согласно одному варианту осуществления идентификационная метка 106 и идентификационная метка 108 поставляются в клиентский модуль в общем регистрационном запросе 105.
Согласно одному варианту осуществления сетевая система 100 содержит согласующий модуль 110, например согласующий сервер (СС). Согласно одному варианту осуществления поисковый модуль 104 выполнен для запрашивания идентификационных данных, например информации о провайдере для провайдера пользователя из согласующего модуля 110. Например, согласно одному варианту осуществления поисковый модуль 104 выполнен для поставки другой идентификационной метки 112 (например, второй идентификационной метки) данных пользователя в согласующий модуль, причем другая идентификационная метка 112 данных пользователя обеспечивает однозначную идентификацию данных пользователя. Согласно одному варианту осуществления другая идентификационная метка 112 данных пользователя идентична идентификационной метке 106 данных пользователя. Другими словами, в этом варианте осуществления идентификационная метка данных пользователя, которую поисковый модуль получает из клиентского модуля 102, направлена посредством поискового модуля 104 в согласующий модуль 110 в качестве другой идентификационной метки 112 данных пользователя. Другая идентификационная метка 112 может быть поставлена в согласующий модуль 110 в цикле 136 передачи запроса, который запрашивает идентификационные данные, ассоциированные с другой идентификационной меткой 112. В ответ на получение другой идентификационной метки 112 данных пользователя согласующий модуль 110 поставляет в поисковый модуль идентификационные данные 114, например, в ответном цикле 138 передачи. Согласно одному варианту осуществления согласующий модуль 110 осуществляет выборку ассоциированных с данными пользователя идентификационных данных 114 из запоминающего устройства 111 согласующего модуля 110. Согласно одному варианту осуществления запоминающее устройство 111 сохраняет идентификатор данных пользователя, например, идентификационную метку 106 и ассоциированные идентификационные данные 114 для нескольких пользователей. Эти данные могут быть сохранены в запоминающем устройстве в процессе регистрации модуля провайдера, причем модуль провайдера поставляет данные, которые подлежат сохранению в запоминающем устройстве 111.
Согласно одному варианту осуществления идентификационные данные 114 однозначно идентифицируют модуль провайдера, ассоциированный с данными пользователя (например, модуль провайдера 118, показанный на фиг. 1). Например, согласно одному варианту осуществления идентификационные данные 114 идентифицируют модуль провайдера, на котором размещен почтовый ящик пользователя, который ассоциирован с адресом электронной почты, который образует данные пользователя в варианте осуществления.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для осуществления выборки связанных с конфигурированием данных 115, ассоциированных с информацией 114 по идентификации провайдера с использованием идентификационных данных 114. Согласно одному варианту осуществления поисковый модуль 104 осуществляет выборку адреса провайдера, ассоциированного с информацией по идентификации провайдера, например, из запоминающего устройства 113 поискового модуля 104. Адрес провайдера может быть представлен универсальным указателем ресурса (URL), под которым можно получить доступ к соответствующему модулю провайдера посредством пользовательского устройства 102. Согласно одному варианту осуществления поисковый модуль хранит в запоминающем устройстве 113 информацию по идентификации провайдера и соответствующий адрес провайдера, например URL провайдера для нескольких провайдеров. Согласно одному варианту осуществления поисковый модуль 104 выполнен для осуществления выборки связанных с конфигурированием данных 115 (например, зарегистрированного имени и/или сетевого адреса подпровайдера, с которым можно непосредственно контактировать посредством клиентского модуля 102 с использованием идентификационных данных 114. Согласно одному варианту осуществления поисковый модуль 104 получает связанные с конфигурированием данные 115 из модуля провайдера, как показано на фиг.1, или согласно другому варианту осуществления (не показанному на фиге. 1) из согласующего модуля 110, например, совместно с информацией 114 по идентификации провайдера.
Согласно одному варианту осуществления цикл передачи запроса, переданный из передающего модуля в приемный модуль, считается циклом передачи, который запрашивает у приемного модуля выполнение некоторой операции. В ответ на цикл передачи запроса приемный модуль может возвратить цикл передачи ответа, указывающий на результат выполненной операции.
Согласно одному варианту осуществления в случае соответствия другой идентификационной метки данных пользователя и другой идентификационной метки других данных пользователя действительным данным пользователя и/или действительным другим данным пользователя, первый модуль 118 провайдера поставляет информацию 123 о состоянии в поисковый модуль. Согласно одному варианту осуществления поисковый модуль 104 выполнен для поставки связанных с конфигурированием данных 115 в клиентский модуль 102, если информация 123 о состоянии из первого модуля провайдера указывает на действительность данных пользователя и других данных пользователя из соответствующих идентификационных меток, поставленных посредством клиентского модуля 102. Согласно одному варианту осуществления первый модуль провайдера 118 далее поставляет связанные с конфигурированием данные 115 в поисковый модуль 104. Информация 123 о состоянии и связанные с конфигурированием данные 115 могут быть поставлены в поисковый модуль 104 в цикле 188 передачи ответа. Связанные с конфигурированием данные 115 могут быть поставлены в клиентский модуль 104 в соответствующем цикле 116 передачи ответа.
Тем самым связанные с конфигурированием данные 115 (которые могут содержать, например, URL провайдера, URL подпровайдера, зарегистрированное имя пользователя и т.д.) могут быть использованы посредством клиентского модуля 102 совместно с известными регистрационными данными пользователя, например паролем пользователя для регистрации у соответствующего провайдера, например, первого провайдера 118, показанного на фиг. 1 (или его подпровайдера, если такой подпровайдер задан в связанных с конфигурированием данных 115). Доступ поискового модуля 102 к первому провайдеру 118 обозначен на фиг. 1 как 120.
Необходимо отметить, что согласно одному варианту осуществления сетевая система 100 содержит несколько модулей провайдера, в том числе, первый модуль 118 провайдера и другие модули провайдера, два из которых обозначены как 118а, 118b. Кроме того, согласно одному варианту осуществления в сетевой системе 100 могут быть предусмотрены два или более поисковых модулей. Кроме того, согласно одному варианту осуществления в сетевой системе 100 могут быть предусмотрены два или более согласующих модуля. Необходимо принять во внимание, что поисковый модуль 104 контактирует с соответствующим модулем провайдера 118, 118а, 118b в зависимости от идентификационных данных 114 провайдера, полученных из согласующего модуля 110. Каждый модуль провайдера 118, 118а, 118b может быть представлен, например, сервером P1, Р2, Р3 провайдера. Согласно одному варианту осуществления поисковый модуль регистрирует себя во всех известных модулях 118, 118а, 118b провайдера. Модули провайдера могут быть доступными через предопределенные URL, например URL на pls1.regify.com, pls2.regify.com и pls3.regify.com. Однако в других вариантах осуществления регистрация поискового модуля может быть выполнена любым другим подходящим способом.
Фиг. 2 показывает протокол поиска согласно вариантам осуществления предложенного в данном документе предмета.
Согласно одному варианту осуществления протокол поиска на фиг. 2 реализован в сетевой системе, выполненной согласно вариантам осуществления предложенного в данном документе предмета, например, в сетевой системе, как она описана на основе фиг. 1.
Примерный вариант использования сетевой системы, описанной в данном документе, и прежде всего, как описано на основе фиг. 2, должен предоставлять пользователю клиентское программное обеспечение, которое должно поддерживать связь с почтовым модулем провайдера (модулем 118 провайдера) пользователя. Варианты осуществления предложенного в данном документе предмета делают возможным, в таком случае, легкую загрузку неконфигурированного клиентского программного обеспечения на клиентский модуль 102, в то время как пользователи не должны запоминать определенного провайдера или детали доступа к провайдеру. Согласно одному варианту осуществления предложенного в данном документе предмета, единственными специфическими для клиента данными, которые пользователь должен помнить в этом варианте осуществления, являются адрес электронной почты пользователя и пользовательский пароль, требуемый для начала сеанса пользователя на модуле провайдера. Тем самым клиентское программное обеспечение не должно загружать и представлять пользователю список провайдеров для выбора им в этом случае соответствующего провайдера, но пользователь должен только лишь поставить адрес электронной почты и соответствующий пользовательский пароль, причем согласно одному варианту осуществления коммуникация с поисковым модулем 104 выполнена таким образом, что не производится обмена какими-либо зашифрованными данными с поисковым модулем. Прежде всего, согласно одному варианту осуществления, клиентский модуль 102 выполнен для генерации соответствующих связанных с пользователем данных (например, идентификационной метки) из адреса электронной почты и из других связанных с пользователем данных (например, соленой идентификационной метки) из пользовательского пароля. Например, согласно одному варианту осуществления клиентский модуль 102 выполнен для хеширования адреса электронной почты и хеширования хеша пароля пользовательского пароля совместно со случайной криптографической солью. При отсылках в дальнейшем на соответствующие идентификационные метки данных пользователя (адрес электронной почты) и на другие данные пользователя (пользовательский пароль) следует понимать, что эти примеры являются только примерными и, что также могут быть реализованы и другие варианты осуществления с любыми иными связанными с пользователем данными и с другими связанными с пользователем данными.
Краткий обзор параметров и примерные варианты осуществления значений параметров, вовлеченных в коммуникацию между клиентским модулем 102 и поисковым модулем 104 согласно показанному на фиг.2 примерному протоколу поиска провайдера, приведен в таблице I.
Следует заметить, что согласно одному варианту осуществления возвращаемые значения не содержат значения регистрационного имени пользователя, в противоположность показанному в таблице I.
Описание формата обмена данными JSON для примерного поискового запроса 105 из клиентского модуля 102 в поисковый модуль представлено следующим образом.
Тем самым теперь при обращении к протоколу поиска на фиг.2, который осуществляет цикл передачи запроса и ответный цикл передачи, как задано в таблицах I-III, клиентский модуль 102 коммуникативно соединен через соединение SSL с поисковым модулем 104, и передает поисковый запрос 105, как он задан в строке значения таблицы I. Согласно одному варианту осуществления клиентский модуль выполнен для задания начальных параметров поискового запроса 105. Это задание начальных параметров представлено посредством элемента 126 блок-схемы. Если хеш адреса электронной почты и хеш пароля, которые поставлены в поисковый модуль 104 в поисковом запросе 105, являются действительными, поисковый модуль 104 возвращает в цикле 116 передачи ответа возвращаемые значения согласно первой альтернативе, приведенной в таблице I, то есть предоставляет URL провайдера и зарегистрированное имя пользователя, равно как и информацию о состоянии. Согласно одному варианту осуществления клиентский модуль принимает URL провайдера и зарегистрированное имя, поставленные с циклом передачи ответа, и выполняет проверку соединения с применением пользовательского пароля, известного клиентскому модулю, как обозначено в 128.
Согласно одному варианту осуществления в составе поискового запроса 105 в поисковый модуль 104 переданы следующие данные: подлежащая выполнению операция (ОР), причем операция может быть представлена операцией «поиск провайдера», соответствующей, например, запросу на поиск провайдера, и ассоциированное зарегистрированное имя для данного хеша адреса электронной почты. Кроме того, поисковый запрос 105 может содержать хеш адреса электронной почты, соответствующий тому адресу электронной почты, который пытается зарегистрироваться в модуле провайдера, криптографическую соль и хеш пароля, который вычислен по комбинации хешированного пользовательского пароля и криптографической соли. Как может быть уяснено из таблицы II, области в описании формата обмена данными JSON могут быть представлены как «ор» для подлежащей выполнению операции, «emailHash» для хеш-кода адреса электронной почты пользователя, «passHashSalt» для криптографической соли и «passHashHash» для хеш-кода пользовательского пароля, который является соленым хеш-кодом хеша пароля.
В цикле 116 передачи ответа в клиентский модуль могут быть поставлены связанные с конфигурированием данные, которые в примерном варианте осуществления являются адресом модуля провайдера (URL провайдера) и зарегистрированным именем пользователя, необходимым для регистрации в модуле провайдера, адрес которого содержится в цикле 116 передачи ответа. Например, в варианте осуществления этот модуль провайдера является модулем 118 провайдера. Согласно другому варианту осуществления цикл 116 передачи ответа, кроме того, содержит информацию о состоянии, указывающую на действительность или на недействительность идентификационных меток, поставленных посредством клиентского модуля 102 в поисковом запросе 105. Например, согласно одному варианту осуществления информация о состоянии в цикле передачи ответа имеет одно из значений «неверно», «ошибка» или «верно». В данном документе информация о состоянии имеет значение «верно», если идентификационные метки, поставленные в поисковом запросе 105, то есть хеш адреса электронной почты и хеш пароля, являются действительными. Кроме того, информация о состоянии имеет значение «неверно», если идентификационные метки, поставленные в поисковом запросе 105, являются недействительными. Кроме того, информация о состоянии имеет значение «ошибка», если произошла ошибка системы. Согласно одному варианту осуществления в случае, если информация о состоянии имеет одно из значений «ошибка» и «неверно», связанные с конфигурированием данные не заданы в цикле 116 передачи ответа. Согласно другому варианту осуществления информация о состоянии может иметь значение «отсутствует поддержка», что указывает на отсутствие поддержки посредством поискового модуля 104 провайдера, ассоциированного с поставленными в поисковом запросе 105 идентификационными метками.
Согласно одному варианту осуществления клиентский модуль 102 выполнен для отображения соответствующего сообщения, соотнесенного информации о состоянии, поставленной в цикле 116 передачи ответа. Например, если информация о состоянии имеет значение «отсутствует поддержка», клиентский модуль может быть выполнен для отображения сообщения 130 о том, что провайдер не поддержан посредством поискового модуля (отображает «сообщение об отсутствии поддержки»). Кроме того, клиентский модуль может быть выполнен для показа сообщения 132 о том, что произошла ошибка в процессе процедуры поиска (отображает «сообщение об ошибке»), если информация о состоянии указывает на то, что произошла ошибка системы. Кроме того, клиентский модуль 102 может быть выполнен для показа сообщения 134 о том, что поставленные в поисковом запросе идентификационные метки являются недействительными (отображает «сообщение о недействительности»), если информация о состоянии указывает на то, что идентификационные метки в поисковых запросах являются недействительными. Кроме того, клиентский модуль 102 может быть выполнен для отображения для пользователя связанных с конфигурированием данных, если информация о состоянии имеет значение «верно», причем, например, данными пользователя являются URL провайдера и зарегистрированное имя пользователя. Согласно одному варианту осуществления клиентский модуль может быть выполнен для автоматического выполнения дальнейших действий, основанных на связанных с конфигурированием данных, полученных в цикле 116 передачи ответа, если информация о состоянии имеет значение «верно». Например, согласно одному варианту осуществления клиентский модуль может автоматически согласовывать соединение с модулем 118 провайдера с использованием URL провайдера и зарегистрированного имени пользователя, поставленных в цикле 116 передачи ответа совместно с пользовательским паролем, введенным посредством пользователя в клиентский модуль 102. Согласно одному варианту осуществления клиентский модуль 102, по завершении успешной проверки соединения с модулем 118 провайдера, может быть выполнен для хранения данных пользователя, то есть URL провайдера и зарегистрированного имени пользователя, равно как и пользовательского пароля. Согласно другим вариантам осуществления только URL провайдера и зарегистрированное имя пользователя сохранены в клиентском модуле, и пользователь должен вводить свой пользовательский пароль прежде, чем соединение с модулем 118 провайдера будет установлено посредством клиентского модуля. Необходимо отметить, что согласно одному варианту осуществления проверка соединения или установление соединения с модулем 118 провайдера включают в себя, по меньшей мере, регистрацию в модуле провайдера 118.
В дальнейшем, коммуникация поискового модуля 104 и согласующего модуля 110 согласно вариантам осуществления предложенного в данном документе предмета обсуждена со ссылками на фиг. 2.
Коммуникация между поисковым модулем 104 и согласующим модулем 110 может быть выполнена через соединение VPN или SSL. Тем самым согласно соответствующему варианту осуществления поисковый модуль 104 и согласующий модуль 110 коммуникативно соединены, например, через соединение VPN или SSL. Прежде всего, поисковый модуль 104 и согласующий модуль 110 могут быть коммуникативно соединены через соединение VPN или SSL.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для поставки цикла передачи запроса 136 в согласующий модуль 110. Согласно одному варианту осуществления цикл 136 передачи запроса содержит другую идентификационную метку данных пользователя. С целью должного различения идентификационной метки данных пользователя в цикле 136 передачи запроса и идентификационной метки данных пользователя в поисковом запросе 105, идентификационная метка данных пользователя в поисковом запросе 105 названа «первой идентификационной меткой данных пользователя», а данные пользователя в цикле 136 передачи запроса названы «второй идентификационной меткой данных пользователя». Однако термины «первый» и «второй» нельзя рассматривать как ограничивающие. Например, согласно одному варианту осуществления первая идентификационная метка данных пользователя идентична второй идентификационной метке данных пользователя. Другими словами, вторая идентификационная метка данных пользователя может быть представлена идентификационной меткой данных пользователя, поставленной в поисковом запросе 105 в поисковый модуль.
Согласно другому варианту осуществления цикл 136 передачи запроса содержит пароль, поставленный посредством поискового модуля. Этот пароль поставлен посредством поискового модуля для проверки действительности цикла передачи запроса и называется в данном документе также СПП-паролем. Согласно одному варианту осуществления согласующий модуль выполнен для обработки поискового запроса поискового модуля только в том случае, если СПП-пароль является действительным.
Согласно другому варианту осуществления цикл 136 передачи запроса содержит операционный индикатор, указывающий на подлежащую выполнению посредством согласующего модуля операцию. Например, операционный индикатор может быть представлен индикатором «поиск провайдера» указывающим на то, что согласующий модуль получил запрос на осуществление выборки информации о провайдере (идентификационной информации провайдера), соответствующей содержанию цикла передачи запроса (например, соответствующей второй идентификационной метке данных пользователя).
Согласно одному варианту осуществления цикл 138 передачи ответа из согласующего модуля 110 в поисковый модуль 104 содержит информацию о состоянии, указывающую на состояние запроса, соответствующий циклу 136 передачи запроса. Согласно одному варианту осуществления цикл 138 передачи ответа, кроме того, содержит идентификационные данные провайдера, идентифицирующие модуль 118 провайдера, ассоциированный с другой идентификационной меткой данных пользователя, поставленной в согласующий модуль 110 в цикле 136 передачи запроса.
При рассмотрении теперь обработки цикла 136 передачи запроса посредством согласующего модуля 110, следует отметить, что согласно одному варианту осуществления, прежде всего, осуществляется проверка 139 действительности СПП-пароля, поставленного в цикле передачи запроса.
Согласно одному варианту осуществления согласующий модуль выполнен для проверки действительности СПП-пароля. Согласно одному варианту осуществления согласующий модуль 110 выполнен для поставки соответствующей информации о состоянии в цикле 138 передачи ответа из согласующего модуля 110 в поисковый модуль 104. Например, согласно одному варианту осуществления согласующий модуль 110 выполнен для задания, в блоке 140, информации о состоянии значения «запрещено», указывающему на запрещение дальнейшей обработки цикла 136 передачи запроса, если поставленный в цикле 136 передачи запроса СПП-пароль не является действительным, что обозначено в блоке 141.
Согласно одному варианту осуществления цикл 138 передачи ответа передается не сразу после окончания обработки цикла 136 передачи запроса посредством согласующего модуля (например, после проверки 139 пароля с результатом «запрещено»). Напротив, после окончания обработки цикла 136 передачи запроса посредством согласующего модуля цикл 138 передачи ответа поставляется в поисковый модуль 104 с заданной задержкой (то есть после заданного времени ожидания). Таким образом, безопасность сетевой системы может быть повышена, поскольку атаки прямым подбором и синхронные атаки могут быть предотвращены. Заданное время ожидания может пребывать в диапазоне секунд, например, между 1 секундой и 10 секундами или между 2 секундами и 7 секундами в другом варианте осуществления.
Согласно одному варианту осуществления согласующий модуль выполнен для осуществления выборки идентификационных данных провайдера, соответствующих хешу адреса электронной почты (например, второй идентификационной метке данных пользователя), полученному в цикле 136 передачи запроса, если проверка пароля в блоке 139 показала, что СПП-пароль является действительным, что обозначено как 142. Действие поиска, то есть выборка идентификационных данных, провайдера (идентификатора провайдера), соответствующих хешу адреса электронной почты, обозначено в блоке 144 на фиг. 2. Если в процессе выборки идентификационных данных провайдера произошла обозначенная как 145 ошибка, например, вследствие отказа аппаратных средств или программного обеспечения в согласующем модуле, информация о состоянии в цикле передачи ответа указывает на то, что произошла ошибка. Согласно одному варианту осуществления производится определение 146 того, произошла ли ошибка в процессе выборки идентификационных данных провайдера. Согласно одному варианту осуществления если ошибка произошла, обозначенная 145 информация о состоянии получает значение «ошибка», что обозначено как 148. Если не произошло никакой ошибки, что обозначено как 150, в блоке 152 осуществляется проверка того, были ли найдены идентификационные данные провайдера для второй идентификационной метки данных пользователя (например, для данного хеша адреса электронной почты). Если никаких идентификационных данных провайдера для второй идентификационной метки данных пользователя не было найдено, что указано как 153, согласно одному варианту осуществления информация о состоянии в цикле 138 передачи ответа указывает на то, что никакие идентификационные данные провайдера не являются доступными для второй идентификационной метки данных пользователя, поставленных в цикле 136 передачи запроса (информация о состоянии: «неверно»). Например, согласно одному варианту осуществления согласующий модуль выполнен для задания информации о состоянии значения «неверно», что обозначено как 154, если не найдено никаких идентификационных данных провайдера для данного хеша адреса электронной почты.
Согласно одному варианту осуществления согласующий модуль 110 выполнен для поставки информации о состоянии, указывающей на то, что идентификационные данные провайдера были найдены для второй идентификационной метки данных пользователя (хеша адреса электронной почты), например, посредством задания информации о состоянии значения «верно», если были найдены идентификационные данные провайдера для второй идентификационной метки данных пользователя, что указано как 156. Согласно одному варианту осуществления только в этом случае идентификационные данные провайдера заданы в цикле 138 передачи ответа. В примерном варианте на фиг. 2 идентификационными данными провайдера являются «СН2». Задание идентификационных данных провайдера и задание информации о состоянии в цикле 138 передачи ответа обозначены в блоке 158 на фиг. 2.
Согласно одному варианту осуществления цикл 136 передачи запроса, равно как и соответствующий цикл 138 передачи ответа, осуществлен с использованием описания формата обмена данными JSON для параметров цикла передачи запроса и цикла передачи ответа. Таблица IV показывает описание формата обмена данными JSON для параметров цикла 136 передачи запроса.
Описание формата обмена данными JSON для соответствующего примерного цикла 138 передачи ответа приведено в таблице V.
Краткий обзор параметров и примерные варианты осуществления значений параметров, вовлеченных в коммуникацию между поисковым модулем 104 и согласующим модулем 110 согласно показанному на фиг. 2 примерному протоколу поиска провайдера, приведены в таблице VI.
В дальнейшем, последующая обработка цикла 138 передачи ответа, поставленного посредством согласующего модуля 110 в поисковый модуль 104, описана в отношении вариантов осуществления предложенного в данном документе предмета.
Если цикл 138 передачи ответа содержит информацию о состоянии, указывающую на то, что СПП-пароль цикла 136 передачи запроса не был действительным, информация о состоянии в цикле 116 передачи ответа из поискового модуля 104 в клиентский модуль 102 указывает на то, что произошла ошибка в процессе обработки поискового запроса 105. Например, согласно одному варианту осуществления поисковый модуль выполнен для задания информации о состоянии в цикле 116 передачи ответа значения «ошибка», что указано в блоке 160 на фиг. 2, если цикл 138 передачи ответа содержит информация о состоянии, указывающую на то, что СПП-пароль цикла 136 передачи запроса не был действительным.
Если цикл 138 передачи ответа из согласующего модуля 110 в поисковый модуль 104 указывает на то, что произошла ошибка в процессе поиска идентификатора провайдера в блоке 144 (состояние: «ошибка»), поисковый модуль может быть выполнен для проверки, обозначенной в блоке 164, на необходимость выполнения дальнейших согласующих операций. Например, согласно одному варианту осуществления имеются два или более согласующих модуля (например, для Европы, Азии, Ближнего Востока), и в этом случае, поисковый модуль может быть выполнен для продолжения действий, если один согласующий модуль потерпит неудачу, путем повторения операции с последующим согласующим модулем. Например, если проверка 164 для дальнейших согласующих операций указывает на то, что дальнейшие согласующие операции должны быть выполнены, что обозначено как 166, то согласно одному варианту осуществления поисковый модуль 104 выполнен, в блоке 135, для задания начальных параметров цикла 136 передачи запроса с использованием значений для дальнейшей согласующей операции. Если проверка 164 на необходимость дальнейших согласующих операций указывает на то, что какие-либо дальнейшие согласующей операции, обозначенные как 168, не должны быть выполнены, то выполняется проверка 170 того, действительно ли все согласующие операции оказались неуспешными. Если эта проверка 170 показывает, что все согласующие операции оказались неуспешными, что обозначено как 172, информации о состоянии в цикле 116 передачи ответа из поискового модуля 104 в клиентский модуль 102 может быть посредством поискового модуля задано значение «ошибка», что указано в блоке 160. Если проверка 170 показала, что не все согласующие операции потерпели неудачу, что обозначено как 174, информации о состоянии в цикле 116 передачи ответа из поискового модуля 104 в клиентский модуль 102 может быть посредством поискового модуля задано значение «неверно», что указано в блоке 176.
Если информация о состоянии в цикле 138 передачи ответа из согласующего модуля 110 в поисковый модуль 104 указывает на то, что не было найдено никаких идентификационных данных провайдера для другой идентификационной метки данных пользователя (состояние: «неверно»), поисковый модуль 104 выполнен для поставки в цикле 116 передачи ответа информации о состоянии, означающей, что данные пользователя (адрес электронной почты) и/или другие данные пользователя (пользовательский пароль) являются недействительными. Например, согласно одному варианту осуществления поисковый модуль 104 выполнен для задания информации о состоянии в цикле 116 передачи ответа значения «неверно», что обозначено как 176.
Если цикл 138 передачи ответа из согласующего модуля 110 в поисковый модуль 104 содержит информацию о состоянии, указывающую на то, что идентификационные данные провайдера для другой идентификационной метки данных пользователя были успешно выбраны, и/или если цикл 138 передачи ответа содержит идентификационные данные провайдера, поисковый модуль 104 может быть выполнен для осуществления выборки связанных с конфигурированием данных, которые ассоциированы с данными пользователя (например, ассоциированы с хешем пароля, полученным поисковым модулем 104 в поисковом запросе 105. Для осуществления выборки связанных с конфигурированием данных согласно одному варианту осуществления поисковый модуль 104 выполнен для осуществления выборки связанных с провайдером данных (например, адреса провайдера, такого как URL провайдера), которые ассоциированы с идентификационными данными провайдера, полученными из согласующего модуля в цикле 138 передачи ответа.
Согласно одному варианту осуществления идентификационным данным провайдера может быть задано значение ноль или другое предопределенное значение, если идентификационные данные провайдера, соответствующие второй идентификационной метке данных пользователя (хешу адреса электронной почты), не были успешно выбраны. В таком случае, отдельная информация о состоянии может быть исключена в цикле 138 передачи ответа, поскольку идентификационные данные провайдера как таковые предоставляют некоторую информацию по состояние выборки идентификационных данных провайдера.
Если выборка 178 связанных с провайдером данных, которые соответствуют идентификационным данным провайдера, была успешной, что обозначено как 180, то есть связанные с провайдером данные были найдены, то проверка 179 на успешность выборки связанных с провайдером данных является положительной. Поисковый модуль 104 может быть выполнен для поставки в клиентский модуль 102 в цикле 116 передачи ответа информации о состоянии означающей, что провайдер клиентского модуля 102, который ассоциирован с данными пользователя, не поддержан посредством поискового модуля 104, если проверка 179 на успешность выборки связанных с провайдером данных является отрицательной, что обозначено как 182. Например, согласно одному варианту осуществления поисковый модуль 104 может быть выполнен, в таком случае, для задания информации о состоянии значения «отсутствует поддержка», что обозначено как 184.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для передачи запроса 186 провайдера в модуль 118 провайдера, который идентифицирован посредством идентификационных данных провайдера, если выборка связанных с провайдером данных (URL провайдера в примерном случае, показанном на фиг. 2), была успешной, что обозначено как 180.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для передачи запроса 186 провайдера в модуль 118 провайдера с использованием связанных с провайдером данных (например, с использованием URL провайдера).
Согласно одному варианту осуществления модуль 118 провайдера выполнен для обработки запроса 186 провайдера, например для выполнения по меньшей мере одного из действий, как то: (i) проверки действительности данных пользователя (адреса электронной почты) и/или других данных пользователя (пользовательского пароля), и (ii) выборки связанных с конфигурированием данных. Согласно одному варианту осуществления модуль 118 провайдера выполнен для поставки ответа 188 провайдера в поисковый модуль 104 в ответ на обработку запроса 186 провайдера. Для коммуникации между поисковым модулем 104 и модулем 118 провайдера поисковый модуль 104 и модуль 118 провайдера могут быть коммуникативно соединены, например, через соединение VPN или SSL. Согласно одному варианту осуществления модуль 118 провайдера только выполняет проверку действительности известных поисковому модулю 104 связанных с пользователем данных (например, идентификационной метки данных пользователя и идентификационной метки других данных пользователя).
Согласно другому варианту осуществления модуль 118 провайдера может альтернативно или дополнительно быть выполненным для осуществления выборки связанных с конфигурированием данных после получения запроса 186 провайдера и после поставки связанных с конфигурированием данных, например регистрационных данных в ответе 188 провайдера в поисковый модуль 104.
Согласно одному варианту осуществления запрос 186 провайдера содержит связанные с пользователем данные и другие связанные с пользователем данные, как описано в данном документе, например идентификационную метку данных пользователя (хеш-код адреса электронной почты), идентификационную метку других данных пользователя (соленый хеш хеша пароля), а также криптографическую соль, используемую для генерации идентификационной метки других данных пользователя. Кроме того, запрос провайдера может содержать операционную инструкцию для модуля провайдера, которая, например, предписывает модулю провайдера поиск других связанных с пользователем данных. Согласно одному варианту осуществления соответствующим параметрам запроса 186 провайдера могут быть заданы, что обозначено как 190, начальные значения, доступные поисковому модулю 104. Описание формата обмена данными JSON для параметров данных для отправки запроса провайдера приведено в таблице VII.
Согласно одному варианту осуществления модуль 118 провайдера выполнен, после получения запроса 186 провайдера, для проверки связанных с пользователем данных, поставленных посредством поискового модуля 104. Например, согласно одному варианту осуществления модуль 118 провайдера выполнен для проверки идентификационной метки данных пользователя и идентификационной метки других данных пользователя. С этой целью модуль провайдера может вычислять идентификационную метку данных пользователя, сохраненную в модуле 118 провайдера, и идентификационную метку других данных пользователя, сохраненную в модуле 118 провайдера. Если одна из идентификационных меток, например идентификационная метка других данных пользователя, является соленой идентификационной меткой, модуль 118 провайдера выполнен для использования криптографической соли, поставленной в запросе 186 провайдера, для вычисления соленой идентификационной метки. Согласно одному варианту осуществления модуль 118 провайдера выполнен для проверки действительности данных пользователя (например, проверке хеша адреса электронной почты) посредством вычисления идентификационной метки данных пользователя и сравнения результата с идентификационной меткой данных пользователя, полученной в запросе 186 провайдера. Согласно одному варианту осуществления модуль 118 провайдера выполнен для нахождения других связанных с пользователем данных, например зарегистрированного имени, соответствующего данным пользователя.
Кроме того, согласно одному варианту осуществления модуль 118 провайдера выполнен для проверки идентификационной метки пароля посредством осуществления выборки пользовательского пароля для зарегистрированного имени и вычисления идентификационной метки для выбранного пользовательского пароля и, наконец, сравнения полученной идентификационной метки с идентификационной меткой пользовательского пароля, полученной в запросе 186 провайдера. Вышеописанные варианты осуществления обработки запроса 186 провайдера посредством модуля провайдера обозначены как 191 на фиг. 2. Следует заметить, что согласно одному варианту осуществления в случае, когда запрос 186 провайдера передан в модуль 118 провайдера через защищенное соединение (например, VPN или SSL соединение), модуль провайдера выполнен для расшифровки полученного зашифрованного запроса 186 провайдера для того, чтобы сделать запрос провайдера доступным для модуля провайдера.
Согласно одному варианту осуществления модуль 118 провайдера выполнен для выполнения проверки 192 на то, произошла ли ошибка в процессе выборки зарегистрированного имени. Согласно одному варианту осуществления модуль 118 провайдера выполнен для включения в ответ 188 провайдера информации о состоянии, которая информация о состоянии указывает на наличие ошибки системы, если проверка 192 показала, что произошла ошибка, что обозначено как 194 на фиг. 2. Кроме того, согласно одному варианту осуществления модуль 118 провайдера, в таком случае, выполнен для исключения задания зарегистрированного имени в ответе 188 провайдера.
Согласно одному варианту осуществления модуль 118 провайдера выполнен для выполнения проверки 198 на то, являются ли связанные с пользователем данные, поставленные в запросе провайдера, действительными связанными с пользователем данными. Например, согласно одному варианту осуществления модуль провайдера 118 проверяет на этапе 198, являются ли действительными данные пользователя, соответствующие идентификационной метке данных пользователя, и другие данные пользователя, соответствующие идентификационной метке других данных пользователя. Согласно одному варианту осуществления проверка 198 выполнена в том случае, если не произошло никакой ошибки в ходе проверки 192 на ошибки, что обозначено как 196. Если проверка 198 действительности является отрицательной, что обозначено как 199 на фиг. 2, например, в случае, когда данные пользователя и/или другие данные пользователя не являются действительными, согласно одному варианту осуществления модуль 118 провайдера поставляет в ответе 188 провайдера информацию о состоянии в поисковый модуль 104, которая информация о состоянии указывает на то, что данные пользователя и/или другие данные пользователя не являются действительными. Например, согласно одному варианту осуществления модуль 118 провайдера выполнен для задания информации о состоянии значения «неверно», что обозначено как 200.
Модуль провайдера 118 может быть выполнен для включения в ответ провайдера информации о состоянии, которая информация о состоянии указывает на то, что связанные с пользователем данные, на которых основана идентификационная метка(-ки), являются действительными, если проверка 198 действительности является положительной, что обозначено как 202. Кроме того, согласно одному варианту осуществления модуль провайдера 118 выполнен для включения в ответ 188 провайдера других связанных с конфигурированием данных, если проверка 198 действительности является положительной. Присваивание начальных значений соответствующим параметрам ответа 188 провайдера обозначено как 204, а соответствующее описание формата обмена данными JSON ответа приведено в таблице VIII.
Краткий обзор параметров и примерные варианты осуществления значений параметров, вовлеченных в коммуникацию между поисковым модулем 104 и модулем 118 провайдера, приведены в таблице IX.
Согласно одному варианту осуществления, поисковый модуль 104 выполнен для поставки цикла передачи ответа из поискового модуля 104 в клиентский модуль 102 в ответ на ответ 188 провайдера, полученный посредством клиентского модуля 104 из модуля 118 провайдера. Например, если информация о состоянии в ответе 188 провайдера указывает на то, что произошла ошибка системы, соответствующая информация о состоянии, указывающая на то, что произошла ошибка, содержится в цикле 116 передачи ответа из поискового модуля 104 в клиентский модуль 102. Например, поисковый модуль 104 может быть выполнен для задания в цикле 116 передачи ответа информации о состоянии значения «ошибка», что обозначено как 206 на фиг. 2. Кроме того, если ответ 188 провайдера из модуля 118 провайдера указывает на то, что соответствующие идентификационной метке(-кам) связанные с пользователем данные, поставленные в поисковом запросе 105 к поисковому модулю 104, не являются действительными, поисковый модуль может включать соответствующую информация о состоянии в цикл 116 передачи ответа из поискового модуля 104 в клиентский модуль 102. Например, согласно одному варианту осуществления поисковый модуль может быть выполнен, в таком случае, для задания информации о состоянии значения «неверно», что обозначено как 208.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для поставки связанных с провайдером данных, выбранных посредством поискового модуля 104 в ходе процесса 178 поиска, в клиентский модуль 102 в цикле 116 передачи ответа. Согласно одному варианту осуществления поисковый модуль 104 выполнен для поставки связанных с провайдером данных, только в том случае, если информация о состоянии ответа 188 провайдера указывает на то, что соответствующие идентификационной метке(-кам) связанные с пользователем данные, поставленные в поисковом запросе 105 в поисковый модуль 104, являются действительными.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для включения связанных с конфигурированием данных, полученных из модуля 118 провайдера в ответе 188 провайдера, в цикл 116 передачи ответа из поискового модуля 104 в клиентский модуль 102, если такие связанные с конфигурированием данные поставлены посредством модуля 118 провайдера в ответе 188 провайдера. Задание начальных значений соответствующих параметров цикла 116 передачи ответа обозначено как 210 на фиг. 2.
Фиг. 3 схематично показывает функционирование сетевой системы согласно вариантам осуществления предложенного в данном документе предмета.
Фиг. 3 относится к регистрации модуля 118 провайдера в поисковом модуле 104 и в согласующем модуле 110.
Прежде всего, фиг. 3 относится к регистрационному протоколу провайдера, согласно которому модуль 118 провайдера регистрируется в согласующем модуле 110 и в поисковом модуле 104. Относительно функционирования сетевой системы следует понимать, что каждый модуль провайдера, который вовлечен в коммуникации, как описано относительно фиг. 2, должен быть зарегистрирован в согласующем модуле 110 и в поисковом модуле 104.
Согласно одному варианту осуществления модуль 118 провайдера выполнен для поставки регистрационного запроса 220 в поисковый модуль 104. Согласно одному варианту осуществления регистрационный запрос 220 содержит, по меньшей мере, часть идентификационных данных провайдера, которые идентифицируют модуль 118 провайдера. Например, согласно одному варианту осуществления идентификационные данные провайдера содержат географический код и идентификатор провайдера. Согласно одному варианту осуществления только часть идентификационных данных провайдера, например идентификатор провайдера в примерном случае, поставлена в поисковый модуль 104 в регистрационном запросе 220. Идентификатор провайдера обозначен на фиг. 3 как «providerid». Согласно одному варианту осуществления регистрационный запрос 220 содержит подлежащую выполнению операцию (ОР). Например, подлежащая выполнению операция может быть представлена операцией «регистрация нового модуля провайдера в поисковом модуле 104». Согласно одному варианту осуществления поисковый модуль выполнен для регистрации части идентификационных данных провайдера (идентификатора провайдера) и сетевого адреса модуля 118 провайдера, например, в базе данных, управляемой посредством поискового модуля. Согласно другому варианту осуществления регистрационный запрос 220 содержит связанные с проверкой данные, основанные на проверочных данных, например идентификационную метку проверочных данных, которая обозначена на фиг. 3 как «secretHash». Связанные с проверкой данные могут быть использованы посредством поискового модуля 104 и/или согласующего модуля 110 для проверки того, был ли регистрационный запрос 220 передан посредством модуля 118 провайдера в соответствии с идентификатором провайдера, заданным в регистрационном запросе 220. Другими словами, согласно одному варианту осуществления проверочные данные являются зашифрованными данными и известны в примерном случае исключительно вовлеченным модулям, например, модулю провайдера и согласующему модулю, показанном на фиг. 3. Согласно другому варианту осуществления идентификационная метка проверочных данных может быть использована для дополнения части идентификационных данных провайдера (идентификатора провайдера), поставленных в поисковый модуль 104 в регистрационном запросе 220. Дополнение, которое совместно с частью идентификационных данных провайдера образует полные идентификационные данные провайдера, может быть поставлено посредством согласующего модуля.
Согласно другому варианту осуществления регистрационный запрос 220 может содержать криптографическую соль (например, обозначенную на фиг. 3 как «secretSalt»), например, в том случае, когда идентификационная метка проверочных данных является соленой идентификационной меткой проверочных данных, сгенерированной с использованием криптографической соли, используемой для генерации идентификационной метки проверочных данных.
Согласно одному варианту осуществления регистрационный запрос 220, кроме того, содержит сетевой адрес модуля 118 провайдера, например URL модуля 118 провайдера.
Описание формата обмена данными JSON для параметров данных при регистрации регистрационного запроса 220 из модуля 118 провайдера в поисковый модуль 104 показано в таблице X.
Задание начальных значений параметров регистрационного запроса 220 посредством модуля 118 провайдера обозначено на фиг. 3 как 222.
Согласно одному варианту осуществления модуль 118 провайдера, кроме того, выполнен для получения цикла 224 передачи ответа из поискового модуля 104 в ответ на регистрационный запрос 220. Согласно одному варианту осуществления цикл 224 передачи ответа содержит информацию о состоянии, например, относительно успешной обработки регистрационного запроса. Например, если информация о состоянии указывает на то, что регистрация модуля провайдера была выполнена успешно (например, если состоянию было задано значение «верно»), модуль провайдера может быть выполнен для продолжения выполнения способа, который инициировал регистрационный запрос 220, что обозначено как 226. Такой способ может быть представлен, например, мастером настройки регистрации, выполняемом на модуле 118 провайдера.
Согласно другому варианту осуществления модуль 118 провайдера выполнен для показа сообщения 228 об ошибке, если информация о состоянии в цикле 224 передачи ответа указывает на то, что произошла ошибка (состояние: ошибка). Например, сообщение об ошибке может рекомендовать пользователю произвести запрос оператора поискового модуля для сообщения об ошибке.
Согласно одному варианту осуществления модуль провайдера выполнен для показа сообщения о недействительности, если информация о состоянии в цикле 224 передачи ответа указывает на то, что проверка защиты в процессе обработки регистрационного запроса 220 потерпела неудачу 230.
Описание формата обмена данными JSON параметров цикла 224 передачи ответа согласно одному варианту осуществления показано в таблице XI.
Краткий обзор параметров, вовлеченных в регистрационный запрос 220 и цикл 224 передачи ответа, то есть параметров, вовлеченных в коммуникацию между модулем провайдера и поисковым модулем в процессе регистрации провайдера, приведен в таблице XII.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для получения регистрационного запроса 220 из модуля 118 провайдера. Согласно одному варианту осуществления поисковый модуль 104 выполнен для передачи цикла 232 передачи запроса в согласующий модуль, причем цикл 232 передачи запроса содержит связанные с провайдером идентификационные данные, которые основаны, по меньшей мере, на части идентификационных данных провайдера, которые поисковый модуль получил в регистрационном запросе 220. Задание начальных значений параметров цикла 232 передачи запроса обозначено на фиг. 3 как 233. Согласно одному варианту осуществления связанные с провайдером идентификационные данные являются идентичными, по меньшей мере, с частью идентификационных данных провайдера регистрационного запроса 220, которые согласно одному варианту осуществления являются идентификатором провайдера, обозначенным «providerid» в задании 233 начальных значений на фиг. 3. Согласно другому варианту осуществления цикл 232 передачи запроса содержит пароль «plsPass», в данном документе также называемый СПП-паролем. Согласно одному варианту осуществления СПП-пароль в цикле 232 передачи запроса является необходимым для обработки цикла передачи запроса посредством согласующего модуля. Другими словами, согласно одному варианту осуществления согласующий модуль выполнен для того, что он не обрабатывает цикл 23 передачи запроса, если цикл 232 передачи запроса не содержит действительного СПП-пароля. Согласно одному варианту осуществления цикл 232 передачи запроса содержит связанные с проверкой данные, которые поисковый модуль 104 получил от модуля провайдера 118 в регистрационном запросе 220. Необходимо принять во внимание, что в случае, когда связанные с проверкой данные являются соленой идентификационной меткой проверочных данных, цикл 232 передачи запроса также содержит криптографическую соль, которая была использована для вычисления соленой идентификационной метки проверочных данных. Как упомянуто выше, криптографическая соль может быть поставлена в поисковый модуль 104 посредством модуля 118 провайдера в регистрационном запросе 220.
Согласно другому варианту осуществления цикл 232 передачи запроса, кроме того, содержит операционный параметр «ор», указывающий на подлежащую выполнению посредством согласующего модуля операцию. Например, согласно одному варианту осуществления операционный параметр может запрашивать проверку, по меньшей мере, части идентификационных данных провайдера и/или связанных с проверкой данных. Например, согласно одному варианту осуществления операционному параметру может быть задано посредством поискового модуля 104 значение «проверка провайдера».
Согласно одному варианту осуществления согласующий модуль 110 выполнен для поставки цикла 236 передачи ответа в поисковый модуль 104 в ответ на цикл 232 передачи запроса.
Согласно одному варианту осуществления согласующий модуль 110 выполнен для проверки действительности СПП-пароля, поставленного в цикле 232 передачи запроса, что обозначено как 234. Согласующий модуль 110 может быть выполнен для включения информации о состоянии в цикл 236 передачи ответа, которая информация о состоянии указывает на то, что обработка цикла 232 передачи запроса посредством согласующего модуля 110 запрещена, если СПП-пароль, поставленный в согласующий модуль в цикле 232 передачи запроса не является действительным, что обозначено как 238. Согласно такому варианту осуществления согласующий модуль 110 может быть выполнен для задания информации о состоянии («status») в цикле 236 передачи ответа значения «запрещено», если проверка 234 пароля является отрицательной, то есть СПП-пароль, поставленный в цикле 232 передачи запроса, не является действительным. Задание информации о состоянии значения «запрещено» обозначено на фиг. 3 как 240. Согласно другому варианту осуществления, не показанному на фиг. 3, информация о состоянии в цикле 236 передачи ответа может указывать на недействительность СПП-пароля.
Если проверка 234 действительности СПП-пароля дает результат действительности СПП-пароля, что обозначено как 242, согласующий модуль, согласно одному варианту осуществления, выполнен для поиска идентификационных данных провайдера («providerid»), например, для поиска дополнения к части идентификационных данных провайдера и/или для проверки проверочных данных («зашифрованных данных»), что обозначено как 244, например, посредством проверки того, являются ли действительными связанные с проверкой данные (например, идентификационная метка проверочных данных). Для поиска идентификационных данных провайдера согласно одному варианту осуществления согласующий модуль может хранить в своем запоминающем устройстве полные идентификационные данные провайдера.
Согласно одному варианту осуществления выполняется проверка 246 на наличие ошибок, которая проверка 246 на наличие ошибок указывает на то, произошла ли ошибка в процессе поиска идентификатора провайдера и/или в процессе подтверждения идентификационной метки проверочных данных. Например, согласующий модуль 110 может быть выполнен для включения информации о состоянии в цикл 236 передачи ответа, которая информация о состоянии указывает на то, что произошла ошибка в процессе обработки цикла передачи запроса в том случае, если произошла ошибка системы, что обозначено как 248. Например, согласно одному варианту осуществления согласующий модуль 110 выполнен для задания, что обозначено как 250, состоянию в цикле 236 передачи ответа значения «ошибка», если проверка 246 на наличие ошибок указывает на то, что ошибка произошла.
Если никакой ошибки не произошло, что обозначено как 252, производится установление того, является ли действительной проверка проверочных данных, например, идентификационной метки проверочных данных. Эта проверка правильности данных обозначена как 254. Согласно одному варианту осуществления согласующий модуль 110 выполнен для включения в цикл 236 передачи ответа информации о состоянии, указывающей на то, что проверочные данные или идентификационная метка проверочных данных не являются действительными, если проверка 254 правильности данных указывает на то, что проверочные данные (или идентификационная метка проверочных данных) не являются действительными, что обозначено как 256. В этом отношении нужно отметить, что выявление действительности идентификационной метки проверочных данных, как считается, является идентичным выявлению действительности проверочных данных. Согласно одному варианту осуществления действительность данных выявляется посредством вычисления соответствующей идентификационной метки от проверочных данных, сохраненных в согласующем модуле, и сравнения полученной таким образом идентификационной метки с идентификационной меткой проверочных данных, полученной в цикле 232 передачи запроса. Если обе идентификационные метки совпадают друг с другом, проверочные данные являются действительными, равно как и идентификационная метка проверочных данных.
Если проверка 254 правильности данных дает тот результат, что идентификационная метка проверочных данных не является действительной, что обозначено как 256, согласующий модуль может быть выполнен для задания состоянию в цикле 236 передачи ответа значения «неверно», указывающего на то, что идентификационные данные провайдера или, по меньшей мере, их часть, поставленные в цикле передачи запроса в согласующий модуль 110, и/или связанные с проверкой данные не являются действительными, что обозначено на фиг. 3 как 258. Согласно одному варианту осуществления, согласующий модуль выполнен для включения дополнения идентификационных данных провайдера в цикл 236 передачи ответа, если проверка 254 правильности данных указывает на то, что идентификационные данные провайдера и/или связанные с проверкой данные является действительными, что обозначено как 260. Согласно другому варианту осуществления согласующий модуль 110 может быть, кроме того, выполнен для поставки информации о состоянии в цикле 236 передачи ответа, которая информация о состоянии указывает на то, что цикл 232 передачи запроса был успешно обработан посредством согласующего модуля 110 (состояние: верно).
Согласно одному варианту осуществления поисковый модуль 104 выполнен для получения цикла 236 передачи ответа из согласующего модуля 110. Согласно одному варианту осуществления поисковый модуль 104 выполнен для задания информации о состоянии в цикле 224 передачи ответа из поискового модуля 104 к модулю 118 провайдера значения, которое указывает на то, что произошла ошибка («состояние: ошибка», что обозначено как 264), если цикл 236 передачи ответа из согласующего модуля 110 в поисковый модуль 104 указывает на то, что СПП-пароль, поставленный в цикле 232 передачи запроса, не является действительным (состояние: «запрещено»).
Согласно одному варианту осуществления поисковый модуль 104 выполнен для проверки на необходимость большего числа согласований, что обозначено как 266, то есть для проверки того, должны ли дальнейшие регистрационные запросы быть переработаны посредством поискового модуля 104, если информация о состоянии в цикле 236 передачи ответа указывает на то, что произошла ошибка системы в согласующем модуле 110. Если проверка 266 на необходимость большего числа согласований показывает, что по меньшей мере один дальнейший регистрационный запрос должен быть обработан посредством поискового модуля 104, поисковый модуль 104 выполнен для обработки по меньшей мере одного дальнейшего регистрационного запроса, что обозначено как 268. Если не требуется переработки никакого дальнейшего регистрационного запроса посредством поискового модуля 104, что обозначено как 270, производится выявление того, все ли регистрационные запросы показывают ошибки, что обозначено как 272. Если ответ является позитивным, что обозначено как 274, информации о состоянии в цикле 224 передачи ответа из поискового модуля 104 в модуль 118 провайдера задается значение посредством поискового модуля 104, что обозначено как 264, таким образом, что оно указывает на то, что произошла ошибка («состояние: ошибка»).
Если выявление 272 того, привели ли все регистрационные запросы к ошибке, приводит к результату, что дело обстоит не так, что обозначено как 276, информация о состоянии в цикле 224 передачи ответа, поставленном посредством поискового модуля 104 в модуль 118 провайдера, имеет значение «неверно».
Согласно одному варианту осуществления поисковый модуль 104 выполнен для задания информации о состоянии в цикле 224 передачи ответа из поискового модуля 104 в модуль 118 провайдера такого значения, что оно указывает на то, что по меньшей мере одни данные из числа, по меньшей мере, части идентификационных данных провайдера и связанных с проверкой данных являются недействительными («состояние: неверно», что обозначено как 278), если цикл 236 передачи ответа из согласующего модуля 110 в поисковый модуль 104 указывает на то, что по меньшей мере одни данные из числа, по меньшей мере, части идентификационных данных провайдера и связанных с проверкой данных являются недействительными.
Согласно одному варианту осуществления поисковый модуль 104 выполнен для добавления сетевого адреса модуля 118 провайдера (поставленного в поисковый модуль 104 в регистрационном запросе 220) и (ассоциированных) идентификационных данных провайдера в запоминающее устройство поискового модуля 104, например в базу данных поискового модуля 104. Согласно другому варианту осуществления поисковый модуль 104 выполнен для обновления сетевого адреса модуля 118 провайдера и ассоциированных идентификационных данных провайдера в запоминающем устройстве поискового модуля 104.
Согласно одному варианту осуществления в случае, когда только часть идентификационных данных провайдера поставлена в поисковый модуль 104 в регистрационном запросе 220, поисковый модуль 104 выполнен для объединения дополнения идентификационных данных провайдера и части идентификационных данных провайдера, полученной в регистрационном запросе 220, с образованием полных идентификационных данных провайдера.
Согласно одному варианту осуществления дополнение идентификационных данных провайдера является географическим кодом, а часть идентификационных данных провайдера, поставленная в регистрационном запросе 220, является идентификатором провайдера, как в виде примера показано на фиг. 3. Добавление или обновление сетевого адреса провайдера и ассоциированных идентификационных данных провайдера в запоминающем устройстве (не показано на фиг. 3) обозначены как 280 и в дальнейшем именуются регистрацией.
Согласно одному варианту осуществления производится установление 282 того, произошла ли ошибка в процессе регистрации 280. Если в процессе регистрация 280 произошла ошибка, что обозначено как 284, информации о состоянии в цикле 224 передачи ответа из поискового модуля 104 в модуль 118 провайдера значение задано таким образом, что оно указывает на то, что произошла ошибка в процессе регистрации модуля провайдера («состояние: ошибка», что обозначено как 264).
Согласно одному варианту осуществления поисковый модуль 104 выполнен для задания информации о состоянии в цикле 224 передачи ответа такого значения, которое указывает на то, что регистрация модуля 118 провайдера в поисковом модуле 104 (и в согласующем модуле 110) была успешной («состояние: верно», что обозначено как 288), если не произошло никакой ошибки в процессе регистрации 280 в поисковом модуле 104, что обозначено как 286.
Согласно одному варианту осуществления цикл 232 передачи запроса, равно как и цикл 236 передачи ответа осуществляются с использованием для описания параметров цикла передачи запроса и цикла передачи ответа формата обмена данными JSON. Таблица XIII показывает описание формата обмена данными JSON для параметров цикла 232 передачи запроса:
Описание формата обмена данными JSON для примерного цикла 236 передачи ответа приведено в таблице XIV.
Краткий обзор параметров и примерные варианты осуществления значений параметров, вовлеченных в коммуникацию между поисковым модулем 104 и согласующим модулем 110 согласно показанному на фиг. 3 примерному регистрационному протоколу провайдера, приведен в таблице XV.
Описанные в данном документе варианты осуществления позволяют специалистам в данной области техники легко понять, что варианты осуществления могут быть осуществлены различными способами при учете общеизвестных знаний, доступных специалистам в данной области техники. Тем не менее, в последующем приведены некоторые примерные детали вариантов осуществления для поискового модуля 104, клиентского модуля 102, согласующего модуля 110 и модуля провайдера. Однако следует понимать, что приведенные специфические детали вариантов осуществления являются только примерными и не должны быть рассмотрены как ограничивающие. В дальнейшем приведен примерный вариант осуществления клиентского модуля 102.
Согласно одному варианту осуществления клиентский модуль 102 выполнен для запроса у пользователя зарегистрированного адреса электронной почты и пользовательского пароля, ассоциированного с этим адресом электронной почты. Согласно одному варианту осуществления клиентский модуль выполнен для генерации идентификационной метки согласно алгоритму хеширования SHA256 путем создания случайной криптографической соли и создания хешированной версии хешированного пользовательского пароля, посоленного с использованием криптографической соли:
SHA256 (соль: SHA1 (пользовательский пароль))
В этом случае закодированная версия формата обмена данными JSON:
Эта идентификационная метка (хеш-код соленого хеша пароля) затем отправлена в поисковый модуль 104 (например, в https://pls.regify.com/). По успешном завершении цикла передачи ответа клиент получает остальные данные
Тем самым клиентский модуль теперь может быть зарегистрирован в модуле 118 провайдера с использованием:
URL: https://regify.provider.com/
Имя пользователя: адрес электронной почты
Пароль: пароль
В случае ошибки клиентский модуль показывает пользователю диалог, указывающий на то, является ли ошибка связанной с регистрационными данными, в котором случае пользователь может повторно ввести регистрационные данные. В противном случае показанный пользователю диалог может указывать на то, что ошибка связана с системой, в котором случае пользователю может быть предоставлена возможность введения сетевого адреса провайдера (URL) и ручной регистрации.
В том, что относится к поисковому модулю 104, согласно одному варианту осуществления поисковый модуль 104 поддерживает базу данных идентификационных данных провайдера для отображений в виде карт распределения сетевых адресов провайдеров (URL провайдеров). Провайдер может быть добавлен в базу данных поискового модуля посредством выполнения сетевого оперативного консультанта на модуле провайдера.
Согласно одному варианту осуществления база данных поискового модуля 104 содержит таблицу провайдера, которая может быть сгенерирована посредством следующей команды языка структурированных запросов (SQL):
результатом выполнения которой является таблица провайдера, как она представлена в виде Таблицы XVI:
Эта таблица обновляется при регистрации провайдера посредством поискового модуля 104. К таблице обращаются за сетевым адресом провайдера в процессе операции по поиску, показанной на фиг. 2, после того, как согласующий модуль 110 поставил провайдеру идентификационные данные для заданной идентификационной метки данных пользователя (например, для заданного хеша адреса электронной почты).
Согласно одному варианту осуществления все регистрационные запросы и поисковые запросы протоколируются для обеспечения управления статистикой и трассировкой. Согласно одному варианту осуществления поисковый модуль выполнен для отделения географического кода идентификационных данных провайдера от остальной части идентификационных данных провайдера перед созданием записи системного журнала. Примерная таблица регистрации может быть составлена с помощью следующих команд SQL:
что дает в результате следующую примерную таблицу регистрации
tbllog
Примерные записи таблицы регистрации для Таблицы XVII при успешной регистрации провайдера и успешных поисковых запросах приведены в следующей таблице:
Соответствующие образцы регистрационных записей неудавшегося регистрационного запроса и неудавшегося поискового запроса могут быть следующими:
Детальные сообщения об ошибках содержат сообщения от каждого запрошенного согласующего модуля. Следует заметить, что может иметься число n согласующих модулей, которые могут быть запрошены посредством поискового модуля 104. Примерные детальные сообщения об ошибках выглядят следующим образом.
Поскольку поисковые запросы о недавно зарегистрированном пользователе могут потребовать запрашивания нескольких согласующих модулей, поддержаны поисковые таблицы, которые ассоциируют согласующие модули со страной происхождения поискового запроса согласно GeoIP. GeoIP является доступным через Интернет сервисом, который делает возможным определение географического местоположения сервера, посредством предоставления серверам сетевых адресов (IP-адресов). Действие задачи-планировщика или отсутствие файла РНР могут привести к обновлению этих табличных структур. Поисковый модуль 104 в этом случае начинает проверку хешей адресов электронной почты с того согласующего модуля, который имеет показатели наибольшего успеха в стране происхождения запроса. Последующий запрос SQL, на который распространяется действие оптимизации, может быть использован в таблице регистрации «TBL log» для извлечения списка провайдеров, которые обслуживают уникальные хеши адресов электронной почты в заданной стране:
Результат может тогда быть переработан посредством программы, и записан, например, в файле РНР, содержащем представление хеша/списка в порядке согласующего модуля. Согласующие географические коды, не найденные в запросе, прилагаются согласно одному варианту осуществления. Согласно одному варианту осуществления существует также порядок поиска по умолчанию в случае, когда страна происхождения еще не находится в карте хеша. Ниже приведено примерное представление такой структуры данных:
Согласно одному варианту осуществления выполнение функций согласующего модуля 110, как описано в данном документе, обеспечена для существующего согласующего модуля посредством предоставления нового программного приложения, называемого, например, PLS.PHP. Согласно одному варианту осуществления это приложение отвечает только на запросы с действительным СПП-паролем, который подлежит заданию в соответствующем цикле 136, 232 передачи запроса в согласующий модуль. Например, согласно одному варианту осуществления СПП-пароль задан как значение «PLSpass» в соответствующей структуре формата обмена данными JSON. Согласно одному варианту осуществления каждый согласующий модуль имеет строго один СПП-пароль, который должен соответствовать паролям в запросах. Согласно другому варианту осуществления каждый согласующий модуль выполняет три операции, которые заданы в операционной области отправленной структуры формата обмена данными JSON.
Далее приведен примерный вариант осуществления функции поиска провайдера. Наиболее употребимой функцией согласующего модуля является функция «поиск провайдера», которая, например, запускается посредством соответствующего цикла 136 передачи запроса из поискового модуля 104 в согласующий модуль 110. Согласно одному варианту осуществления эта функция «поиск провайдера» осуществляет поиск ассоциированных идентификационных данных провайдера для заданной идентификационной метки данных пользователя (например, хеша адреса электронной почты). Вовлеченная логика представлена в основном запросом SQL в виде:
Согласно одному варианту осуществления согласующий модуль 110 и поисковый модуль 104 выполнены таким образом, что в случае признания результата запроса пустым, результату присваивается состояние: «неверно». В противном случае, состояние имеет значение: «верно», а поле «идентификатор провайдера» содержит найденные идентификационные данные провайдера, такие как «DE6». Ответ может выглядеть как:
В последующем описан примерный вариант осуществления проверки провайдера. Другая операция используется в том случае, когда провайдер регистрируется в поисковом модуле 104 для проверки своей подлинности. Эта операция (ор) в варианте осуществления названа «проверка провайдера».
Структура данных формата обмена данными JSON в примерном варианте осуществления:
В данном случае согласующий сервер проверяет, что часть идентификационных данных провайдера («идентификатор провайдера: 2»), действительно заканчивается идентификационной меткой проверочных данных («шифровальным хешем») при хешировании заданной криптографической соли («шифровальной соли») с помощью проверочных данных («зашифрованных данных»). В случае успеха согласующий модуль 110 возвращает в поисковый модуль 104:
Согласно одному варианту осуществления согласующий модуль 110 выполнен для получения контрольного запроса из поискового модуля, причем контрольный запрос делает возможной проверку того, пребывает ли согласующий модуль 110 в состоянии нормального функционирования.
Контрольный запрос может быть следующим:
В том, что относится к модулю провайдера, следует отметить, что согласно одному варианту осуществления регистрация провайдера может быть выполнена посредством сетевого оперативного консультанта. Вариант осуществления модуля провайдера сетевой системы согласно вариантам осуществления предложенного в данном документе предмета, например протокола поиска провайдера, как он примерно показан на фиг. 2, может также быть выполнен посредством использования баз данных SQL и приложений РНР. Однако также возможны и другие варианты осуществления предложенных в данном документе вариантов осуществления предмета как для модуля провайдера, равно как и для других модулей, например клиентского модуля, поискового модуля и согласующего модуля.
В том, что относится к описанным в данном документе вариантам осуществления, следует отметить, что в различных циклах коммуникации может производиться обмен различными данными пользователя (или данными, полученными на их основе). Например, для поискового запроса из клиентского модуля в поисковый модуль, адрес электронной почты и пользовательский пароль могут быть использованы в качестве основания для связанных с пользователем данных и для других связанных с пользователем данных, и только адрес электронной почты может быть использован в качестве основания для связанных с пользователем данных при коммуникации между поисковым модулем и согласующим модулем.
Необходимо принять во внимание, что использование соленых идентификационных меток требует адаптации вовлеченных модулей. Например, если используется соленая идентификационная метка хеша пароля, модуль провайдера требует соответствующей адаптации, которая позволяет ему проверять соленую идентификационную метку. Например, для проверки соответствия соленой идентификационной метки полученного из поискового модуля пароля соответствующему паролю, сохраненному в модуле провайдера, модуль провайдера может быть выполнен для вычисления идентификационной метки пароля, сохраненного в модуле провайдера, к объединению идентификационной метки с шифровальной солью и для вычисления конечной идентификационной метки от таким способом посоленной идентификационной метки. Подразумевается, что примененный для вычисления конечной идентификационной метки способ должен быть одинаковым во всех вовлеченных модулях, например в вышеупомянутом варианте, в клиентском модуле и в модуле провайдера, с целью обеспечения возможности проверки на идентичность данных, на основании которых были вычислены идентификационные метки.
В то время как циклы передачи между модулями согласно вариантам осуществления предложенного в данном документе предмета иногда описаны как включающие в себя операционный параметр, указывающий на подлежащую выполнению операцию, следует понимать, что такой операционный параметр может быть исключен согласно одному варианту осуществления. Например, соответствующий модуль может быть выполнен для выполнения определенного действия, если цикл передачи с предопределенной структурой данных получен этим модулем. Такая предопределенная структура данных может быть представлена той же структурой данных, что описана относительно вариантов осуществления предложенного в данном документе предмета, за исключением того, что в структуре данных исключен рабочий параметр.
Хотя некоторые варианты осуществления описаны со ссылками на различные элементы предметной области базы данных или модули, следует понимать, что соответствующие признаки каждого из элементов предметной области базы данных или модулей могут быть реализованы независимо от признаков других элементов предметной области базы данных или модулей, если только другие признаки не являются обязательными для одного признака.
Согласно одному варианту осуществления согласующий модуль постоянно сохраняет секретные данные, такие как идентификационные данные, ассоциированные со связанными с пользователем данными, но поставляет такие данные только по запросу из поискового модуля. Другими словами, согласно одному варианту осуществления согласующий модуль не начинает коммуникацию с другими модулями, он только отвечает. Тем самым повышена безопасность. Соответственно и согласно одному варианту осуществления, активным компонентом системы является поисковый модуль.
В то время как в описании чертежей задана определенная последовательность действий (например, проверки 139, 146, 152, 164, 170, 179, 192, 198), следует понимать, что такая примерная последовательность не должна быть рассмотрена как ограничивающая. Квалифицированным лицам понятно, что многие описанные действия могут быть выполнены в различной последовательности, или даже, что никакая определенная последовательность не является необходимой, например, в случае параллельного выполнения некоторых описанных здесь действий, когда ожидающий компонент системы (функция, модуль или последующее действие) может только ожидать окончания необходимых действий.
В то время как некоторые варианты осуществления относятся к заданию начальных значений параметров структур данных, например описаний формата обмена данными JSON, следует понимать, что такая процедура является только одной возможностью выполнения соответствующих циклов передачи информации, информационных элементов и значений параметров из одного модуля в другой модуль.
В то время как в некоторых примерных случаях сделана ссылка на значение параметра и на другое значение параметра (например, на связанные с конфигурированием данные и на другие связанные с конфигурированием данные), следует понимать, что такие варианты нельзя рассматривать как ограничение предложенного предмета в отношении числа значений параметров.
Прежде всего, в дополнение к предложенным двум параметрам (значениям параметров) в таких случаях, как описано в данном документе, способы и устройства могут быть выполнены к работе исключительно с единственным параметром (значением параметра) или к работе с тремя или более параметрами (значениями параметров).
Следует заметить, что в случаях, когда определенные варианты осуществления предложенного в данном документе предмета описаны относительно связанных с компонентами системы данных в виде идентификационной метки (например, связанных с пользователем данных в виде идентификационной метки данных пользователя), необходимо понимать, что согласно более общим вариантам осуществления соответствующие связанные с компонентами системы данные используются вместо явно описанной идентификационной метки (то есть, также может быть реализован вариант осуществления посредством соотнесения со связанными с пользователем данными, которые основаны на данных пользователя, вместо соотнесения с идентификационной меткой данных пользователя).
Коммуникация между модулями согласно вариантам осуществления предложенного в данном документе предмета может быть выполнена через произвольное подходящее соединение/подходящую сеть, например, через Интернет, локальную сеть (LAN), региональную сеть (WAN), сотовую связь и т.д.
Кроме того, необходимо отметить, что компонент системы или модуль, как описано в данном документе, не ограничены специализированным компонентом системы, как описано в некоторых вариантах осуществления. Скорее предложенный в данном документе предмет может быть осуществлен различными способами в различных местоположениях в сетевой системе, при условии обеспечения требуемого выполнения функций.
Согласно вариантам осуществления изобретения любой описанный в данном документе подходящий компонент системы (например, компоненты, модули и устройства), например клиентский модуль, поисковый модуль, согласующий модуль и модуль провайдера, по меньшей мере, частично представлен в виде соответствующих компьютерных программ, которые позволяют процессорному устройству обеспечивать выполнение функций соответствующих компонентов системы, как они описаны в данном документе.
Согласно другим вариантам осуществления любой описанный в данном документе подходящий компонент системы может быть представлен в виде аппаратных средств. Согласно другим, гибридным, вариантам осуществления некоторые компоненты системы могут быть представлены в виде программного обеспечения, в то время как другие компоненты системы представлены в виде аппаратных средств.
Необходимо отметить, что любой описанный в данном документе подходящий компонент системы (например, компоненты, модули и устройства), не ограничен специализированным компонентом системы, как описано в некоторых вариантах осуществления. Скорее предложенный в данном документе предмет может быть осуществлен различными способами и с различной степенью детализации на уровне устройства или на уровне программного модуля, при условии обеспечения выполнения требуемой функции. Кроме того нужно отметить, что согласно вариантам осуществления отдельный компонент системы (например, программный модуль, модуль аппаратных средств или гибридный модуль (то есть, объединенный модуль программного обеспечения/аппаратных средств)) может быть предоставлен для каждой из описанных в данном документе функций. Согласно другим вариантам осуществления компонент системы (например, программный модуль, модуль аппаратных средств или гибридный модуль) выполнен для обеспечения двух или более функций, как описано в данном документе. Согласно одному варианту осуществления каждый модуль связан с процессорным устройством, содержащим по меньшей мере один процессор для выполнения по меньшей мере одной компьютерной программы для обеспечения выполнения функций модуля согласно одному или нескольким вариантам осуществления предложенного в данном документе предмета.
Необходимо отметить, что термин «содержащий» не исключает другие элементы или этапы, а использование в описании единственного числа не исключает множественности. Кроме того, термин «использование» (некоторых данных) не исключает использования, в дополнение к ним, и других данных. Также могут быть объединены элементы, описанные в связи с различными вариантами осуществления. Нужно также отметить, что ссылочные обозначения в пунктах формулы изобретения не должны быть рассмотрены как ограничивающие предметный охват пунктов.
С целью обобщения вышеописанных вариантов осуществления настоящего изобретения, может быть заявлено:
Предоставлена сетевая система 100, содержащая согласно одному варианту осуществления поисковый модуль 104, согласующий модуль 110, имеющий запоминающее устройство, и клиентский модуль 102. Клиентский модуль 102 выполнен для поставки связанных с пользователем данных 106 в поисковый модуль 104, причем связанные с пользователем данные 106 основаны на данных пользователя, данные пользователя ассоциированы с пользователем, и связанные с пользователем данные 106 обеспечивают однозначную идентификацию данных пользователя. Кроме того, поисковый модуль выполнен для осуществления выборки идентификационных данных 114 из согласующего модуля 110 с использованием связанных с пользователем данных 106, причем идентификационные данные 114 ассоциированы с данными пользователя 106, и согласующий модуль 110 выполнен для осуществления выборки из запоминающего устройства идентификационных данных 114, ассоциированных с данными пользователя. Согласующий модуль 110 выполнен для поставки идентификационных данных 114 в поисковый модуль 104. Поисковый модуль 104 выполнен для осуществления выборки связанных с конфигурированием данных 115 для поставляемого пользователю обслуживания, причем связанные с конфигурированием данные 115 выбраны с использованием идентификационных данных 114.