GB2571705A

GB2571705A - File serving

Info

Publication number: GB2571705A
Application number: GB1802995.9A
Authority: GB
Inventors: Wolff Daniel
Original assignee: Universal Music Operations Ltd
Current assignee: Universal Music Operations Ltd
Priority date: 2018-02-23
Filing date: 2018-02-23
Publication date: 2019-09-11
Also published as: GB201802995D0

Abstract

A media server comprising: a memory storing a plurality of media files; a processor; and a data output; the processor being configured to receive an indication of a subset of the media files, and to, in response to that command, represent over the data output a mass storage device whose root level contains the files of the subset. If the memory comprise a root level and one or more sub levels hierarchically below the root level, at least some of the files of the subset may be stored in a sub level. The media server may comprise a physical interface separate from the data output, the processor may be configured to receive the said command over that physical interface. The physical interface may be a wireless interface. The root level may be that of a virtual or emulated root level or directory.

Description

(57) A media server comprising: a memory storing a plurality of media files; a processor; and a data output; the processor being configured to receive an indication of a subset of the media files, and to, in response to that command, represent over the data output a mass storage device whose root level contains the files of the subset. If the memory comprise a root level and one or more sub levels hierarchically below the root level, at least some of the files of the subset may be stored in a sub level. The media server may comprise a physical interface separate from the data output, the processor may be configured to receive the said command over that physical interface. The physical interface may be a wireless interface. The root level may be that of a virtual or emulated root level or directory.

1/2

2/2

A &wr~^Application No. GB1802995.9

RTM

Date :13 August 2018

Intellectual Property Office

The following terms are registered trade marks and should be read as such wherever they occur in this document:

TOSLINK (Page 6,7)

Wi-Fi (Page 7)

Bluetooth (Page 7)

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

FILE SERVING

This invention relates to serving files to reading devices.

It is known to store files on devices such as USB (universal serial bus) sticks. These comprise a memory which stores the files according to a file system such as FAT32. The file system enables the files to be organised into a hierarchical structure. The highest level of the file system is a root level. It can include files and one or more directories. Each directory may include files and a sub-level of one or more directories.

Media files, for example music or video files, can be stored on a storage device of this type. The device can then be connected to a reading device which can read selected files and play out the media represented in those selected files. The reading device might, for example, be a domestic hi-fi system or the entertainment system of an automobile. Such reading devices often have a somewhat restricted user interface for selecting the files to be played out. For example, a typical hi-fi system that accepts storage devices might have a small display, or no display at all, for displaying the directory structure, and it might not be able to show metadata such as detailed track information or cover art that might help the user to select a track. A typical automobile entertainment system has a restricted set of control options intended to make it safe for use when driving. These limitations can make it difficult to select a file from the storage device for playout, especially when there are many files stored on the device, and at multiple levels of file hierarchy.

It would be desirable to make it easier to select media for playback in a system like the ones described above.

According to the present invention there is provided a media server comprising: a memory storing a plurality of media files; a processor; and a data output; the processor being configured to receive an indication of a subset of the media files, and to, in response to that command, represent over the data output a mass storage device whose root level contains the files of the subset.

If the memory comprises a root level and one or more sub-levels hierarchically below that root level, at least some of the files of the subset may be stored in a sub-level.

The processor may be configured to, in response to the command, represent over the data output a mass storage device whose root level contains only the files of the subset.

The media server may comprise a physical interface separate from the data output, the processor being configured to receive the said command over that physical interface. The processor may be configured to be incapable of responding to a message received over the data output to represent over the data output a mass storage device whose root level contains the files of the subset.

The said physical interface may be a wireless interface.

The processor may be configured to represent a mass storage device according to a mass storage protocol. The mass storage protocol may provide a directory query command for requesting the contents of a directory. The processor may be configured to respond to such a command received over the data output requesting the content of a root level by returning over the data output a list of the files of the subset. The protocol may provide a file read command for requesting a file. The processor may be configured to respond to such a command received over the data output requesting one of the files of the subset by returning over the data output the data of that file.

The protocol may be a USB protocol. The protocol may be a SCSI protocol.

