ПОДСИСТЕМНО-КОНТЕКСТНАЯ АРХИТЕКТУРА ДЛЯ КОМНАТ ДЛЯ РАБОТЫ В ГРУППЕ В ВИРТУАЛЬНОМ ПРОСТРАНСТВЕ Российский патент 2011 года по МПК G06F15/16 

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

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

Продукты E-Learning (электронное обучение) и "виртуальная классная комната" позволяют каждому студенту находиться в отдельной компьютерной системе, например на персональном компьютере (ПК; PC), и вместо классной комнаты встречаться в интерактивном виртуальном пространстве, часто с использованием программного обеспечения для веб-конференций, например программного продукта Live Meeting корпорации MICROSOFT. Хотя продукты E-Learning (электронное обучение) и "виртуальная классная комната" могут поддерживать сценарий "разбиения" на меньшие группы, текущее продукты E-Learning (электронное обучение) и "виртуальная классная комната", которые поддерживают эту возможность, реализуют каждую "комнату для работы в группе" как отдельную, полнофункциональную веб-конференцию (или совещание). Поскольку каждая комната (например, "главная комната" и "комнаты для работы в группе") является целой веб-конференцией, имеется некоторое количество непроизводительных затрат сервера (или службы), связанных с каждой комнатой для работы в группе. Кроме того, вход в комнату для работы в группе может представлять собой медленный процесс, поскольку он обычно требует нового соединения с сервером. Инструктору (например, докладчику на веб-конференции) может быть трудно быстро переключаться с одной комнаты для работы в группе на другую комнату для работы в группе. Аналогичным образом инструктор, желающий наблюдать за каждой комнатой, должен быть подключен к веб-конференции каждой комнаты со всеми сопутствующими непроизводительными затратами клиентской стороны. Также студенту (например, участнику веб-конференции), который находится и в главной комнате, и в комнате для работы в группе, для каждой из них требуются отдельные клиенты веб-конференций, что обычно увеличивает потребление ресурсов центрального процессора (CPU; ЦП) и памяти на персональном компьютере студента. Кроме того, отправка файла, документа или другой части информационного содержания из комнаты в комнату может являться трудной или занимать много времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПОДРОБНОЕ ОПИСАНИЕ

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

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

Термин "посетитель" относится к неуполномоченному пользователю или неуполномоченному участнику совещания.

Термин "комната для работы в группе" относится к именованному контексту.

Термин "функциональная подсистема" или "интерактивная подсистема" относится к набору функциональных возможностей, предоставляемых системой веб-конференций. Каждая функциональная подсистема реализует набор функциональных возможностей. Функциональная подсистема, которая может выражать контекстную функциональную возможность без помощи извне, рассматривается как "поддерживающая контекст", и поддерживающие контекст функциональные подсистемы могут реализовывать контекстные функциональные возможности с использованием контекстных прокси. Типичные функциональные подсистемы включают в себя, но без ограничения, чат, менеджер вопросов и ответов (Q&A), совместное использование приложений, список посетителей, совместное использование документов, обмен сообщениями через доску объявлений, передачу файлов, аудио, видео, средство просмотра слайдов, передачу голоса по Интернет-протоколу (VoIP), менеджер списка посетителей и т.п.

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

Термин "главная комната" относится к глобальному контексту.

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

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

Термин "докладчик" относится к уполномоченному пользователю или уполномоченному участнику совещания.

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

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

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

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

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

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

В некоторых вариантах воплощения система веб-конференций включает в себя менеджер контекстов, который управляет созданием и уничтожением комнат для работы в группе в пределах веб-конференции, управляет перемещением пользователей (например, участников совещания) между различными комнатами для работы в группе, включая главную комнату, и уведомляет заинтересованные стороны об этих изменениях. Менеджер контекстов может быть реализован как подсистема в пределах системы веб-конференций. Когда система веб-конференций принимает от пользователя запрос на создание совещания, система веб-конференций создает глобальный контекст, или главную комнату для совещания. В системе веб-конференций совещание может состоять из менеджера контекстов и коллекции функциональных подсистем, обусловленных функциональными возможностями, которые должны быть доступны во время совещания. Например, предполагая, что запрашивающий совещание запросил, чтобы во время совещания были доступны функциональные возможности совместного использования документов, менеджера вопросов и ответов (Q&A) и передачи файлов, совещание может состоять из экземпляров менеджера контекстов, функциональной подсистемы для совместного использования документов, функциональной подсистемы для менеджера вопросов и ответов (Q&A) и функциональной подсистемы для передачи файлов. Экземпляры функциональных подсистем, которые были созданы для совещания, наряду с привязанным к ним информационным содержанием, можно концептуально представить как главную комнату совещания. Иначе говоря, функциональные подсистемы, которые были созданы для совещания, наряду с привязанным к ним информационным содержанием, обозначают главную комнату совещания. Менеджер контекстов в пределах совещания осведомлен о каждой функциональной подсистеме совещания, и менеджер контекстов в ответ на команды создания новых комнат для работы в группе (то есть контекстов) или уничтожения существующих комнат для работы в группе (то есть контекстов) в пределах совещания выдает команды (или запросы, или события и т.д.) функциональным подсистемам совещания.

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

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

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

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

