СПОСОБ, СИСТЕМА И ИНФОРМАЦИОННЫЙ НОСИТЕЛЬ ДЛЯ СОХРАНЕНИЯ СОСТОЯНИЯ ВХОДА В ПОЛЬЗОВАТЕЛЬСКУЮ УЧЕТНУЮ ЗАПИСЬ

Родственные заявки

Настоящая заявка претендует на приоритет международной заявки на патент №PCT/CN 2013/078615, озаглавленной "METHOD AND SYSTEM FOR USER ACCOUNT TO MAINTAIN LOGIN STATE AND STORAGE MEDIUM", поданной 1 июля 2013 г. и претендующей на приоритет заявки на патент Китая No. 201210233708.2, озаглавленной "METHOD AND SYSTEM FOR USER ACCOUNT TO MAINTAIN LOGIN STATE", поданной 6 июля 2012 г., обе из которых полностью включены посредством ссылки в настоящий документ.

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

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

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

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

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

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

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

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

Способ сохранения состояния входа в пользовательскую учетную запись, включающий:

получение запроса данных для доступа в соответствии с пользовательским ID, причем запрос данных для доступа включает ID сеанса, соответствующий пользовательскому ID;

извлечение ID сеанса из запроса данных для доступа и получение сеанса в соответствии с ID сеанса; и

назначение для полученного сеанса запроса данных для доступа.

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

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

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

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

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

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

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

извлечение ID сеанса из запроса данных для доступа и получение сеанса в соответствии с ID сеанса; и

назначение для полученного сеанса запроса данных для доступа.

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

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

КРАТКОЕ ОПИСАНИЕ ГРАФИЧЕСКИХ МАТЕРИАЛОВ

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

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

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

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

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

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

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

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

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

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

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

S202, получение запроса для входа пользователя, при этом указанный запрос для входа пользователя содержит пользовательский ID;

S204, извлечение указанного пользовательского ID из указанного запроса для входа пользователя, авторизацию указанного пользовательского ID и создание после успешной авторизации сеанса, соответствующего указанному пользовательскому ID;

S206, получение ID сеанса, соответствующего указанному созданному сеансу; и

S208, сохранение в кэш-памяти ID сеанса и пользовательского ID, который соответствует ID сеанса.

В данном варианте осуществления запрос для входа пользователя содержит пароль. Этап авторизации пользовательского ID может определяться как авторизация пользовательского ID посредством авторизации пароля; тогда как в другом варианте осуществления пользовательский ID также может быть авторизован через протокол LDAP (облегченный протокол доступа к сетевому каталогу).

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

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

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

Альтернативно ID сеанса и соответствующий пользовательский ID могут быть сохранены в виде скрытого тэга (<hidden></hidden>) в локальной памяти клиента. Когда клиент генерирует запрос данных для доступа, он получает пользовательский ID в активном состоянии; из скрытого тэга в локальной памяти клиента выполняется поиск ID соответствующего сеанса, который соответствует пользовательскому ID, и он добавляется в конец URL (унифицированного указателя ресурса) запроса данных для доступа. Например, сгенерированный URL запроса данных для доступа может выглядеть как "http://www.aaa.com/index.html?sid=123456789", где "http://www.aaa.com/index.html" - исходный URL запроса данных для доступа, а "123456789" - ID сеанса.

S104, извлечение указанного ID сеанса из указанного запроса данных для доступа и получение сеанса, соответствующего указанному ID сеанса.

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

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

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

S106, назначение для полученного сеанса запроса данных для доступа.

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

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

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

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

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

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

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

В одном варианте осуществления, как показано на фиг. 3, система для сохранения состояния входа в пользовательскую учетную запись содержит: модуль 102 получения запроса для доступа, модуль 104 получения сеанса и модуль 106 назначения сеанса, при этом:

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

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

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

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

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

модуль 108 получения запроса для входа пользователя, сконфигурированный для получения запроса для входа пользователя, при этом указанный запрос для входа пользователя содержит указанный ID;

модуль 110 авторизации ID, сконфигурированный для извлечения пользовательского ID из указанного запроса для входа пользователя и авторизации указанного пользовательского ID;

модуль 112 создания сеанса, сконфигурированный для создания после успешной авторизации сеанса, соответствующего указанному пользовательскому ID; и

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

В данном варианте осуществления запрос для входа пользователя содержит пароль. Модуль ПО авторизации пользовательского ID может быть сконфигурирован для авторизации пользовательского ID посредством авторизации пароля. В другом варианте осуществления модуль ПО авторизации пользовательского ID может быть сконфигурирован для авторизации пользовательского ID через протокол LDAP (облегченный протокол доступа к сетевому каталогу).

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

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

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

Альтернативно модуль 114 внесения в кэш-память может быть сконфигурирован для сохранения ID сеанса и соответствующего пользовательского ID в виде скрытого тэга (<hidden></hidden>) в локальной памяти клиента. Когда клиент генерирует запрос данных для доступа, он получает пользовательский ID в активном состоянии; из скрытого тэга в локальной памяти клиента выполняется поиск ID соответствующего сеанса, связанного с пользовательским ID, и он добавляется в конец URL (унифицированного указателя ресурса) запроса данных для доступа. Например, сгенерированный URL запроса данных для доступа может выглядеть как "http://www.aaa.com/index.html?sid=123456789", где "http://www.aaa.com/index.html" - исходный URL запроса данных для доступа, а "123456789" - ID сеанса.

Модуль 104 получения сеанса сконфигурирован для извлечения ID сеанса из указанного запроса данных для доступа и получения сеанса, соответствующего ID сеанса.

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

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

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

Модуль 106 назначения для сеанса сконфигурирован для назначения полученного сеанса для запроса данных для доступа.

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

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

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

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

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

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

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

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

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

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

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