Устройство обработки информации и способ управления устройством обработки информации

Устройство обработки информации и способ управления устройством обработки информации

Иллюстрации

Показать все

Реферат

УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

[0001] Настоящее изобретение относится к устройству обработки информации и способу управления устройством обработки информации.

ОПИСАНИЕ УРОВНЯ ТЕХНИКИ

[0002] Известны многофункциональные периферийные устройства (MFP: многофункциональное периферийное устройство), имеющие функции, такие как функции для сканирования, печати и связи. MFP снабжено панелью управления на основном корпусе, и пользователь может использовать функцию копирования, функцию сканирования или подобные, из MFP посредством эксплуатации панели управления. Также, в последние годы, MFP снабжаются функциями, такими как функции для сервера совместного использования файлов, веб-сервера или подобными, и терминал в сети имеет возможность осуществления доступа к функциям сервера MFP с использованием протокола связи, такого как SMB (блок сообщений сервера), HTTP или подобного. Также MFP снабжаются MIB (базой информации управления), и терминал в сети имеет возможность осуществления доступа к MIB для MFP и использованием SNMP v3 (RFC3414 (модель обеспечения защиты на уровне пользователей (USM)) для версии 3 простого протокола управления сетью (SNMP v3)), который известен как протокол управления сетевым устройством.

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

[0004] В случаях, когда единое MFP снабжается множеством механизмов аутентификации пользователей таким образом, есть нижеследующие способы координирования механизмов аутентификации. Подход для ассоциации и синхронизации пользовательской информации, используемой в основном для аутентификации для панели управления, и пользовательской информации, управляемой посредством USM (модель обеспечения защиты на уровне пользователей) из SNMP v3, известен (например, выложенная заявка на патент Японии № 2006-195755).

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

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

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

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

[0007] В случае, когда множество механизмов аутентификации пользователей существуют в едином устройстве, из-за вышеописанных проблем, целесообразной является конфигурация, в которой главным образом используется единый механизм аутентификации пользователей, в случае, когда протоколы связи, функции или подобные являются разными. Однако в каждом способе аутентификации пользователей каждого вида протокола связи есть различия в спецификациях, и поддержка обработки, относящейся к аутентификации пользователей для всех протоколов связи в едином механизме аутентификации пользователей, является трудной. Например, так как схема, заданная USM из SNMP v3, выполняет не только аутентификацию пользователей с использованием пароля пользователя, но также выполняет криптографическую обработку, обработку обнаружения сигнатуры/фальсификации или подобное, с помощью ключа, сгенерированного на основе пароля, такая обработка является сложной.

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

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

[0009] Аспектом настоящего изобретения является устранение вышеупомянутых проблем с традиционной технологией.

[0010] Признаком настоящего изобретения является предоставление способа, в котором возможно интегрировать администрирование, относящееся к аутентификации пользователя.

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

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

(ii) получения, из запоминающего блока, способа вычисления, соответствующего протоколу;

(iii) преобразования полученного пароля в хэш в соответствии с полученным способом вычисления; и

(iv) верификации подлинности данных аутентификации с помощью хэша.

[0012] Настоящее изобретение в своем втором аспекте предоставляет способ управления устройством обработки информации, способным принимать запрос аутентификации в соответствии с протоколом из множества протоколов, причем способ содержит: этап сохранения для сохранения в память идентификатора пользователя и пароля для каждого пользователя и способа вычисления для каждого протокола; этап приема для приема запроса аутентификации от удаленного компьютера в соответствии с протоколом из множества протоколов, причем запрос аутентификации включает в себя данные аутентификации; этап управления для:

(i) получения, из памяти, пароля, соответствующего данным аутентификации, которые включены в запрос аутентификации;

(ii) получения, из памяти, способа вычисления, соответствующего протоколу;

(iii) преобразования полученного пароля в хэш в соответствии с полученным способом вычисления; и

(iv) верификации подлинности данных аутентификации с помощью хэша.

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

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

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

[0015] Фиг. 1 изображает упрощенный вид, показывающий конфигурацию сети согласно первому варианту осуществления настоящего изобретения.

[0016] Фиг. 2 является блок-схемой, показывающей конфигурацию аппаратных средств MFP согласно первому варианту осуществления.

