Отображение обнаруженных элементов универсального режима "подключай и работай" на местоположение smb

Отображение обнаруженных элементов универсального режима "подключай и работай" на местоположение smb

Иллюстрации

Показать все

Реферат

С добавлением способностей «подключай и работай» уровня устройства стало намного легче устанавливать, настраивать и добавлять периферийные устройства к потребительским электронным устройствам и персональным компьютерам (ПК). Универсальный режим «подключай и работай» (Universal Plug and Play, UPnP™) расширяет эту простоту до включения целой сети, позволяя обнаруживать и управлять сетевыми устройствами и службами, такими как принтеры, подключенные в сеть, Интернет-шлюзы и клиентское электронное оборудование. Сетевые протоколы UPnP обнародуются UPnP Форумом, который является промышленным проектом, разработанным для обеспечения возможности простого и устойчивого соединения между автономными устройствами и ПК от многих различных производителей.

UPnP - это больше, чем простое расширение периферийной модели режима «подключай и работай». Он разработан для поддержки конфигурации по умолчанию, «невидимого» присутствия в сети и автоматического обнаружения для множества категорий устройств от широкого спектра производителей. С использованием UPnP устройство может динамически подсоединяться к сети, получать адрес Интернет-протокола (IP), предоставлять свои способности и распознавать присутствие и способности других устройств все автоматически для облегчения, таким образом, конструкции сетей конфигурации по умолчанию. Устройства могут затем сообщаться друг с другом напрямую, используя сеть с равноправными узлами, чтобы получать доступ и совместно использовать содержимое.

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

UPnP является распределенной, открытой архитектурой сети, которая независима от любых конкретных операционных систем, языков программирования или физических сред. Однако UPnP использует стандартные протоколы, такие как TCP/IP, HTTP и XML, которые позволяют легко вписываться в существующие сети. Использование таких стандартизированных протоколов позволяет UPnP выигрывать от возможности совместной работы в качестве характерной особенности.

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

После того как желаемый объект содержимого обнаружен, например, с использованием ресурса или тега <res> в документе XML, удаленное устройство использует информацию транспортного протокола от службы каталогов содержимого для сопоставления его со способностями медиаплеера в удаленном устройстве. Общие транспортные протоколы включают, например, HTTP GET и RTSP/RTP (потоковый протокол реального времени/транспортный протокол реального времени). Переданное содержимое затем воспроизводится удаленным устройством при использовании другой службы UPnP (служба управления передачей AV), или не-UPnP внеполосного протокола, для управления потоком содержимого (например, стоп, ускоренная перемотка вперед, обратная перемотка, пауза и др.)

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

Сущность изобретения

Обеспечивается решение, в котором UPnP устройство показывает службу для отображения UPnP обнаруженного элемента содержимого на местоположение блока серверных сообщений (SMB). Служба выполнена с возможностью показывать путь совместного использования SMB запрашиваемому пользователю на удаленном клиенте с использованием протокола UPnP. Затем пользователю разрешается доступ к файлам совместного пользования посредством протокола SMB для получения доступа к файлам, записи изменений или осуществления управления на уровне файла для обнаруженного элемента содержимого. Аутентификация, если требуется, используется для подтверждения того, что пользователь авторизован для получения местоположения совместного пользования SMB от службы, или подтверждения того, что пользователь авторизован для доступа к совместному пользованию SMB. Предложенное решение направлено на упрощение структуры и работы вычислительных сетей при использовании универсального режима «подключай и работай» (UPnP).

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

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

Краткое описание чертежей

Фиг.1 - графическое представление иллюстративной домашней сети, которая выполнена с возможностью использования UPnP;

Фиг.2 - блок-схема иллюстративной архитектуры сервера и клиента;

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

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

Фиг.5 - иллюстративный документ XML, который включает в себя <res> тег, который включает в себя путь SMB;

Фиг.6 - диаграмма иллюстративного способа для обеспечения службы каталогов содержимого запрашивающему пользователю;

Фиг.7 - диаграмма иллюстративного способа для идентификации и показа местоположения совместного использования SMB запрашивающему пользователю;

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

Фиг.9 - схема иллюстративного представления потока сообщений между сервером SMB и клиентом SMB.

Раскрытие изобретения

