The present invention generally relates to current Universal Plug and Play (UPnP) audio visual (AV) media server specifications. In particular, the present invention relates to the implementation of a storage capacity query for querying the remaining storage capacity of a media server device that is hosting a content directory service.
This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The Digital Living Network Alliance (DLNA) is an industry association that focuses on developing design guidelines to enable interoperability between various wired and wireless devices on a network(s). UPnP is one of the technical cornerstones of the DLNA. UPnP itself, is a set of computer network protocols promulgated by the UPnP Forum. UPnP technology defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP technology further provides a distributed, open networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices.
The UPnP Device Architecture (UDA) is designed to support zero-configuration, “invisible” networking, and automatic discovery for a breadth of device categories from a wide range of vendors. Therefore, a UPnP device can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices on the network. To accomplish this, each UPnP device must have a Dynamic Host Configuration Protocol (DHCP) client and search for a DHCP server when the device first connects to the network. If no DHCP server is available, the device can assign itself an IP address. Once an IP address has been established, an exchange of discovery messages between the device and a control point occurs. The discovery messages utilizes a UPnP discovery protocol, which allows the device to advertise its services on the network, and a control point (CP) to seek those devices on the network that are of interest to the CP.
After the device has been discovered by a CP, the CP must retrieve a device description from a URL provided in the discovery message sent by the device. The device description can include anything from a list of embedded devices to services, as well as a list of commands or actions to which a certain service provided by the device responds to. Once the description is retrieved by the CP, the CP can send suitable control messages to interact with the service, to which the service responds by sending action-specific values that describe a run-time state of the service.
The next process in UPnP networking is event notification, or “eventing.” A UPnP description for a service includes a list of actions the service responds to and a list of variables that model the state of the service at run time. The service publishes updates when these variables change, and a CP may subscribe to receive this information. The service publishes updates by sending event messages that contain the names of one or more state variables and the current value of those variables.
The final step is presentation, which allows a user to control the device and/or view the status of the device. For example, if the device has a URL for presentation, the control point can retrieve a page from this URL, load the page into a Web browser, and present the page to the user.
UPnP defines device control protocols for a number of device categories on top of the UDA. These device control protocols define the services and their actions and state variables that the device in question offers for other peers in the UPnP network as described above. UPnP AV defines the device control protocol (DCP) for AV devices. Three components required by UPnP AV are a CP, a media server device (MSD), and a media renderer device (MRD).
Current UPnP AV media server specification define a versatile set of actions for searching, manipulating (e.g., create, delete and update) objects in the content directory service (CDS) portion of a MSD as well as importing and exporting content to/from the CDS. However, the media server specification does not include an action (or state variable) for querying the remaining storage capacity of the media server device hosting the CDS. Therefore, it is impossible for the CP to query the remaining free capacity prior to, e.g., starting a copy or move operation of a big chunk of data to the MSD. This may lead to an interruption in the copy operation due to insufficient storage capacity. This is frustrating from user's point of view, because such an operation should never be started if it is doomed to fail.
The present invention comprises a system and method for determining the remaining free storage capacity of a media database in a MSD, such as one used in a UPnP AV architecture. In one embodiment of the present invention, a CP queries the CDS of an MSD as to the remaining free storage space on the media database contained within the MSD. The CDS can query the MSD file system/OS to determine this capacity information and forward the capacity information back to the CP. This is accomplished by simply adding a new query action to the MSD service description, and implementing the query action in the CDS operational software. In a second embodiment, the query is implemented as a dedicated AV MSD service. In a third embodiment, UPnP eventing and a new state variable capable of indicating the remaining free storage capacity is used.
The various embodiments of the present invention allow a user of an MSD, MRD, or UPnP network to determine whether or not any free remaining storage capacity is left on the MSD before or after, copying or moving AV content onto that MSD. This is also advantageous for a user when programming the recording of a live event or content, as live recordings can result in large-sized files. In either case, a query to determine the remaining free storage on the MSD makes it possible to predetermine whether the copy, move, or recording operation will succeed or fail. This minimizes the risk of wasted time in beginning a copy, move, or recording, only to have the action fail before completion. Furthermore, the implementations of the various embodiments of the present invention ensure backward compatibility with earlier AV MSDs because the query action is implemented as simply a new action option.
These and other advantages and features of the invention, together with the organization and manner of operation thereof, will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein like elements have like numerals throughout the several drawings described below.
Referring to
The CP device 330 having a CP 335, uses a UPnP discovery service such as simple service discovery protocol (SSDP), or a similarly based protocol, to discover the MSD 305 and the MRD 350. Once the CP 335 discovers the MSD 305 and the MRD 350 on the UPnP network 300, the CP 335 works in conjunction with the MSD 305 to discover AV content stored in the media database 310, and with the MRD 350 to present some type of user interface that allow a user to browse for AV content and control AV content rendered on the MRD 350. Specifically, the CP 335, uses the CDS 315 of the MSD 305 to locate certain desired AV content. The CDS 315 allows searching and browsing of the AV content stored in the media database 310 by, for example, the artist of a song or the name of a video. Each item of AV content has information regarding that content, such as the transfer protocol the MSD 305 can use to transport the AV content to the MRD 350.
The MRD 350 is any device capable of actually rendering or playing back AV content, such as MPEG-4 formatted video, MP3 formatted audio, and JPEG formatted photos. Like the MSD 305, the MRD 350 also utilizes an AV transport service 355 and a connection manager service 360. Once the desired content has been discovered by the CP 335, the CP 335 compares the transfer protocol and format obtained from the CDS 315 of the MSD 305 and the connection manager service 360 of the MRD 350. Depending on what transfer protocol is chosen, the respective connection manager services 325 and 360 of the MSD 305 and the MRD 350 will establish an AV transport service, 320 and 355, respectively to control the transfer of the AV content from the MSD 305 to the MRD 350.
It should be noted that depending on the type of transfer protocol selected, an AV transport service may or may not be needed. Examples of possible transfer protocols that can be used are HTTP GET, real time streaming protocol (RTSP)/real time transport protocol (RTP), Institute of Electrical and Electronics Engineers (IEEE)-1394. Therefore, the actual transfer of AV content can occur between the MSD 305 and the MRD 350 and does not necessarily involve the UPnP network 300. In addition, the MRD 350 also utilizes a rendering control 365 to allow for the actual rendering of the AV content for presentation on an output, such as a speaker or TV, although the flow of the AV content from the MSD 305 and the MRD 350 can be controlled by the CP 335. This includes playing, fast-forwarding, rewinding, seeking, etc. of the AV content.
In a second embodiment, the query action is implemented as a dedicated AV media server service instead of another selectable action or option available to a user of the UPnP network 300 or the MSD 305. The procedures allowing the remaining free storage capacity to be queried are similar to those already described, except that the query action itself would be implemented outside of the CDS 315. Therefore, a new service, e.g., “Free_Capacity_Service” is defined to perform at least one action to query the remaining free storage capacity of the media database 310.
In a third embodiment, UPnP eventing and a state variable to indicate the remaining free storage capacity is used to inform a user of the capacity information of the media database 310. A new state variable, e.g., “Remaining_Free_Storage_Capacity” is defined in the service description file of the CDS 315. The CP 335 subscribes to an event that indicates, for example, when a predefined lower limit is reached or passed. It should be noted that the predefined lower limit can be defined in the event subscription. The CDS 315 monitors the remaining free storage capacity of the media database 310, and compares it to the predefined lower limit, which is given as an argument. When the remaining free storage capacity of the media database 310 reaches or passes the predefined lower limit, the CDS 315 will send an event to the CP 335 indicating this condition. It should further be noted that the eventing mechanism utilized has been defined in the UPnP DA v1.0.
The present invention is described in the general context of method steps, which may be implemented in one embodiment by a program product including computer-executable instructions, such as program code, executed by computers in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
Software and web implementations of the present invention could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps. It should also be noted that the words “component” and “module,” as used herein and in the claims, is intended to encompass implementations using one or more lines of software code, and/or hardware implementations, and/or equipment for receiving manual inputs.
The foregoing description of embodiments of the present invention have been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the present invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the present invention. The embodiments were chosen and described in order to explain the principles of the present invention and its practical application to enable one skilled in the art to utilize the present invention in various embodiments and with various modifications as are suited to the particular use contemplated.