[0017] Фиг. 3 является блок-схемой для разъяснения конфигурации программного обеспечения MFP и PC и конфигурации данных, которыми программное обеспечение управляет согласно первому варианту осуществления.

[0018] Фиг. 4A-4D изображают виды, показывающие пользовательские интерфейсы, на которых локальные UI отображаются на пульте управления согласно первому варианту осуществления.

[0019] Фиг. 5A-5F изображают виды для разъяснения пользовательских интерфейсов настроек.

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

[0021] Фиг. 7A-7С изображают виды, показывающие примеры API, которые имеет система аутентификации пользователей согласно первому варианту осуществления.

[0022] Фиг. 8 изображает вид, показывающий пример содержимого таблицы обработки аутентификации согласно первому варианту осуществления.

[0023] Фиг. 9 является схемой последовательности операций для описания функционирования системы аутентификации пользователей, когда API по Фиг. 7A вызывается в MFP согласно первому варианту осуществления.

[0024] Фиг. 10A-10D изображают виды, показывающие взаимосвязи программных модулей, когда MFP выполняет аутентификацию пользователей, вместе с потоком данных согласно первому варианту осуществления.

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

[0026] Фиг. 12 является блок-схемой, показывающей конфигурацию программного обеспечения MFP и сервера аутентификации согласно второму варианту осуществления.

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

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

[0028] Фиг. 1 изображает упрощенный вид, показывающий конфигурацию сети согласно первому варианту осуществления настоящего изобретения.

[0029] С сетью (LAN) 100 соединены MFP 101, который является примером устройства обработки информации согласно настоящему изобретению, и персональный компьютер (PC) 102. MFP 101 и PC 102 способны осуществлять связь друг с другом через LAN 100. Здесь, MFP 101 является многофункциональным периферийным устройством, снабженным множеством функций, таких как функции для сканирования, печати и осуществления связи.

[0030] Фиг. 2 является блок-схемой, показывающей конфигурацию аппаратных средств MFP 101 согласно первому варианту осуществления.

[0031] Блок 200 управления, включающий в себя CPU 201, управляет всеми операциями MFP 101. CPU 201 развертывает ОС (операционную систему), программы управления или подобные, которые установлены на HDD 204, в RAM 203 в соответствии с программой загрузки, хранящейся в ROM 202, и MFP 101 функционирует под управлением CPU 201, который исполняет программы. RAM 203 используется в качестве области временного хранения, такой как основная память, рабочая область или подобное, в CPU 201. HDD 204 хранит данные изображения, различные программы или подобное. Интерфейс 205 пульта управления соединяет пульт 209 управления и блок 200 управления. Пульт 209 управления снабжается блоком отображения, который функционирует как воспринимающая касания панель. Интерфейс 206 принтера соединяет блок 210 принтера и блок 200 управления. Данные изображения, которые должны быть напечатаны блоком 210 принтера, пересылаются из блока 200 управления на блок 210 принтера через интерфейс 206 принтера, и печатаются блоком 210 принтера на носителе записи, таком как лист. Интерфейс 207 сканера соединяет блок 211 сканера и блок 200 управления. Блок 211 сканера генерирует данные изображения посредством сканирования изображения на оригинале и подает данные изображения на блок 200 управления через интерфейс 207 сканера. Сетевой интерфейс 208 соединяет блок 200 управления (MFP 101) с LAN 100. Сетевой интерфейс 208 передает данные изображений, информацию или подобное, на внешнее устройство (например, веб-сервер, или подобное), соединенное с LAN 100, и принимает различную информацию от внешнего устройства в LAN 100.

[0032] Следует отметить, что так как PC 102 образован посредством конфигурации аппаратных средств универсального компьютера, которая в общем известна, объяснение конфигурации PC 102 опущено.

[0033] Фиг. 3 является блок-схемой для разъяснения конфигурации программного обеспечения MFP 101 и PC 102 и конфигурации данных, которыми программное обеспечение управляет согласно первому варианту осуществления. Следует отметить, что символы стрелок по Фиг. 3 представляют вызывающий модуль и цель вызова для функций в основных случаях использования. Ниже дано объяснение для функций программного обеспечения и данных, которыми управляет программное обеспечение.