На чертежах сходные компоненты или элементы обозначены одинаковыми ссылочными позициями. На фиг.1 приведено наглядное представление дома (100), в котором различные устройства связаны с домашней сетью (102). В рабочем кабинете (105) дома (100) на ПК (110) хранятся семейные фотографии. Второй ПК (116) расположен в гостиной (123) и связан с телевизором (128) с большим экраном. Игровая консоль (132) расположена в спальне (136). ПК (110), ПК (116) и игровая консоль (132) связаны, соответственно, с домашней сетью (102), которая, в этом представленном примере, выполнена как сеть UPnP. Сети UPnP могут быть выполнены с помощью разнообразных сетевых сред, включающих в себя, например, телефонную линию, линию электропередач, Ethernet, беспроводную радиочастотную среду и среду IEEE 1394.

Используя настоящее решение для отображения обнаруженных элементов UPnP на местоположение SMB, семья может собираться в гостиной комнате (123) и смотреть фотографии, хранящиеся на ПК (110), на телевизоре (128) с большим экраном. Используя ПК (116), семья может оценивать фотографии, менять их и даже переименовывать из гостиной комнаты (123). Эти возможности доступны при использовании свойства просмотра UPnP и HTTP при добавлении файловых операций через SMB в соответствии с настоящим решением. Иллюстративная семейная фотография хранится на ПК (110) и передается как картинка 150А на монитор, связанный с ПК (110), картинка 150В - на телевизор (128) с большим экраном, и картинка 150С - на монитор, связанный с игровой консолью (132), как показано на Фиг.1.

SMB - это протокол совместного использования сетевых файлов на уровне приложения/представления в сетевой модели OSI (взаимосвязи открытых систем). Соответственно, SMB может исполняться на множестве протоколов нижних уровней, включающих, например, NetBIOS (сетевая базовая система ввода-вывода) через TCP/IP, NetBEUI (расширенный пользовательский интерфейс NetBIOS) или IPX/SPX (межсетевой пакетный обмен/упорядоченный пакетный обмен).

Набор пакетов сообщений, который определяет конкретный вариант протокола SMB, называется диалектом. Например, CIFS (общая межсетевая файловая система) относится к диалекту SMB, который был первым реализован в операционной системе Microsoft Windows NT. SMB и CIFS также доступны в VMS (система виртуальной памяти), нескольких версиях Unix и других операционных системах. Все диалекты SMB, включая CIFS, могут использоваться в настоящем решении, и конкретная версия SMB или выбранный диалект будут зависеть от конкретных требований программы приложения для отображения обнаруженного содержания UPnP. Термин SMB, используемый здесь, предназначен для обращения ко всем таким версиям SMB или диалектам.

Фиг.2 - это блок-схема иллюстративной архитектуры 200 сервера и клиента, включая серверное устройство 205 и клиентское устройство 212, каждое из которых, как правило, сконфигурировано как физическое устройство или компонент, такой как ПК, игровая консоль и т.д. Например, серверное устройство 205 может быть подсоединено в ПК 110 (фиг.1) для совместного использования элементов содержимого, хранящихся там, таких как семейные фотографии, музыка, игры, данные, файлы и тому подобное. Подобным образом клиентское устройство 212 может быть встроено в ПК 116 (фиг.1) или игровую консоль (фиг.1), чтобы принимать элементы содержимого от серверного устройства 205.

Серверное устройство 205 и клиентское устройство 212 взаимодействуют через медиа-серверное UPnP устройство 222 и UPnP устройство 228 медиа-воспроизведения соответственно. UPnP устройства - это логические устройства, которые не должны отражать конкретную физическую установку. Это значит, что физическое устройство может содержать несколько логических UPnP устройств и конкретное количество выбранных UPnP устройств, и их размещение будет зависеть от требований конкретной программы приложения для отображения обнаруженных элементов UPnP. В добавление к медиа-серверному UPnP устройству 222, серверное устройство включает сервер 231 SMB, который выполнен с возможностью осуществления связи с клиентом 235 SMB в клиентском устройстве 212 через сеть, как показано линией 238.

Медиа-серверное UPnP устройство 222 включает в себя службу 240 каталогов содержимого, устроенную обычно как Служба Каталогов Содержимого, соответствующая опубликованным UPnP форумом определениям, которая расширяется дополнительными функциями, описанными ниже. Альтернативно служба 240 каталогов содержимого выполняется как новая служба (именуемая, например, SecureContentDirectoryService»), то есть доступная для запросов клиентов с использованием существующих UPnP протоколов.