Затем менеджер контекстов может определить для каждой функциональной подсистемы информационное содержание, которое функциональная подсистема должна предоставлять через контекстный прокси. Например, докладчик, который сделал запрос комнаты для работы в группе, мог определить информационное содержание совещания, которое должно быть доступно в комнате для работы в группе. Докладчик мог определить эту информацию во время запроса на создание комнаты для работы в группе или вслед за запросом комнаты для работы в группе. Каждая функциональная подсистема на совещании в ответ предоставляет указанное информационное содержание через свой контекстный прокси, который был создан для комнаты для работы в группе. Функциональная подсистема может предоставить элемент информационного содержания посредством "маркировки" или иного указания того, что элемент информационного содержания должен быть доступен через контекстный прокси, соответствующий комнате для работы в группе. В некоторых вариантах воплощения функциональная подсистема может снабдить меткой или аннотацией каждый элемент информационного содержания с помощью метаданных, которые привязывают элемент информационного содержания к конкретному контекстному прокси или нескольким контекстным прокси. Таким образом, функциональная подсистема не должна физически перемещать или копировать информационное содержание из главной комнаты для включения информационного содержания в состав комнаты для работы в группе, и информационное содержание может быть легко перемещено из одной комнаты в другую комнату совещания. Информационное содержание также может быть легко включено в состав нескольких комнат в пределах совещания. Кроме того, посредством аннотирования каждого элемента информационного содержания функциональная подсистема может легко выделить отдельные ресурсы для каждого из своих контекстных прокси. Например, функциональная подсистема, которая предоставляет обмен сообщениями через доску объявлений, может отделить информацию о рисунках для каждой из своих комнат для работы в группе.

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

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

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

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

Фиг. 1 является высокоуровневой блок-схемой, показывающей иллюстративную среду, в которой иллюстративно работает система веб-конференций. Среда представляет собой только один пример подходящей рабочей среды и не предусматривает наложения какого-либо ограничения на объем использования или функциональность системы веб-конференций. Как изображено, среда содержит серверную компьютерную систему 102 и множество клиентских компьютерных систем 104, каждая из которых соединена с сетью 106. Серверная компьютерная система служит в качестве вычислительной платформы, на которой выполняется система 108 веб-конференций. Система веб-конференций "выступает в роли хоста" для множества веб-конференций 110 и оказывает услуги конференц-связи участникам 112 конференции или совещания. Каждый участник может исполнять клиентское приложение 114 на своей клиентской компьютерной системе для доступа к системе веб-конференций и участия в веб-конференции или в нескольких веб-конференциях. Клиенты, исполняемые на клиентских компьютерных системах, позволяют участникам на клиентских компьютерных системах взаимодействовать с системой веб-конференций. Для простоты на фиг. 1 показана только одна серверная компьютерная система, и специалист в области техники поймет, что система веб-конференций может быть распределена по нескольким серверным компьютерным системам.

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

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

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

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

Фиг. 2 является блок-схемой, которая показывает избранные компоненты веб-конференции 202 в соответствии с некоторыми вариантами воплощения. Как изображено, веб-конференция содержит менеджер 204 контекстов и множество функциональных подсистем 206. Менеджер контекстов управляет созданием, уничтожением, именованием контекста и любой информацией, относящейся к управлению функциональных подсистем, содержащихся в веб-конференции, и к контекстным прокси функциональных подсистем. Каждая функциональная подсистема обеспечивает функциональную возможность или набор функциональных возможностей, которые предоставляются в веб-конференции посредством системы веб-конференций. Функциональные подсистемы включают в себя, но без ограничения, чат, совместное использование приложений, список посетителей, совместное использование документов, обмен сообщениями через доску объявлений, передачу файлов, аудио, видео и т.д. Как изображено на фиг. 2, каждая функциональная подсистема показана привязанной ко множеству контекстных прокси 208a-c. Когда функциональной подсистеме дается команда создать комнату для работы в группе, имеющую указанный идентификатор контекста, функциональная подсистема создает контекстный прокси для самой себя. Каждый из контекстных прокси предоставляет именованное представление своей соответствующей функциональной подсистемы, и коллекция контекстных прокси, имеющих одно и то же имя или идентификатор контекста, обеспечивает отдельное представление общей модели совместно используемых данных или комнату для работы в группе в пределах веб-конференции. В качестве примера, коллекция контекстных прокси 208a входит в состав одной комнаты для работы в группе, коллекция контекстных прокси 208b входит в состав другой комнаты для работы в группе и коллекция контекстных прокси 208c входит в состав еще одной комнаты для работы в группе в пределах одной и той же веб-конференции.