[0034] Программное обеспечение MFP 101 хранится как программа на HDD 204 MFP 101, и функции, разъясненные ниже, реализуются этой программой, развернутой в RAM 203, и посредством CPU 201, исполняющим программу.

[0035] Локальный UI (пользовательский интерфейс) 301 отображает пользовательские интерфейсы, которыми оперирует пользователь, на пульте 209 управления и обеспечивает пользователя функциями, которые имеет MFP 101.

[0036] Фиг. 4A-4D изображают виды, показывающие примеры пользовательских интерфейсов, которые локальный UI 301 отображает на пульте 209 управления, согласно первому варианту осуществления.

[0037] Например, Фиг. 4A изображает вид, иллюстрирующий пример экрана аутентификации пользователей для аутентификации пользователя, который использует пульт 209 управления. Фиг. 4B представляет собой пример экрана изменения пароля для запроса, чтобы пользователь, который осуществил аутентификацию на экране аутентификации пользователей по Фиг. 4A, изменил пароль. Фиг. 4C представляет собой пример экрана меню, показывающего список функций, предоставляемый пользователю, который использует пульт 209 управления. Фиг. 4D представляет собой пример экрана пользовательского интерфейса для использования функции "окна" MFP 101. Например, пользователь имеет возможность сохранения данных изображения, полученных из блока 211 сканера, на HDD 204 как электронного документа посредством использования экрана пользовательского интерфейса по Фиг. 4D. Или пользователь имеет возможность печати электронного документа, полученного из HDD 204, с использованием блока 210 принтера.

[0038] PC 102 снабжается программным обеспечением, таким как веб-браузер 317, инструмент 319 управления файлами, инструмент 321 управления MFP или подобными.

[0039] Веб-браузер 317 снабжается функцией, в которой веб-браузер 317 осуществляет связь с HTTP-сервером 302 MFP 101 в качестве HTTP-клиента 318. HTTP-сервер 302 вызывает удаленный UI 303 после приема запроса от веб-браузера 317. Удаленный UI 303 предоставляет пользователю, эксплуатирующему веб-браузер 317, пользовательский интерфейс, заданный в HTML. HTTP-сервер 302 возвращает HTML-данные, полученные от удаленного UI 303, веб-браузеру 317 в качестве ответа на запрос от веб-браузера 317.

[0040] Инструмент 319 управления файлами снабжается функцией, в которой инструмент 319 управления файлами осуществляет связь с SMB/CIFS-сервером 304 MFP 101 в качестве SMB/CIFS-клиента 320. SMB/CIFS-сервер 304 снабжается процессором 305 NTLM-аутентификации для обработки протокола NTLM- (NT LAN Manager) аутентификации. SMB/CIFS-сервер 304 вызывает службу 306 управления документами, когда SMB/CIFS-сервер 304 принимает запрос, такой как запрос просмотра файла, сохранения файла или подобного, от инструмента 319 управления файлами. Служба 306 управления документами снабжается функциями для предоставления просмотра или обновления электронных документов (файлов, имеющих расширение файла, такое как PDF, JPEG, PNG, DOC или подобное), сохраненных на HDD 204, и выполнения сохранения новых файлов, или подобного.

[0041] Инструмент 321 управления MFP снабжается функцией для осуществления доступа к MIB 309, которой MFP 101 обеспечивается посредством осуществления доступа к SNMP-серверу 307 MFP 101 в качестве SNMP-клиента 322. SNMP-сервер 307 обеспечивается блоком 308 обработки USM-аутентификации для обработки протокола аутентификации пользователей, заданного посредством USM из SNMP версии 3. SNMP-сервер 307 обращается к данным, сохраненным в MIB 309, и выполняет настройки, когда SNMP-сервер 307 принимает запрос осуществления доступа от инструмента 321 управления MFP PC 102.

[0042] Система 310 аутентификации пользователей снабжается механизмом для аутентификации пользователя, который использует MFP 101. Ниже дано разъяснение деталей функций, которые имеет система 310 аутентификации пользователей.

[0043] Системе 310 аутентификации пользователей предоставляется UI 311 настроек для пользователя, который управляет MFP 101, для выполнения настройки, относящейся к аутентификации пользователей MFP 101. UI 311 настроек может быть сконфигурирован как пользовательский интерфейс, описанный в HTML, который пригоден для использования из веб-браузера 317 PC 102 аналогично удаленному UI 303.