UPnP устройство 228 медиа-воспроизведения включает в себя пункт 251 управления. В этом иллюстративном примере пункт 251 управления является UPnP пунктом управления, встроенным в UPnP устройство 228 медиа-воспроизведения, которое активизирует действия в службах, обеспечивая требуемые входные параметры и получая выходные параметры, ответы службы и возвращаемые значения. UPnP устройство 228 медиа-воспроизведения обычно выполнено как устройство медиа-воспроизведения, соответствующее опубликованным UPnP форумом определениям, которое реализует клиентское устройство 212 с возможностью воспроизводить элементы содержимого, полученные от серверного устройства 205. UPnP устройство 228 медиа-воспроизведения обычно конфигурируется, чтобы обнаружить набор элементов управления визуализацией, причем пункт 251 управления может управлять тем, как отдельный элемент содержимого визуализируется. В альтернативных решениях отображения обнаруженных элементов UPnP на местоположение SMB UPnP устройство 228 медиа-воспроизведения факультативно используется в ситуациях, где серверное устройство 205 и клиентское устройство 212 взаимодействуют друг с другом, используя не-UPnP (т.е внеполосные) протоколы коммуникации. Например, Windows® Media Player и Roku™ SoundBridge могут быть использованы для визуализации элементов содержимого.

В архитектуре 200 сервер-клиент пункт 251 управления обращается к службе 240 каталогов содержимого через UPnP сеть, как обозначено линией 260, как показано на фиг.2.

Фиг.3 - это схема, показывающая иллюстративный поток сообщений между службой 240 каталогов содержимого и пунктом 251 управления. Пункт 251 управления используется, чтобы выявить другие устройства в UPnP сети, такой как домашняя сеть 102 (фиг.1), путем отправки сообщения обнаружения 303, обычно команды M-Search, используя SSDP (простой протокол обнаружения службы). Служба 240 каталогов содержимого реагирует на команду M-search, используя SSDP сообщение, которое содержит URI (Универсальный код ресурса) документов описания устройства формата XML, которые, в свою очередь, содержат местоположение XML документов 306 описания службы для каждой доступной службы. Пункт 251 управления может загружать документы 306 описания службы, например, посредством HTTP. Медиа-серверное UPnP устройство 222, таким образом, может показывать службу 240 каталогов содержимого пункту 251 управления.

Фиг.4 - это схема, показывающая другой иллюстративный поток сообщений между службой 240 каталогов содержимого и пунктом 251 управления. Пункт 251 управления подсоединяется к службе 240 каталогов содержимого, используя протокол аутентификации, такой как Windows Negotiate, Kerberos, NTLM или т.п. Использование процесса аутентификации необязательно (что обозначено пунктирной линией 406 на фиг.4). Если согласование аутентификации между службой 240 каталогов содержимого и пунктом 251 управления прошло успешно, пункт 251 управления может формировать команды поиска и просмотра службы 240 каталогов содержимого, используя SOAP сообщения 413 посредством HTTP. Служба 240 каталогов содержимого реагирует на команды поиска и просмотра XML документом 418, который показывает запись <res> тега, обычно среди других записей, для обнаруженных элементов содержимого, которые отображены на местоположения SMB. Отображение описано ниже в тексте, относящемся к фиг.6-8.

Фиг.5 - это иллюстративный XML документ 418, который включает в себя <res> тег 505, включающий в себя путь SMB. Путь SMB указывается в <res> теге 505 как

\\10.194.65.100\toby\JC-myhorsenamedblue.wma

который в этом иллюстративном примере указывает файл Windows Media Audio (WMA), находящийся в совместном использовании, именованном «Toby» на ПК 110 на фиг.1, который имеет IP адрес 10.194.65.100. WMA файл относится к песне под названием «My Horse Named Blue», которая исполняется Johnny Cowboy (где и песня, и исполнитель являются вымышленными). Пути SMB для других типов файлов, таких как изображения (например, JPEG форматированные изображения с расширением файла .JPG или .JPEG) или видео (например, Windows Media Video, RealVideo, Apple QuickeTime и др, форматированные видео с расширением файла .wmv, .rm или .ram и .mov соответственно), могут быть включены в один или более <res> тегов в схожей манере.

XML документ 418 также включает в себя <res> тег 510, который обозначает URL для WMA файла, который доступен, например, с использованием HTTP GET, как обеспечивается существующим UPnP Медиа-серверным устройством. URL указывается в <res> теге 510 как

http://10.194.65.100:10243/WMPNSSv3/847081666/2 e0EyMzhEQzg5LTREMkItNDFFOS1BREE0LTdFQUE2MURERjREM30uMC5FRDAzQjJBMw.wma

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