Фиг. 3 является блок-схемой, которая иллюстрирует избранные компоненты функциональной подсистемы 302 в соответствии с некоторыми вариантами воплощения. Как изображено, функциональная подсистема содержит функциональный компонент 304, список 306 управления доступом (ACL) функциональной подсистемы, множество информационных содержаний 308a-n и множество контекстных прокси 312. Функциональный компонент обеспечивает функциональность, связанную с функциональной возможностью или функциональными возможностями, обеспечиваемыми функциональной подсистемой. Например, если функциональная подсистема обеспечивает возможности совместного использования файлов, функциональный компонент содержит логику, которая реализует функциональность совместного использования файлов. Список управления доступом (ACL) функциональной подсистемы определяет права доступа, которые связаны с функциональной подсистемой. Например, список управления доступом (ACL) функциональной подсистемы может определять права, которые имеет каждый участник или группа участников при взаимодействии непосредственно с функциональной подсистемой. Поскольку глобальный контекст веб-конференции состоит непосредственно из функциональных подсистем, взаимодействие с функциональной подсистемой является сходным с взаимодействием в главной комнате веб-конференции. Таким образом, список управления доступом (ACL) функциональной подсистемы определяет права участника при его участии в главной комнате веб-конференции. Информационное содержание представляет собой порцию информации, например отдельный файл, документ, ресурс и т.д., которая находится в функциональной подсистеме или связана с ней. Например, в случае функциональной подсистемы совместного использования файлов элемент информационного содержания может являться заданным файлом. В случае функциональной подсистемы менеджера вопросов и ответов (Q&A) элемент информационного содержания может являться набором вопросов и ответов. В случае функциональной подсистемы средства просмотра слайдов элемент информационного содержания может являться заданным набором слайдов. Каждый элемент информационного содержания 308a-n привязан к соответствующему списку присоединенных контекстов 310a-n. Список присоединенных контекстов представляет собой метаданные, которые определяют контексты, в состав которых включены привязанные элементы информационного содержания. В некоторых вариантах воплощения каждый элемент информационного содержания всегда включен в состав глобального контекста, даже когда элемент информационного содержания дополнительно включен в состав одного или более именованных контекстов. Каждый из контекстных прокси обеспечивает представление прокси функциональной подсистемы и функционирует как канал к именованному подмножеству информационного содержания функциональной подсистемы. Каждый контекстный прокси 312 связан с соответствующим идентификатором 314 контекста. Каждый идентификатор контекста однозначно определяет именованный контекст в пределах веб-конференции, и коллекция контекстных прокси, которые связаны с тем же самым идентификатором контекста, обеспечивает отдельное именованное представление информационного содержания веб-конференции.

Фиг. 4 является блок-схемой, которая иллюстрирует тонкий контекстный прокси 402, созданный посредством поддерживающей контекст функциональной подсистемы в соответствии с некоторыми вариантами воплощения. Тонкий контекстный прокси представляет собой проявление функциональной подсистемы в именованном контексте веб-конференции. Как изображено, тонкий контекстный прокси содержит компонент 404 фильтрации и список 406 управления доступом (ACL) прокси. Список управления доступом (ACL) прокси определяет права доступа, предоставленные участникам веб-конференции при взаимодействии через тонкий контекстный прокси. Компонент фильтрации фильтрует действия, которые запрашиваются через тонкий контекстный прокси, в соответствии с полномочиями и правами, указанными в списке управления доступом (ACL) прокси. Например, когда тонкий контекстный прокси принимает запрос на выполнение действия, компонент фильтрации проверяет запрашиваемое действие на соответствие со списком управления доступом (ACL) прокси, чтобы определить, является ли запрашиваемое действие авторизованным действием. После определения, что запрошенное действие является авторизованным действием, компонент фильтрации направляет запрашиваемое действие функциональному компоненту функциональной подсистемы для обработки действия. Тонкий контекстный прокси содержит логику фильтрации, а не реализацию функциональных возможностей.