[0044] Фиг. 5A-5F изображают виды для разъяснения пользовательских интерфейсов из UI 311 настроек.

[0045] Фиг. 5A представляет собой пример экрана меню. Когда любой из элементов, обозначенных номерами 502-505, указан на экране по Фиг. 5A, обработка переходит на экран для указанной функции. Настройка 502 аутентификации пользователей является пользовательским интерфейсом для задания функции аутентификации пользователей MFP 101 в состояние ВКЛ или ВЫКЛ. Когда настройка 502 аутентификации пользователей указана на экране по Фиг. 5A, обработка переходит на экран по Фиг. 5B. На экране по Фиг. 5B пользователь имеет возможность задания аутентификации пользователей в состояние ВКЛ или ВЫКЛ, и система 310 аутентификации пользователей сохраняет содержимое, которое задано здесь, как настройку 312 аутентификации на HDD 204. Каждый программный модуль имеет возможность обращения к настройке ВКЛ/ВЫКЛ аутентификации пользователей посредством осуществления доступа к настройке 312 аутентификации. В примере по Фиг. 5B, аутентификация пользователей задана в состояние ВКЛ (аутентификация пользователей включена).

[0046] Экран по Фиг. 5C отображается посредством управления 503 учетными записями пользователей, указываемого на экране по Фиг. 5A. На экране по Фиг. 5C пользователь имеет возможность регистрации и редактирования имени пользователя и полномочий пользователя. Экран по Фиг. 5D представляет собой пример экрана, который отображается, когда на экране по Фиг. 5C указывается "зарегистрироваться" или "редактировать". Пользователь имеет возможность выполнения регистрации, редактирования или подобного, учетной записи пользователя посредством экранов пользовательского интерфейса, показанных на Фиг. 5C и Фиг. 5D. Система 310 аутентификации пользователей управляет информацией, относящейся к учетной записи пользователя, зарегистрированного с использованием экрана по Фиг. 5D, посредством хранения информации в базе данных 313 пользователей на HDD 204. Имя пользователя "Alice" зарегистрировано как администратор на экране по Фиг. 5D, и также зарегистрирован пароль, соответствующий имени пользователя.

[0047] Фиг. 6 изображает вид, показывающий пример конфигурации данных базы данных 313 пользователей согласно первому варианту осуществления.

[0048] Здесь имя пользователя 601, пароль 602 и полномочия 603 зарегистрированы посредством экранов пользовательского интерфейса, показанных на Фиг. 5C и Фиг. 5D. Дата/время 604 последнего обновления пароля представляет собой данные и время, в которые пароль зарегистрирован или обновлен посредством экрана по Фиг. 5D.

[0049] Экран по Фиг. 5E отображается посредством настройки 504 политики паролей, указываемой на экране по Фиг. 5A. Фиг. 5E представляет собой пример экрана пользовательского интерфейса для задания политики, относящейся к паролям. Например, "нет периода действия", "30 дней" и "90 дней" могут быть выбраны в качестве периодов действия паролей. Также может быть выбрано, является ли допустимым/недопустимым "три буквы или более" (настройка, чтобы пароль принудительно составлял три буквы или более), "включая символ" (настройка для принудительного включения символа в пароль), или подобное, в качестве настроек для сложности пароля. Система 310 аутентификации пользователей сохраняет набор элементов посредством экрана по Фиг. 5E в качестве настроек 314 политики паролей на HDD 204.

[0050] Экран по Фиг. 5F отображен посредством управления 505 журналом аутентификации, указываемым на экране по Фиг. 5A. Фиг. 5F представляет собой экран пользовательского интерфейса для управления записями журнала результатов аутентификации. На Фиг. 5F возможно просматривать журналы 316 аутентификации, которые система 310 аутентификации пользователей записывает на HDD 204. На этом экране отображаются имя пользователя, режим аутентификации, дата и время, в которые выполнена аутентификация, и результат аутентификации (OK или NG (не удачно)), которые зарегистрированы в журналах 316 аутентификации.