The data output may be a USB physical interface.

Some or all of the media files may be audio and/or video files.

The processor may be configured to represent a USB mass storage device.

The processor may be configured to in, response to the said indication, represent over the data output a mass storage device containing only the files of the subset.

The present invention will now be described by way of example with reference to the accompanying drawings.

In the drawings:

Figure 1 is a schematic view of a storage device and media playout system.

Figure 2 shows the architecture of the two-part playout apparatus of figure 1.

Figure 3 illustrates a file system.

Figures 4 and 5 illustrate virtual file systems.

Figure 1 shows a two-part playout apparatus. The apparatus comprises a primary playout unit 1 and a user interface unit 2. Content data, which defines the content of media to be played out, is stored on primary playout unit 1. A user can use user interface unit 2 to select which of that content is to be played out, and to cause the primary playout unit to play that content out. The user interface unit is communicatively coupled to the primary playout unit by a wireless data link. The primary playout unit has multiple hardware output connectors 7a-7e through which it can play out the content. A hi-fi system 9 can be connected to one or more of those connectors to receive the data that is being played out. In the example of figure 1, connection 3 exists from connector 7c. Each of the connectors 7a-7e is of a different type or format. Put another way, each connector differs in its hardware form (e.g. the shape of the coupling, the number of pins or other electrical or optical connectors, the configuration of the pins/connectors) and/or in the logical protocol it supports. The primary playout unit can serve media through any of the connectors 7a-7e. To do that it transfers media content data, defining the content of the media, from a chosen connector and over a link 3 connected to it. The media content data can then be received by the hifi system.

The hi-fi system 9 has multiple hardware input connectors 8a-8c through which it can receive the media content data. In the example of figure 1, connection 3 is connected to input connector 8a. Each of the connectors 8a-8c is of a different type.

The hi-fi system 9 comprises a digital-to-analogue converter (DAC) and amplifier 4. The DAC/amplifier 4 receives and processes media content data received over one of the input connectors 8 and in dependence on that content it drives loudspeakers 6 over analogue links 5. In this way, the loudspeakers 6 reproduce the sounds defined by the received media content data. The hi-fi system 9 has a selector 11, which may for example be a multi-position switch or a multiplexer. The selector can be controlled by a user of the hi-fi system to select which one of input connectors 8 is to be used by the DAC/amplifier 4.

The primary playout unit 1 can be considered a source of the media (e.g. audio and/or video) to be played out. The device to which it provides its output (device 4 in figure 1) can be considered a sink device in respect of a link 3. Examples of sink devices include (without limitation) amplifiers, DACs, sound processors, direct-drive loudspeakers, televisions and projectors. The sink device may itself reproduce the media, by presenting it in a form that can be appreciated by a human, or it may control a reproduction device to do so. If the sink device is, for example, a direct-drive loudspeaker, television or projector it may itself reproduce the media. Alternatively, the sink device may control a reproduction device such as a loudspeaker, headphones, a television or a projector, or may control a combination of a reproduction devices, such as loudspeakers and a television, to in combination reproduce the media.

In summary, the primary playout apparatus 1 operates under the control of the user interface apparatus 2 to play out to a sink device (4 in the example of figure 1) media stored in non-volatile storage locally on the primary playout unit. The sink device may itself reproduce that media for a human listener or viewer, or it may control a further reproduction device (6 in the example of figure 1) to do so.

The primary playout unit 1 and the user interface unit 2 are consumer devices. Each one is sized to be suitable for domestic use. Each one has a respective outer casing. Each casing may be configured to protect the device in domestic use.

Figure 2 shows the architecture of the playout apparatus in more detail.

The user interface unit 2 comprises display 10. Display 10 is driven by a processor 15. The processor 15 executes code stored in a non-transient form in a non-volatile memory 13. The memory 13 stores code executable by the processor 15 to perform the functions described of it herein. The user interface 2 has a user input device 12. This may be integrated with the display 10 if the display is a touch screen. The processor is coupled to a wireless communication interface 14. This may, for example, support Wi-Fi (IEEE 802.11) or Bluetooth communications. The user interface unit 2 is powered by a local battery 34. Alternatively, it may be powered directly by mains electricity.