Фиг. 5 является блок-схемой, которая иллюстрирует контекстный прокси 502, созданный функциональной подсистемой, которая не поддерживает контекст, в соответствии с некоторыми вариантами воплощения. Как изображено, контекстный прокси содержит функциональный компонент 504 и список 506 управления доступом (ACL) прокси. Список управления доступом (ACL) прокси определяет права доступа, предоставленные участникам веб-конференции при взаимодействии через контекстный прокси. Функциональный компонент представляет собой экземпляр логики, которая реализует функциональность, связанную с функциональной возможностью или функциональными возможностями, обеспечиваемыми функциональной подсистемой. Функциональный компонент обрабатывает действия, которые запрашиваются через контекстный прокси, в соответствии с полномочиями и правами, указанным в списке управления доступом (ACL) прокси. В данном случае функциональный компонент аналогичен функциональному компоненту, описанному на фиг. 4, в том, что функциональный компонент обрабатывает запрашиваемые действия.

Фиг. 6 является блок-схемой последовательности операций, показывающей иллюстративные этапы, выполняемые докладчиком совещания для создания комнаты для работы в группе в пределах совещания, в соответствии с некоторыми вариантами воплощения. В качестве примера, докладчик совещания, принимая участие в совещании, обеспечиваемом системой веб-конференций, может решить создать комнату для работы в группе в пределах совещания. На этапе 602 докладчик совещания определяет имя комнаты для работы в группе для совещания. На этапе 604 докладчик совещания определяет участников совещания для перемещения в комнату для работы в группе. Для каждого указанного участника совещания (этап 606) докладчик совещания определяет права доступа для участника совещания в пределах комнаты для работы в группе на этапе 608, пока не будут указаны права доступа для всех указанных участников совещания (этап 610). На этапе 612 докладчик совещания делает запрос на создание комнаты для работы в группе в пределах совещания. Докладчик совещания может ввести информацию, требуемую для запроса комнаты для работы в группе, через пользовательский интерфейс (UI), представленный в клиенте докладчика посредством системы веб-конференций. Функциональные возможности, которые должны быть обеспечены в комнате для работы в группе, могут быть определены из полномочий, которые указаны для каждого из участников совещания. В некоторых вариантах воплощения докладчик совещания также может явно определить функциональные возможности, которые должны быть обеспечены в комнате для работы в группе. В некоторых вариантах воплощения докладчик совещания может определить информационное содержание, которое должно быть доступно в пределах комнаты для работы в группе.

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

Фиг. 7 является блок-схемой последовательности операций, которая иллюстрирует обработку менеджера контекстов для создания комнаты для работы в группе в соответствии с некоторыми вариантами воплощения. На этапе 702 компонент менеджера контекстов совещания принимает запрос на создание комнаты для работы в группе в пределах совещания. На этапе 704 менеджер контекстов осуществляет проверку для определения, уполномочен ли пользователь, который запросил создание комнаты для работы в группе, создавать комнату для работы в группе. Если пользователь не уполномочен создавать комнату для работы в группе, то на этапе 706 менеджер контекстов сообщает об ошибке. В ином случае, если пользователь, который запросил создание комнаты для работы в группе, уполномочен создавать комнату для работы в группе, то на этапе 708 менеджер контекстов дает каждой функциональной подсистеме в совещании команду создать контекстный прокси с указанным именем. Указанное имя может являться именем комнаты для работы в группе, которое определено запрашивающим комнату для работы в группе. В некоторых вариантах воплощения менеджер контекстов может создать идентификатор контекста, который однозначно определяет запрашиваемую комнату для работы в группе в пределах совещания, привязывает идентификатор контекста к имени комнаты для работы в группе и дает каждой функциональной подсистеме совещания команду создать контекстный прокси и идентифицировать контекстный прокси с помощью идентификатора контекста.

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