[0051] Фиг. 7A-7C изображают виды, показывающие пользовательские интерфейсы API (интерфейсы программирования приложений), которыми система 310 аутентификации пользователей обеспечивается согласно первому варианту осуществления.

[0052] Посредством других программных модулей, вызывающих API 701 по Фиг. 7A, системе 310 аутентификации пользователей может быть выдан запрос аутентификации, запрашивающий аутентификацию пользователей. Система 310 аутентификации пользователей определяет функционирование API 701 посредством обращения к таблице 315 обработки аутентификации на основе информации от вызывающего модуля 702.

[0053] Фиг. 8 изображает вид, показывающий пример содержимого таблицы 315 обработки аутентификации согласно первому варианту осуществления.

[0054] Таблица 315 обработки аутентификации хранит комбинацию из информации 801 вызывающего модуля, присутствия или отсутствия функции 802 изменения пароля вызывающего модуля, режима 803 вычисления, типа 804 обработки аутентификации или подобного. В информации 801 вызывающего модуля регистрируется протокол связи вызывающего модуля, который изначально выдает запрос аутентификации. Присутствие или отсутствие функции 802 изменения пароля вызывающего модуля представляет, содержит ли программный модуль вызывающего модуля функцию изменения пароля. Например, так как для локального UI 301, который управляет интерфейсом с помощью пользователя, присутствие или отсутствие функции 802 изменения пароля вызывающего модуля имеет значение "существует", и существует функция для отображения экрана изменения пароля по Фиг. 4B на экране управления.

[0055] Между тем, для протокола связи, такого как HTTP, SMB/CIFS и SNMP v3, не задан протокол для изменения пароля. По этой причине HTTP-сервер 302, SMB/CIFS-сервер 304 и SNMP v3 сервер 307 не имеют функции для запроса изменения пароля. Режим 803 вычисления представляет собой алгоритмы вычисления, которые API 701 использует для преобразования из пароля в другое значение. "БЕЗ ОБРАБОТКИ" представляет собой использование пароля как есть, без обработки пароля. "MD4" представляет собой вычисление MD4- (алгоритм классификации сообщений 4) классификатора (хэш-значения) из пароля. "MD5" представляет собой вычисление MD5 (алгоритм классификации сообщений 5) классификатора (хэш-значения) из пароля. Режим 803 вычисления не ограничен алгоритмами "MD4", "MD5" или подобными и может быть любым видом режима вычисления, пока режим 803 вычисления является известным режимом вычисления, который реализует система 310 аутентификации пользователей. Например, в общем известны алгоритмы вычисления, такие как HMAC (хэширование с помощью ключей для кода аутентификации сообщений) (RFC 2104), SHA (алгоритм безопасного хэширования) или подобные. Может быть взята такая конфигурация, в которой система 310 аутентификации пользователей обеспечивается алгоритмом вычисления NTLM или USM из SNMP версии 3 в качестве режима вычисления. Тип 804 обработки аутентификации категоризирует функционирование API 701 либо на "осуществить верификацию", либо на "возврат значения вычисления". "Осуществить верификацию" представляет собой API 701, выполняющий операцию верификации значения, вычисленного из пароля, относительно данных 704 аутентификации, принятых от вызывающего модуля, и возвращения результата верификации. "Возврат значения вычисления" представляет собой API 701, выполняющий операцию вычисления из пароля другого значения для пароля с помощью алгоритма, указанного "режимом 803 вычисления", и возвращения вычисленного значения (выходных данных, показанных номером 705 по Фиг. 7A).

[0056] Далее ниже дано разъяснение смысла возвращаемых значений 706 на Фиг. 7A, которые возвращает API 701.

[0057] - SUCCESS

SUCCESS представляет, что обработка API 701 выполнена успешно. В случае, в котором типом 804 обработки аутентификации является "осуществить верификацию", SUCCESS представляет, что обработка аутентификации пользователей выполнена успешно. В случае, в котором типом 804 обработки аутентификации является "возврат значения вычисления", значение, вычисленное из пароля, сохраняется в выходных данных 705 на Фиг. 7A и возвращается.

[0058] - SUCCESS_NEED_PWD_CHANGE

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

[0059] - ERROR

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

[0060] - ERROR_NEED_PWD_CHANGE

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