Фиг.6 - это графическое представление иллюстративного способа 600 для UPnP устройства (такого как медиа-серверное UPnP устройство 222 на фиг.2) для показа его элементов содержимого посредством службы каталогов содержимого (такой как служба 240 каталогов содержимого на фиг.2) запрашивающему пользователю. Запрашивающий пользователь обычно является пользователем размещенного в удалении электронного устройства, такого как клиентское устройство 212, UPnP устройство 228 медиа-воспроизведения на фиг.2. Иллюстративный способ 600 начинается на этапе 605. На этапе 612 сообщение обнаружения, такое как команда M-Search, отправляется из пункта 251 управления (Фиг.2) для ведения поиска UPnP устройств, представляющих интерес, и принимается медиа-серверным UPnP устройством 222. Медиа-серверное UPnP устройство 222 отвечает на сообщение обнаружения, разрешая, таким образом, медиа-серверному UPnP устройству 222 и службе 240 каталогов содержимого обнаруживаться клиентским устройством 212, как показано на этапе 615. Служба 240 каталогов содержимого показывает элементы содержимого запрашивающему пользователю на этапе 618, чтобы обеспечить различные представления хранящегося содержимого, чтобы, таким образом, обеспечивать возможность поиска и просмотра доступных элементов содержимого. Используя детальные описания содержимого, поисковый запрос может вернуть набор элементов содержимого. Дополнительно, организация содержимого поддерживается посредством контейнеров, которые могут быть использованы для объединения в группы содержимого, сходного с каталогами или папками. Иллюстративный способ 600 заканчивается на этапе 627.

Фиг.7 - это графическое представление иллюстративного способа 700 для идентификации и показа местоположения совместного пользования SMB запрашивающему пользователю, используя службу каталогов содержимого, представленную в способе 600 (фиг.6) выше. Служба SecureContentDirectory, упомянутая выше, используется для представления способа 700. Альтернативно, существующая служба каталогов содержимого UPnP может быть расширена для выполнения этапов, показанных на фиг 7.

Иллюстративный способ начинается на этапе 702. На этапе 711 служба каталогов содержимого получает команду поиска или просмотра от запрашивающего пользователя. Необязательный этап аутентификации представлен в блоке 715. Протокол аутентификации выбран из одного из Windows Negotiate, Kerberos, NTLM или т.п. в большинстве приложений.

Служба каталогов содержимого работает для отображения элементов содержимого, запрашиваемых в командах поиска или просмотра на этапе способа, показанном в блоке 711, по наилучшему пути SMB. Под «наилучшим» в основном подразумевается наиболее прямой путь SMB, к которому определенный запрашиваемый пользователь имеет доступ.

Концепция наилучшего пути SMB далее проиллюстрирована на фиг.8, которая является блок-схемой иллюстративного репозитария 800 содержимого, показывающего содержащуюся в нем структуру 811 каталогов. Репозитарий 800 содержимого обычно воплощается как память, такая как накопитель на жестком диске в устройстве, таком как ПК 110 на фиг.1. Как показано на фиг.8, структура 811 каталогов включает три области общего пользования 815, 822 и 825. В иллюстрированном примере имеется три пользователя ПК 110, включая Admin, Dad и Toby. Удаленный пользователь хочет получить доступ к с:\home\toby, таким образом, будет иметься три потенциальных способа доступа к файлу через каждую из соответствующих областей 815, 822 и 825 совместного пользования. Admin имеет доступ к каждой из областей 815, 822 и 825 совместного пользования, в то же время Dad имеет доступ как к области 822 Home, так и к области 825 Toby. Таким образом, чтобы определить наилучший путь SMB блока системных сообщений для показа, путь UNC (Универсальное соглашение об именах) определяется, основываясь на файле, содержащемся в запросе, и данных запрашивающего пользователя.

Если Toby запрашивает файл в области совместного пользования Toby, единственный доступный и наилучший UNC путь показа это \\server\toby\filename.

Если Dad хочет получить доступ к тому же файлу, то есть два варианта, основанных на уровне доступа Dad:

А. \\server\toby\filename

В. \\server\home\toby\filename

В этом примере вариант А - это наилучший вариант, потому что он представляет наиболее прямой путь. Служба медиа-сервера соответственно выбирает \\server\toby\filename как наилучший путь SMB, если Dad является запрашивающим пользователем.

Если Admin запрашивает доступ, то имеется три варианта:

A. \\server\toby\filename

В. \\server\home\toby\filename

С. \\server\c$\home\toby\filename

В этом примере вариант А - снова наилучший вариант, потому что он представляет наиболее прямой путь. Служба медиа-сервера, таким образом, выбирает \\server\toby\filename как наилучший путь SMB, если Admin является запрашивающим пользователем.