The wireless transceiver 14 supports two-way wireless communications over a link illustrated at 40 with a corresponding wireless communications transceiver 21 of the primary playout unit 1. The communications link 40 may be direct between interfaces 14 and 21, as shown in figure 2, or may go via an access point or bridge.

The primary playout unit 2 comprises a media memory 20. This is a non-volatile memory which stores the content data that can be played out by the playout unit. The memory is wired into the primary playout unit. In one embodiment it is not userremovable from the primary playout unit. Alternatively, it may be user removable. Preferably the primary playout unit is configured so the media content data is permanently stored in it. That is, the media content stored in the memory is not capable of deletion or alteration by an end user. The media memory is coupled to processor 22. Processor 22 executes code stored in a non-transient form in a nonvolatile memory 23. The memory 23 stores code executable by the processor 22 to perform the functions described of it herein. The processor is also coupled to wireless interface 21.

One function of the processor is to read content data from memory 20, process it if necessary (for example by transforming it from one encoding scheme to another) and provide a digital output representing that content data. The digital output is provided on output bus 35. Output bus 35 is connected to a set of output drivers 24, 27, 28. Each output driver drives one or more physical output connectors 25, 26, 29, 30. These connectors correspond to connectors 7a-7e as shown in figure 1. The function of the output drivers is to transform the signal on the output bus into a signal that meets the physical and format requirements for transmission on an output link over one of the connectors, and to handle any link-level communications on that output link. Some examples will be given below.

1. Output connector 25 is an RCA socket for transmitting an analogue output signal to a receiving hi-fi device. Output connector 26 is a mini jack connector for transmitting an analogue output signal to a reproduction device such as a set of headphones. Accordingly, driver 24, which drives output connectors 25 and 26, comprises a digitalto-analogue convertor for converting the digital signal on bus 35 to a corresponding analogue signal and an amplifier for amplifying the analogue signal to a suitable line level. The driver 24 may also be capable of driving the RCA socket to provide an S/PDIF digital output.

2. Output connector 29 is an HDMI socket for transmitting a digital electrical signal according to an HDMI protocol to a receiving hi-fi device. Accordingly, driver 27, which drives output connector 29, comprises an HDMI driver. It converts the digital signal on bus 35 to a suitable format for transmitting according to an HDMI protocol, amplifies it to a suitable line level and transmits the resulting signal according to that protocol. The driver 27 also performs link-level HDMI activities such as handshaking, link negotiation and downloading capability data (EDID) from a receiving (sink) device.

3. Output connector 30 is a TOSLINK socket for transmitting a digitally encoded optical signal according to a TOSLINK protocol to a receiving hi-fi device. Accordingly, driver 28, which drives output connector 30, comprises a TOSLINK driver. It converts the digital signal on bus 35 to a suitable digital format for transmitting according to a TOSLINK protocol. That converted signal is used to control an optical source such as a laser or LED to generate light signal to be output via connector 30.

The hardware output connectors may be configured for any suitable hardware format and data protocol. Non-limiting examples of connector types that may be provided include TOSLINK, S/PDIF, HDMI, RCA/phono, mini jack, USB, and ethernet/RJ45. The connector may be a media-specific connector, for example TOSLINK, S/PDIF, HDMI, RCA/phono or a connector of a suitable format (e.g. USB-B) capable of DSD playout.

The primary playout unit 1 comprises a second wireless transceiver 33 which is coupled to the output bus. It can convert the data on the output bus into a suitable format for wireless transmission to a reproduction device, and then transmit it to the reproduction device. It may, for example, be a Wi-Fi (IEEE 802.11) or a Bluetooth transceiver. Transceiver 33 could be merged with transceiver 21.