[0061] Описание разъясненного выше API 701 является только одним примером, и настоящее изобретение не ограничено этим примером. Например, может быть взята конфигурация, чтобы получить от вызывающего API модуля порцию или всю информацию таблицы 315 обработки аутентификации, показанной на Фиг. 8. В случае, когда от вызывающего модуля получена только порция информации, берется конфигурация, чтобы из таблицы 315 обработки аутентификации получить только информацию, требуемую для определения функционирования API. Посредством конфигурирования так, что таблица 315 обработки аутентификации имеет возможность редактирования извне, становится возможным поддерживать гибкую модификацию или добавление программных модулей, которые использует API.

[0062] Другой пример API показан на Фиг. 7B. API по Фиг. 7B использует параметры 708 и делает возможным получение от вызывающего модуля всей информации таблицы 315 обработки аутентификации, которая показана на Фиг. 8. Таким образом, в случае, когда берется конфигурация, чтобы получить от вызывающего модуля всю информацию, системе 310 аутентификации пользователей необязательно обращаться к таблице 315 обработки аутентификации. Также необязательно ограничивать API обработки аутентификации до одного API, и для каждой комбинации обработки, предусмотренной заранее, может быть подготовлено множество API. В разъяснении ниже, разъяснение дано с помощью API 701, показанного на Фиг. 7A, используемого в качестве API для обработки аутентификации.

[0063] API по Фиг. 7C получает результат аутентификации пользователей, которую исполняет программный модуль, и осуществляет запись в журнал в журналах 316 аутентификации.

[0064] Фиг. 9 является схемой последовательности операций для описания функционирования системы 310 аутентификации пользователей, когда, в MFP 101, программный модуль вызывает API 701 по Фиг. 7A согласно первому варианту осуществления. Следует отметить, что программа, которая исполняет эту обработку, развертывается в RAM 203 при исполнении и исполняется под управлением CPU 201.

[0065] Эта обработка инициируется посредством вызываемого API 701 по Фиг. 7A, и система 310 аутентификации пользователей принимает запрос на обработку, относящуюся к аутентификации пользователей. Сперва, на этапе S901, система 310 аутентификации пользователей получает информацию вызывающего модуля 702 и имя пользователя 703 (идентификатор пользователя) из параметров API 701. Далее обработка переходит на этап S902, и система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации на основе информации вызывающего модуля 702, получает режим аутентификации (присутствие или отсутствие функции изменения пароля, режим вычисления, тип обработки аутентификации). Далее обработка переходит на этап S903, и система 310 аутентификации пользователей определяет, зарегистрировано ли имя пользователя, полученное на этапе S901, в базе данных 313 пользователей (Фиг. 6) или нет. В случае, когда имя пользователя зарегистрировано, получают пароль 602 и дату/время 604 последнего обновления пароля, зарегистрированные в связи с именем пользователя. Между тем, в случае, когда имя пользователя не зарегистрировано в базе данных 313 пользователей, и пароль не мог быть получен на этапе S903, система 310 аутентификации пользователей определяет сбой аутентификации на этапе S904, так как система 310 аутентификации пользователей не может получить пароль, и обработка переходит на этап S914. На этапе S914 система 310 аутентификации пользователей осуществляет запись в журнал сбоя аутентификации. Затем обработка переходит на этап S915, система 310 аутентификации пользователей возвращает ошибку (ERROR) вызывающему API 701 модулю, и обработка завершается.

[0066] Между тем, в случае, когда получение пароля выполнено успешно на этапе S904, обработка переходит на этап S905, и система 310 аутентификации пользователей, обращаясь к настройке 314 политики паролей, определяет, удовлетворяет ли полученный пароль периоду действия, настройке сложности или подобному, или нет. Здесь, в случае, когда период действия пароля истек, или сложность неудовлетворительна, обработка переходит на этап S906, и система 310 аутентификации пользователей также определяет присутствие или отсутствие функции изменения пароля вызывающего модуля. Здесь в случае, когда функция изменения пароля существует, обработка переходит на этап S907, и обработка продолжается. Однако в случае, когда определено, что функция изменения пароля не существует на этапе S906, обработка переходит на этап S914, и осуществляется запись в журнал сбоя аутентификации, и затем на этапе S915 ошибка (ERROR_NEED_PWD_CHANGE) возвращается вызывающему API 701 модулю, и обработка завершается.