Согласно фиг.7 служба медиа-сервера играет роль запрашивающего пользователя, используя данные запрашивающего пользователя на этапе 721. На этапе 726 служба медиа-сервера, используя локальный путь к запрошенному файлу и действуя в качестве запрашивающего пользователя, вызывает оболочку API (интерфейс прикладных программ), запрашивая наилучший путь SMB к запрашиваемому файлу. Если оболочка API возвращает путь SMB, служба медиа-сервера будет включать этот путь в <res> тег, включенный в XML ответ на команду поиска или просмотра запрашивающего пользователя, как показано на этапе 731. Иллюстрированный способ 700 завершается на этапе 740.

На фиг.9 представлена диаграмма, показывающая иллюстрированный поток сообщений между сервером 231 (фиг.2) SMB и клиентом 235 (фиг.2) SMB. Иллюстративные сообщения содержат пакеты, которые обмениваются между сервером 231 SMB и клиентом 235 SMB, используя протокол SMB, после того как служба медиа-сервера показывает путь SMB запрашивающему пользователю, как описано выше.

В этом иллюстративном примере клиент 235 SMB и сервер 231 SMB сначала устанавливают полнодуплексное TCP-соединение. Затем клиент 235 SMB формирует и посылает пакет запроса сеанса NetBIOS через TCP-соединение. Если пакет был отформатирован правильно, сервер 231 SMB возвращает пакет, который содержит сообщение, подтверждающее, что сессия установлена. После этого клиент 235 SMB посылает сообщение 905 протокола согласования серверу 231 SMB, чтобы согласовать определенный диалект SMB, используемый для сессии.

Сервер 231 SMB отвечает на запрос от клиента 235 SMB, чтобы определить диалект SMB, который будет использоваться в сессии. Возвращенное сообщение 912 также включает 8-битную случайную строку, которая будет использоваться как вызов, как часть факультативного процесса аутентификации совместно используемого ключа. Клиент 235 SMB возвращает ответ на вызов в сообщении 916, которое включает информацию, касающуюся возможностей клиента 235 SMB. Как упомянуто выше, аутентификация является дополнительным процессом, который обозначен на фиг.9 пунктирной линией.

Если сервер 231 SMB принимает ответ от клиента 235 SMB на вызов, действительный UID (пользовательский ID) включается в сообщение 918, которое возвращается клиенту 235 SMB. Если оно не принимается, сервер 231 SMB возвращает код ошибки в этом сообщении и отказывает в доступе.

Клиент 235 SMB затем запрашивает доступ к совместному использованию SMB, содержащемуся в <res> теге, представленном службой медиа-сервера, как описано выше. Сообщение 922 запроса доступа содержит полный заданный путь совместного использования в формате UNC.

Если доступ к совместному использованию получен, то сервер 231 SMB возвращает 16-битный ID дерева (TID), который соответствует совместному использованию в сообщении 927. Если совместное использование не существует или пользователь имеет недостаточные данные для доступа к совместному использованию, сервер будет возвращать код ошибки в сообщении 927 и отказывать в доступе.

Клиент 235 SMB запрашивает сервер SMB открыть файл в доступном совместном использовании в сообщении 931. Это сообщение содержит имя файла, который должен быть открыт. Например, согласно фиг.5 имя файла, который должен быть открыт, JC-ahorsenamedblue.wma.

Согласно фиг.9 если доступ к файлу получен, то сервер 231 SMB возвращает ID файла для запрашиваемого файла в сообщении 935. Если файл не существует или пользователь имеет недостаточные данные для доступа к файлу, сервер 231 SMB будет возвращать код ошибки в сообщении 935 и отказывать в доступе к файлу.

Клиент 235 SMB запрашивает сервер 231 SMB различным образом открыть файл, прочитать данные из открытого файла и возвратить эти данные клиенту 235 SMB, записать в файл или закрыть файл в сообщении 942. Другие файловые операции, включающие переименование, удаление и т.д., могут также быть включены в сообщение 942. ID файла, который получен клиентом, когда файл был открыт, включается в это сообщение для идентификации, из какого открытого файла сервер 231 SMB должен выполнить запрошенную операцию. Соответствующие ответы на сообщение 942 содержатся в сообщении 948 от сервера 231 SMB клиенту 235 SMB.

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

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

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

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

4. Способ по п.1, в котором обнаруживаемый объект содержит один или более дискретных компонентов данных медиа-содержимого, выбранных из одного из музыки, видео, изображений, игр, новостей или данных.