Затем для каждой функциональной подсистемы совещания (этап 718) менеджер контекстов выполняет этапы 720-722, пока не будут обработаны все функциональные подсистемы совещания (этап 722). На этапе 720 менеджер контекстов информирует функциональную подсистему об участниках, которые должны принять участие через контекстный прокси, предоставленный функциональной подсистемой. На этапе 722 менеджер контекстов информирует функциональную подсистему о правах доступа каждого участника при его участии через контекстный прокси. Специалист в области техники поймет, что в зависимости от прав доступа, определенных пользователем, который запросил комнату для работы в группе, одна или более функциональных подсистем может не иметь участников, принимающих участие через ее контекстный прокси. Это позволяет комнате для работы в группе не предлагать функциональную возможность или функциональные возможности, которые предлагаются в главной комнате совещания. На этапе 726 менеджер контекстов информирует каждого из участников, которые были закреплены за комнатой для работы в группе, о закреплении за комнатой для работы в группе. В некоторых вариантах воплощения менеджер контекстов может обеспечить индикацию о закреплении за комнатой для работы в группе клиенту участника, и клиент может отобразить пользовательский интерфейс (UI), который содержит индикацию относительно закрепления участника за комнатой для работы в группе. Отображаемый пользовательский интерфейс (UI) также может обеспечить интерфейс, через который участник может работать в комнате для работы в группе.

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

Фиг. 8 является блок-схемой последовательности операций, которая иллюстрирует обработку функциональной подсистемы для создания контекстного прокси в соответствии с некоторыми вариантами воплощения. На этапе 802 функциональная подсистема принимает указание для создания контекстного прокси. На этапе 804 функциональная подсистема создает запрашиваемый контекстный прокси. На этапе 806 функциональная подсистема осуществляет проверку для определения, смогла ли она успешно создать контекстный прокси. Если функциональная подсистема не смогла успешно создать контекстный прокси, то на этапе 808 функциональная подсистема сообщает об ошибке. Например, функциональная подсистема может возвратить сообщение об ошибке менеджеру контекстов, информируя менеджера контекстов о неудачном создании запрашиваемого контекстного прокси. В ином случае, если функциональная подсистема смогла успешно создать контекстный прокси, то на этапе 810 функциональная подсистема связывает имя с созданным контекстным прокси. Имя может являться именем комнаты для работы в группе, представленной контекстным прокси. На этапе 812 функциональная подсистема сообщает об успешном создании запрашиваемого контекстного прокси, например, менеджеру контекстов.

Фиг. 9 является блок-схемой последовательности операций, которая иллюстрирует обработку функциональной подсистемы для привязки участников совещания к комнате для работы в группе в соответствии с некоторыми вариантами воплощения. На этапе 902 функциональная подсистема принимает информацию об участниках совещания, которые должны принять участие через контекстный прокси. На этапе 904 функциональная подсистема принимает информацию о правах доступа каждого участника, когда он принимает участие через контекстный прокси. На этапе 906 функциональная подсистема создает список управления доступом (ACL) прокси для контекстного прокси. В некоторых вариантах воплощения функциональная подсистема привязывает элемент или элементы информационного содержания к контекстному прокси. Например, для каждого элемента информационного содержания, который определен как доступный через контекстный прокси, функциональная подсистема может включить в список присоединенных контекстов каждого элемента информационного содержания индикацию контекста, представленного контекстным прокси. В некоторых вариантах воплощения для каждого участника, закрепленного за комнатой для работы в группе, функциональная подсистема соединяет клиент участника с контекстным прокси, который был создан функциональной подсистемой для комнаты для работы в группе.

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

На этапе 1008 функциональная подсистема информирует участников о перемещении из комнаты для работы в группе. В некоторых вариантах воплощения функциональная подсистема может предоставить индикацию о перемещении участника из комнаты для работы в группе клиенту участника. Затем клиент может предоставить индикацию о перемещении из комнаты для работы в группе и удалить или больше не отображать пользовательский интерфейс (UI), который позволял участнику работать в комнате для работы в группе. Клиент может отобразить или повторно отобразить пользовательский интерфейс (UI) для главной комнаты веб-конференции. На этапе 1010 функциональная подсистема перемещает все информационное содержание, которое привязано к комнате для работы в группе, в главную комнату совещания. Например, для каждого элемента информационного содержания, который привязан к комнате для работы в группе, функциональная подсистема может удалить из своего списка присоединенных контекстов индикацию контекста, который должен быть уничтожен (например, комнату для работы в группе), и включить в список присоединенных контекстов индикацию глобального контекста (например, главной комнаты), если она там уже не присутствует. На этапе 1012 функциональная подсистема уничтожает комнату для работы в группе. Например, функциональная подсистема уничтожает контекстный прокси, который функциональная подсистема создала для комнаты для работы в группе.

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

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

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

2. Способ по п.1, в котором, по меньшей мере, один из первых контекстных прокси является тонким контекстным прокси.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18. Машиночитаемый носитель по п.16, содержащий создание списка управления доступом (ACL) для каждого из контекстных прокси, причем ACL определяет права доступа для участников совещания, которые взаимодействуют через его соответствующий контекстный прокси.

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