[0067] В случае, когда, на этапе S905, система 310 аутентификации пользователей определяет, что полученный пароль удовлетворяет периоду действия и настройке сложности, или в случае, когда, на этапе S906, определено, что функция изменения пароля вызывающего модуля существует, обработка переходит на этап S907. На этапе S907 система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, подтверждает режим 803 вычисления, заданный для вызывающего модуля. В случае, когда здесь режим вычисления не является режимом "БЕЗ ОБРАБОТКИ" (например, в случае "MD4" или "MD5"), обработка переходит на этап S908, и выполняется обработка вычисления, на основе полученного пароля, в соответствии с режимом вычисления. Например, MD4-классификация или MD5-классификация вычисляется здесь в соответствии с алгоритмом MD4 или MD5. Здесь, обработка переходит на этап S909, и система 310 аутентификации пользователей, обращаясь к таблице 315 обработки аутентификации, подтверждает тип 804 обработки аутентификации, заданный для вызывающего модуля. Здесь, в случае, когда типом 804 обработки аутентификации является "возврат значения вычисления", обработка переходит на этап S910, система 310 аутентификации пользователей сохраняет вычисленное значение в выходных данных 705 и возвращает успешное выполнение обработки (SUCCESS), и обработка завершается. Также, в случае, когда проверка политики паролей на этапе S905 дает здесь сбой, что-нибудь возвращается на это событие (SUCCESS_NEED_PWD_CHANGE).

[0068] Между тем, в случае, когда система 310 аутентификации пользователей, на этапе S909, определяет, что типом 804 обработки аутентификации является "осуществить верификацию", обработка переходит на этап S911, и система 310 аутентификации пользователей осуществляет верификацию подлинности данных аутентификации 704 (Фиг. 7A) относительно значения, вычисленного на этапе S908. В случае, когда результатом верификации является то, что данные аутентификации 704 и вычисленное значение совпадают, обработка переходит на этап S912, система 310 аутентификации пользователей осуществляет запись в журнал успеха аутентификации, обработка переходит на этап S913, успешное выполнение обработки (SUCCESS) возвращается вызывающему API модулю, и обработка завершается. В этом случае, в случае, когда проверка политики паролей на этапе S905 имеет значение NG, что-нибудь возвращается на это событие (SUCCESS_NEED_PWD_CHANGE).

[0069] Между тем, в случае, когда определено, что результатом верификации на этапе S911 является то, что данные аутентификации 704 и вычисленное значение не совпадают, то определяется сбой аутентификации, обработка переходит на этап S914, и система 310 аутентификации пользователей осуществляет запись в журнал сбоя аутентификации. Затем, на этапе S915, вызывающему API модулю возвращается ошибка (ERROR), и обработка завершается.

[0070] Далее будет дано разъяснение для примера функционирования, когда аутентификация пользователей на MFP 101 задана в состояние ВКЛ, и различные программные модули исполняют аутентификацию пользователей с использованием системы 310 аутентификации пользователей. Здесь будет дано разъяснение для случая, в котором программными модулями являются локальный UI 301, HTTP-сервер 302, SMB/CIFS-сервер 304 и SNMP-сервер 307.

[0071] Фиг. 10A-10D изображают виды, показывающие взаимосвязи программных модулей, когда MFP 101 выполняет аутентификацию пользователей, вместе с потоком данных согласно первому варианту осуществления.

[0072] Фиг. 10A изображает вид для разъяснения случая, когда локальный UI 301 выполняет аутентификацию пользователей с использованием системы 310 аутентификации пользователей. На Фиг. 10A экран аутентификации пользователей отображается на экране управления, и аутентификация пользователей запрашивается для пользователя, использующего MFP 101. Локальный UI 301, на этапе S1001, получает имя пользователя и пароль, которые пользователь вводит на экране аутентификации пользователей по Фиг. 4A. Также, на этапе S1002, локальный UI 301 делает запрос на обработку аутентификации посредством прохождения имени пользователя и пароля в систему 310 аутентификации пользователей посредством API 701 по Фиг. 7A. При этом система 310 ауте