The primary playout unit has a local user interface 36 whereby at least some functions of the primary playout unit may be controlled. Conveniently, the local user interface may provide a relatively simple user interface in comparison to that provided by the user interface unit 2. For example, the primary playout unit may have user operable switches for controlling basic functions of the unit; it may have no pixelated display device; it may have basic indicator lights to indicate, for example any one or more of the following: (I) that the device is powered on, (ii) that the device is charging, (iii) that the device is performing playback, (iv) that the device is in an error state, (v) that the device is in a programming state. Any indicator lights provided in the user interface and/or elsewhere on the exterior of the primary playout unit 1 may be isolated from any other such lights. Each such light may be capable of taking no more than two states (e.g. on/off), no more than three states (e.g. off, colour 1 on, colour 2 on) or no more than four states (e.g. off, colour 1 on, colour 2 on, colour 3 on). There may be lights next to each of the output connectors, for indicating a specific output connector by the light next to it being the only one of those lights that is illuminated.

The primary playout unit is powered by a battery 31. Conveniently the battery is rechargeable from an external connector 32. Alternatively, or in addition the battery may be user-replaceable. The primary playout unit operating under battery power whilst not connected to an external charging source can avoid the generation of earth loops to a sink device when the connection from the primary playout unit to the sink device is an electrical link. That can improve the quality of playback. Driving a display device can consume a considerable amount of the energy stored in the battery of a typical smartphone or tablet. By embodying the user interface on a separate device, the drain of a display on the battery of the primary playout unit can be avoided. This can increase the time that the primary playout unit operates without the need for recharging.

The memory 20 stores in a non-volatile form source media content. The source content data defines media that can be played out by the primary playout unit 1. The source content data may be stored in any suitable format, but it is preferred that it is stored in a relatively high definition form. Conveniently the source content data may be stored in an uncompressed (“raw”) form. Examples of suitable formats include pulse code modulated (PCM) audio (preferably at a sample rate greater than 44kHz), 4K or higher video, FLAC and MP3. Source content data representing a single item of content (e.g. a track) may be stored in multiple formats. Then when the item of content is to be played out the primary playout unit can select one of those stored formats as the source of playback. This may reduce the load on processor 22 if the selected format requires less transformation to provide the output feed to bus 35.

The memory 20 also stores metadata relating to one or more of the stored items of media content. The metadata may include any one or more of: (i) a track identifier of the media content (e.g. a track name or number), (ii) a name of a corpus of which the media content forms part (e.g. the name of a work or an album in which the media content appears), (iii) an identity of one or more performers of the media content, (iv) a date of the media content, (v) an image (e.g. an album cover) relating to the media content, (vi) any other more complex related information such as the musical score of the item of content, a video of the item of content being performed or a hyperlink to further information about the item of content.

The media content and the metadata can be stored in the memory 20 in any suitable data structure. Conveniently they are stored in a hierarchical data structure.

The memory 23 stores code for enabling the processor to transcode the stored media content into a suitable form for use by consumers 24, 27, 28, 33 on bus 35. The code may permit the processor to provide data of multiple different formats on bus 35. The processor may select the format in which data on bus 35 is provided in dependence on which of the physical outputs 25, 26, 29, 30 is active. For example, the processor may provide data on bus 35 at a resolution not higher than the maximum resolution of the active output having the highest resolution. Alternatively, the processor may be capable of providing data on bus 35 in a plurality of formats and it may select the one of those formats that is most similar to the format to be transmitted over an active output. This may reduce the power used by the driver for that output to transform the data from the output bus 35 into a suitable format for transmission over the respective physical output.

The primary playout unit comprises a further output port 60, which corresponds to port 7c of figure 1. Port 7c supports a mass storage protocol. Another device can communicate with the primary playout unit over port 7c and see content on the primary playout device as if it were directly accessing a file system.

Thus, in one mode of operation (e.g. when one of ports 25, 26, 29, 30 is being used for output) the primary playout unit progressively transmits data representing a locally stored file over a media playout link, and that data file can be reproduced by the sink system substantially at the same time as it is received by the sink device. This happens if the primary playout unit is providing a file over, for example, a phono or HDMI interface. This may be considered as streaming or real-time playback. In another mode of operation (when port 60 is being used for output), the primary playout unit can serve as a mass storage device. In this mode it permits a sink device to request a file and in response to that request it transmits that file in its entirety to the sink device. Then the sink device can store the entire file, interpret it and play out the file. In the second mode, the file may be provided to the sink device in a compressed or uncompressed media file format such as MP3, MP4, M4A, WMA, FLAC, OGG, WAV, AIF or AAC. The operation of the primary playout unit in that second mode will now be discussed in more detail.

To operate in the second mode, the processor 22 implements code stored in memory 23 to process and respond to messages received over mass storage interface 60. The physical form of the mass storage interface could, for example, be a USB interface (e.g. USB-A, USB-B or USB-C) or an SD (storage device) interface such as a microSD interface, or it could be a wireless interface such as IEEE 802.11B or Bluetooth. The protocol implemented by the processor 22 over the mass storage interface could, for example, be a USB mass storage protocol, OBEX, or any other suitable protocol supporting directory-level file interrogation and reading. In a preferred embodiment, the protocol is USB MSC or USB UMS, served over a USB hardware socket such as a USB-B socket. This configuration mimics a conventional USB stick.

Some examples of messages to which the processor can respond over the mass storage interface will now be described. Each message may be represented by a datagram of a respective form sent by the sink device to the primary playout unit over the mass storage interface 60. Among the messages to which the processor can respond over the mass storage interface are:

1. A directory query command. In response to this command the processor transmits a message over the mass storage interface listing the contents of either a directory specified in an operand to the command or of a current working directory. Those contents may include any files and directories present in the directory in question.

2. A directory change command. In response to this command the processor changes the current working directory by moving to the next higher directory in a file system hierarchy or to a directory specified in an operand to the command.

3. A read file command. In response to this command the processor transmits over the mass storage interface the content of a command specified in an operand to the command.

In practice, the processor may respond to these commands formatted as SCSI commands.

Figure 3 illustrates a hypothetical file structure that could be present in the memory

20. A root directory 70 holds, at a second level 71 of hierarchy, sub-directories A and D and files B and C. At a third level 72 of hierarchy, directory A holds sub-directories E and F and directory D holds files G and H. At a fourth level 73 of hierarchy, directory

E stores files I and J and directory F stores files K and L. In practice, the files may represent media files, and the directories may serve to group those media files together. For example, each of the directories may correspond to a particular artist, composer or genre, and may store files or sub-directories relevant to that grouping.

In one possible mode of operation, a sink device connected to port 60 may use the commands listed above to navigate the directory structure of figure 3, select a file for playback, read that file from the primary playout unit and then reproduce it. This mode of operation requires the sink device to pass directory-querying and potentially directory-changing commands to the primary playout unit. In this mode of operation, the user may need to operate a user interface of the sink device to review the available files and signal which directories or files are to be accessed.

A second mode of operation will now be described. In the second mode of operation the user uses user interface unit 2 to signal to the primary playout unit a media file or set of media files that are to be reproduced. The user may review information on the display 10 indicating the media files that are available on the primary playout unit. This information may for example be a list of works, albums or songs. The user may make a selection from that list, and that selection may be signalled to the primary playout unit. The processor 22 establishes which stored files correspond to the media that has been designated by the user. The processor then responds to commands received over the mass storage interface as if the root directory contained only those files. Thus, the processor represents to the sink system a virtual file system whose contents have been designated by the user using the user interface unit 2.

Figures 4 and 5 illustrate this mode of operation. The user might use the user interface unit 2 to designate files I and J of the file system shown in figure 3 for reproduction. In that case the processor responds to commands over the mass storage interface as if it were making available a directory structure as shown in figure 4. In this example the processor is treating directory E as if it were the root directory. In another example, the user might use the user interface unit 2 to designate files C and H of the file system shown in figure 3 for reproduction. In that case the processor responds to commands over the mass storage interface as if it were making available a directory structure as shown in figure 5. In this example the processor is in effect providing a virtual directory and treating that directory as if it were the root directory. In other examples, the processor might respond to commands received over the mass storage interface as if it were making available a directory structure having sub-directories as well as files.

In this mode of operation, the processor responds to file system commands (e.g. to request directory contents) so as to represent a directory structure in which the files designated by the user are the only files or directories at the root level.

In the examples given above, the files themselves are stored in a hierarchical structure. This is not essential. The files could be stored in a flat structure, or in a database, or in any other convenient way.

Using the approach described above, the user can simplify the user interface actions needed at the sink system in order to select one or more files to be read and reproduced. A hierarchical or non-hierarchical structure holds all the media files that are available for playout. The user selects a subset of those files using user interface

2. It may have a relatively more capable user interface. In response to that selection the processor 22 behaves so as to present over the mass storage interface a file structure comprising only that subset of files. Then, the selection of those files for playout at the sink device can be simplified because they appear to the sink device to be the only files available for playout over the mass storage interface. The sink device may be configured to automatically read and play out the contents of the root directory presented over the mass storage interface. This is particularly convenient because then the sink device can automatically play whatever media has been selected using device 2.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1. A media server comprising:

a memory storing a plurality of media files;

a processor; and a data output;

the processor being configured to receive an indication of a subset of the media files, and to, in response to that command, represent over the data output a mass storage device whose root level contains the files of the subset.

2. A media server as claimed in claim 1, wherein, if the memory comprises a root level and one or more sub-levels hierarchically below that root level, at least some of the files of the subset are stored in a sub-level.

3. A media server as claimed in claim 1 or 2, wherein the processor is configured to, in response to the command, represent over the data output a mass storage device whose root level contains only the files of the subset.

4. A media server as claimed in any preceding claim, comprising a physical interface separate from the data output, the processor being configured to receive the said command over that physical interface.

5. A media server as claimed in claim 4, wherein the said physical interface is a wireless interface.

6. A media server as claimed in any preceding claim, wherein the processor is configured to represent a mass storage device according to a mass storage protocol, the mass storage protocol providing a directory query command for requesting the contents of a directory, and the processor is configured to respond to such a command received over the data output requesting the content of a root level by returning over the data output a list of the files of the subset.

7. A media server as claimed in any preceding claim, wherein the processor is configured to represent a mass storage device according to a mass storage protocol, the mass storage protocol providing a file read command for requesting a file, and the processor is configured to respond to such a command received over the data output requesting one of the files of the subset by returning over the data output the data of that file.

8. A media server as claimed in claim 6 or 7, wherein the protocol is a USB protocol.

9. A media server as claimed in any of claims 6 to 8, wherein the protocol is a SCSI protocol.

10. A media server as claimed in any preceding claim, wherein the data output is a USB physical interface.

11. A media server as claimed in any preceding claim, wherein the media files are audio and/or video files.

12. A media server as claimed in any preceding claim, wherein the processor is configured to represent a USB mass storage device.

13. A media server as claimed in any preceding claim, wherein the processor is configured to, in response to the said indication, represent over the data output a mass storage device containing only the files of the subset.

Intellectual Property Office

Application No: GB1802995.9

Claims searched: 1-13

Examiner: Mr Aaron Saddington

Date of search: 13 August 2018

Patents Act 1977: Search Report under Section 17

Documents considered to be relevant:

Category Relevant to claims Identity of document and passage or figure of particular relevance X 1-13 US 2014/0108471 Al LIU ET AL - See whole document, especially figure 10 and paragraphs 99-104 X 1-13 US 2007/0156710 Al KERN ET AL - See whole document, especially paragraph 77 and Figures 7a and 7b with their accompanying description

Categories:

X Document indicating lack of novelty or inventive step A Document indicating technological background and/or state of the art. Y Document indicating lack of inventive step if P Document published on or after the declared priority date but combined with one or more other documents of before the filing date of this invention. same category. & Member of the same patent family E Patent document published on or after, but with priority date earlier than, the filing date of this application.

Field of Search:

Search of GB, EP, WO & US patent documents classified in the following areas of the UKCX :

Worldwide search of patent documents classified in the following areas of the IPC____________

G06F_______________________________________________________

The following online and other databases have been used in the preparation of this search report WPI, EPODOC, PATENT FULLTEXT, INTERNET

International Classification:

Subclass Subgroup Valid From G06F 0017/30 01/01/2006 G06F 0003/06 01/01/2006