JP2007250161A - Device and method for reproducing, program, program storage medium, and data distribution system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily handle a contents file recorded in a disk and an update file recorded in a local storage. <P>SOLUTION: For downloaded data, based on a path name designated by the src_file_name of a Manifest () section and a path name designated by the dst_file_name field, path and file names in the local storage and path and file names in a virtual file system are treated as different. This invention is applied to a reproducing device. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

The present invention relates to a playback apparatus and playback method, a program and a program storage medium, and a data distribution system, and more particularly to a playback apparatus and playback suitable for use when downloading an update file of content recorded on a recording medium. The present invention relates to a method, a program, a program storage medium, and a data distribution system.

  One of DVD (Digital Versatile Disc) playback-only standards is the DVD video format. In this DVD video format, content data such as video and audio is multiplexed together with various sub-picture data such as subtitles, and recorded as a program stream on a disc. In addition, navigation data for interactively reproducing the stream is recorded on the disc.

  Here, interactive playback refers to playback from a preferred position and playback in a preferred order, as well as a multi-angle function that enables playback of video shot from various angles, and preference from multiple languages. This refers to playback performed by the user using various functions of the DVD, such as a multi-language function that enables playback in any language, and a barrent control function that prevents playback of certain scenes such as violent scenes.

  The program stream can also multiplex a plurality of audio streams and a plurality of caption data streams. This makes it possible to record subtitle data in a plurality of different languages on a single disc for a single video content such as a movie, for example. You can select audio and subtitles in your preferred language.

  By the way, Patent Document 1 discloses a system that allows a user to easily download contents such as sound effects, moving images, and still images that are materials of a video work. Patent Document 2 discloses a technique that can replace a part of music data with other data.

JP 2003-140662 A JP 2002-31967 A

  However, there is a problem that the user can only reproduce the content recorded on the disc attached to the player.

  Therefore, for example, when a disc on which movie content for which only English subtitles are prepared is purchased is purchased, the user can display English subtitles that are recorded in advance on the disc. In order to view the same movie content in which subtitles in a desired language different from the recorded language are displayed, it is necessary to purchase a different disc in which the subtitle information in the desired language is recorded in advance. It was.

  Also, if the disc seller is to sell discs with movie content recorded in multiple countries with different languages, prepare discs with subtitle information for each language in advance, or It is necessary to prepare multiple types of discs, such as English discs and Japanese discs.

  For example, if you want to add bonus tracks or change some of the subtitles, audio, etc., instead of changing the entire content, the discs with the added bonus tracks, subtitles, audio, etc. A newly modified disk had to be prepared and distributed again.

  Therefore, it takes a long time to prepare such a disk, and in some cases, a large business opportunity is lost.

  The present invention has been made in view of such a situation, and it is possible to download an update file of content recorded on a disc so that the content file and update file recorded on the disc can be easily downloaded. To be able to handle it.

  A playback device according to a first aspect of the present invention is a playback device for playing back an AV stream using a first data group and a second data group recorded on an optical disc, wherein the first data group First acquisition means for acquiring data, second acquisition means for acquiring a second data group reproduced together with the first data group, and the second data acquired by the second acquisition means Storage means for storing a group; first information indicating a path of the second data group in a directory structure of the storage means from the second data group stored by the storage means; and the second information Extracting means for extracting the second information indicating the path in the virtual file system of the data group, detecting means for detecting the directory structure of the first data group, and the first detected by the detecting means 1's And at least part of each of the first data group and the second data group based on the directory structure of the data group and the first information and the second information extracted by the extracting means Virtual file system generation means for generating the virtual file system including the first data group and the second data group acquired based on the virtual file system, and the AV stream And reproducing means for reproducing.

  A playback method according to a first aspect of the present invention is a playback method for a playback apparatus that plays back an AV stream using a first data group and a second data group recorded on an optical disc, wherein A second data group to be reproduced together with the data group, and storing the acquired second data group in a storage unit, and from the second data group stored in the storage unit, the storage First information indicating a path of the second data group in a directory structure of a part and second information indicating a path of the second data group in a virtual file system are extracted, and the first information is extracted. And detecting the directory structure of the first data group and the first data group and the second information extracted based on the detected directory structure of the first data group and the extracted first information and second information. The second data group Generating the virtual file system including at least a part of each, reading the first data group and the second data group based on the virtual file system, and reproducing the AV stream; including.

  A program according to a first aspect of the present invention is a program for causing a computer to execute processing for reproducing an AV stream using a first data group and a second data group recorded on an optical disc, The second data group reproduced together with the first data group is acquired, the acquired second data group is stored in a storage unit, and the second data group stored in the storage unit From the first information indicating the path of the second data group in the directory structure of the storage unit and the second information indicating the path in the virtual file system of the second data group, A directory structure of the first data group is detected, and based on the detected directory structure of the first data group, and the extracted first information and second information, the first data group A virtual file system including at least a part of each of the data group and the second data group, and the first data group and the second data group based on the virtual file system. And the computer is caused to execute processing including the step of reproducing the AV stream.

  In the first aspect of the present invention, the first data group recorded on the optical disc and the second data group are used to reproduce the AV stream, and the first data group is reproduced together with the first data group. The second data group is acquired, the acquired second data group is stored, and the second data group in the directory structure in which the second data group is stored from the second data group First information indicating the path of the second data group and second information indicating the path of the second data group in the virtual file system are extracted, and the directory structure of the first data group is detected and detected. Further, at least one of each of the first data group and the second data group based on the directory structure of the first data group and the extracted first information and second information. The virtual file system containing a is generated, the first data group and the second data group is read based on the virtual file system, the AV stream is reproduced.

  A data distribution system according to a second aspect of the present invention includes a reproduction device that reproduces an AV stream based on information recorded on a removable optical disc, and a data distribution device that distributes data to the reproduction device. In the data distribution system, the playback device obtains a detection unit for detecting a directory structure of the first data group recorded on the optical disc, and a second data group distributed from the data distribution device Data acquisition means, first storage means for storing the second data group acquired by the data acquisition means, directory structure of the first data group detected by the detection means, and First information indicating a path in the directory structure of the storage means of the second data group and a virtual file system of the second data group A virtual file system that generates the virtual file system including at least a part of each of the first data group and the second data group based on attribute information including second information indicating a path to be Generating means, wherein the data distribution apparatus manages second distribution means for storing a plurality of the second data groups and a schedule for distributing the second data groups to the reproduction apparatus. And a plurality of second data groups stored in the second storage means that can be distributed to the playback device based on the schedule managed by the schedule management means Selecting means.

  In the second aspect of the present invention, the reproducing apparatus detects the directory structure of the first data group recorded on the optical disc, and acquires and acquires the second data group distributed from the data distribution apparatus. In addition, the second data group is stored, the directory structure of the first data group, and the first information indicating the path in the directory structure of the area where the second data group is stored, and the second data group The virtual data including at least a part of each of the first data group and the second data group based on attribute information including second information indicating a path in a virtual file system of the data group A file system is generated, a plurality of the second data groups are stored in the data distribution device, and a schedule for distributing the second data groups to the playback device is managed. Is, based on the schedule, among the plurality of the second data group stored by said second storage means, those that can be delivered to the playback device is selected.

  According to the present invention, it is possible to provide information necessary for combining and reproducing the first data group and the second data group supplied to the reproducing apparatus.

  According to still another aspect of the present invention, a virtual file system can be constructed, and a data group included in the virtual file system can be distributed according to a predetermined schedule.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram showing a configuration example of a playback apparatus 1 according to the first embodiment to which the present invention is applied.

  The controller 21 executes a control program prepared in advance, or controls the optical disc drive 22 to read a navigation program (described later) recorded on the optical disc 11, develops it in the memory 23 and executes it. The overall operation of the playback apparatus 1 is controlled. For example, the controller 21 can display a predetermined menu screen on an external display device when the optical disc 11 is loaded.

  The optical disk drive 22 reads data from the optical disk 11 according to the control by the controller 21 and outputs the read data to the controller 21, the memory 23, or the decoder 26. When the information read from the optical disc 11 is a navigation program or a PlayList, the information read by the optical disc drive 22 is output to the controller 21 or the memory 23. When the information read from the optical disk 11 is an AV stream or text data, the information read by the optical disk drive 22 is output to the decoder 26.

  FIG. 2 is a diagram showing an example of an application format of the optical disc 11 mounted on the playback apparatus 1 to which the present invention is applied. In addition to the optical disk 11, the recording medium mounted on the playback device 1 may be, for example, a magnetic disk or a semiconductor memory.

  The application format has two layers, PlayList and Clip, for managing AV (Audio Visual) streams. Here, a pair of one AV stream or text data and Clip Information which is information accompanying the AV stream or text data is considered as one object, and these are collectively referred to as Clip. Hereinafter, an AV stream data file is referred to as an AV stream file. A data file of Clip Information is referred to as a Clip Information file.

  In general, a file used in a computer or the like is handled as a byte string, but the content of an AV stream file is expanded on the time axis, and an access point of a clip is mainly designated by a PlayList with a time stamp.

  When the access point in the Clip is indicated by the PlayList with a time stamp, the Clip Information file is used to find address information to start decoding in the AV stream file from the time stamp.

  The PlayList is a set of information indicating the playback section of the AV stream. Information indicating one playback section in an AV stream is called PlayItem, and PlayItem is represented by a pair of IN point (playback start point) and OUT point (playback end point) of the playback section on the time axis. Therefore, the PlayList is composed of one or a plurality of PlayItems as shown in FIG.

  In FIG. 2, the first PlayList shown first from the left is composed of two PlayItems, and the first PlayList and the second half of the AV stream included in the first Clip shown on the left side by the two PlayItems. Each part is referenced. Also, the second PlayList shown second from the left is composed of one PlayItem, so that the entire AV stream included in the second Clip shown on the right is referred to. Furthermore, the third PlayList illustrated third from the left is composed of two PlayItems, and by the two PlayItems, a predetermined part of the AV stream included in the first Clip illustrated on the left side, and Reference is made to a predetermined portion of the AV stream included in the second Clip shown on the right side.

  The navigation program (Navigation program) is a program for causing the controller 21 to execute the function of controlling the playback order of the PlayList and the interactive playback of the PlayList. The navigation program also has a function of displaying a menu screen for the user to instruct execution of various reproductions. The navigation program is described in a programming language such as Java (registered trademark), and is recorded on a recording medium such as the optical disc 11. For example, when the navigation program is executed by the controller 21 and the first PlayItem included in the first PlayList illustrated first from the left in FIG. 2 is specified as information representing the playback position at that time, The first half portion of the AV stream included in the first Clip shown on the left side referenced by the PlayItem is played back.

  Further, in the PlayList described with reference to FIG. 2, in addition to the main path (Main Path) specified by PlayItem, the sub path specified by using a sub play item (Sub Play Item) as shown in FIG. (Sub path) information can also be included. When SubPlayItem is defined, for example, an independent data stream that is not multiplexed with a Clip (for example, MPEG2 transport stream) specified by PlayItem can be played back in synchronization with AV stream playback.

  For example, subtitle related information composed of a text subtitle file and a font file necessary for rendering, corresponding to the clip AV stream of the main path (Main Path) specified by PlayItem, and the playback section of the subtitle related information By preparing a SubPlayItem that specifies, the subtitles corresponding to the data described in the text subtitle file are displayed in the display font based on the font data described in the font file simultaneously with the playback of the Clip AV stream. It can be displayed on the device. Also, for example, by providing dubbed audio data in another language and SubPlayItem corresponding to dubbed audio data in correspondence with the Clip AV stream of the main path (Main Path) specified by PlayItem, playback of the Clip AV stream At the same time, dubbed voice data in other languages can be reproduced and output.

  Thus, the SubPlayItem and the corresponding data (clip) may be recorded on the optical disc 11 in advance, or may be downloaded from the server 3 via the network 2 as additional data (update data). Alternatively, it may be obtained using a removable medium (for example, a removable medium 28 described later). Details of downloading such additional data from the server 3 will be described later with reference to FIG.

  Returning again to the description of FIG.

  The memory 23 appropriately stores data necessary for the controller 21 to execute various processes. The local storage 24 is composed of, for example, an HDD (Hard Disk Drive) composed of a magnetic disk. In addition to the HDD, the local storage 24 may be configured by, for example, a semiconductor memory, or the local storage 24 configured by the semiconductor memory may be detachable from the playback device 1.

  The Internet interface 25 is connected to the network 2 by wire or wirelessly, communicates with the server 3 via the network 2 in accordance with control from the controller 21, and downloads data downloaded from the server 3 locally. The data is supplied to the storage 24. From the server 3, for example, data for updating the data described with reference to FIG. 2 recorded on the optical disc 11 mounted in the playback device 1 at that time is downloaded as content. The local storage 24 can record content downloaded from the server 3 via the network 2.

  The decoder 26 decodes the AV stream or text data supplied from the optical disk drive 22 or the local storage 24, and outputs the obtained video signal and audio signal to an external display device. In the display device, based on the signal decoded by the decoder 26, for example, the content recorded on the optical disc 11 (video display, audio output) is output.

  The operation input unit 29 includes, for example, an input device such as a button, a key, a touch panel, a jog dial, and a mouse, and a reception unit that receives a signal such as an infrared ray transmitted from a predetermined remote commander, and acquires a user operation input. To the controller 21.

  In addition, a drive 27 is connected to the controller 21 as necessary. For example, a magnetic disk (including a flexible disk), an optical disk (CD-ROM (Compact Disk-Read Only Memory), DVD) A removable medium 28 including a magneto-optical disk (including MD (registered trademark) (Mini-Disk)), a semiconductor memory, or the like.

  Next, a method for reproducing the data recorded on the optical disk 11 mounted on the reproduction apparatus 1 and the data stored in the local storage 24 will be described.

  The playback apparatus 1 includes a local storage 24 including an HDD (Hard Disk Drive). The playback device 1 is connected to the network 2 by wire or wirelessly, and can record the content downloaded from the server 3 via the network 2 in the local storage 24. From the server 3, for example, data for updating content such as a movie recorded on the optical disc 11 mounted on the playback device 1 at that time can be downloaded.

  In a state where the downloaded content is recorded in the local storage 24, when the operation input unit 29 instructs the reproduction of the content recorded on the optical disc 11, the controller 21 stores the content recorded on the optical disc 11. And the content recorded in the local storage 24 are associated with each other, and the content reproduction process is executed.

  Here, a method for reproducing the content recorded on the optical disc 11 and the content recorded on the local storage 24 in association with each other will be described with reference to FIG.

  For example, it is assumed that the optical disc 11 in FIG. Further, it is assumed that only an English text subtitle file is recorded on the optical disc 11 as a subtitle data file that can be displayed superimposed on the movie content video.

  For example, in FIG. 4, the Clip1 AV stream recorded on the optical disc 11 and referred to by the PlayList PlayItem is a stream for displaying the video of the movie content and playing the corresponding audio. The subtitle related information 1 of Clip2 to be referred to is a text subtitle file for displaying English subtitles in conjunction with video display.

  In this state, when subtitles in a language different from English are displayed and movie contents recorded on the optical disc 11 are to be viewed, subtitle data in a language different from English is not recorded on the optical disc 11. The user cannot view the movie by displaying subtitle data in a language different from English in this state.

  Therefore, the user causes the playback device 1 to download a text subtitle file in a desired language of a movie recorded on the optical disc 11 from the server 3 via the network 2 (or obtain it using the removable medium 28). A state in which a text subtitle file, for example, in Arabic that has not been recorded in advance on the optical disc 11 has been downloaded (or copied from the removable medium 28 to the local storage 24) will be described.

  That is, when the user instructs to download an Arabic text subtitle file corresponding to the PlayList recorded in advance on the optical disc 11, the playback apparatus 1 accesses the server 3 and records it on the optical disc 11. A file prepared in the server 3 is downloaded to update the content that is being updated.

  In the example of FIG. 4, for example, a video clip and audio of movie content recorded in advance on the clip 3 and the optical disc 11 composed of an Arabic text subtitle file (subtitle-related information 2) and a clip information file associated therewith. In addition to Clip (AV stream data) and English text subtitle files, the PlayList file (Updated PlayList file) that can control the playback and display of the corresponding subtitle data of Clip 3 is compared with the one recorded on the optical disc 11 The updated new navigation program files are downloaded and recorded in the local storage 24.

  Note that, in the updated play list, SubPlayItem1 and SubPlayItem2 representing sub paths are added in addition to the PlayItem representing the main path. PlayItem of Updated PlayList refers to Clip1 including AV Stream recorded on optical disc 11, SubPlayItem1 refers to Clip2 including subtitle related information 1 recorded on optical disc 11, and SubPlayItem2 Refers to Clip3 including subtitle related information 2 that is an Arabic text subtitle file downloaded from the server 3 together with the updated play list.

  The new navigation program of FIG. 4 can specify SubPlayItem1 or SubPlayItem2 together with the PlayItem of the updated play list as the playback section. Thus, for example, the new navigation program is associated with the desired video and audio data in advance on the optical disc 11 in advance. Of the English subtitles defined by the recorded text subtitle file in English or the Arabic subtitles defined by the text subtitle file in Arabic not previously recorded on the optical disc 11, the subtitles in the language desired by the user Can be displayed.

  As described above, by downloading from the server 3 (or copying from the removable medium 28), the playback apparatus 1 can perform the clip 2 that is an English text subtitle file and the Arabic that is not prepared in advance on the optical disc 11. Any of Clip3, which is a text subtitle file of words, can be reproduced and displayed as a subtitle of a movie. That is, the user views a movie with a desired language subtitle in English or Arabic by selecting a desired language from among the subtitle languages that can be displayed on the menu screen displayed on the display device. be able to.

  Note that the AV stream recorded on the optical disc 11 has a structure of an MPEG2 (Moving Picture Experts Group 2) transport stream as shown in FIG. The MPEG2 transport stream is composed of an integer number of Aligned units. The size of the Aligned unit is 6144 bytes (2048 × 3 bytes), and starts from the first byte of the source packet. The source packet is 192 bytes long. One source packet is composed of a TP_extra_header and a transport packet. TP_extra_header is 4 bytes long, and the transport packet is 188 bytes long. One Aligned unit is composed of 32 source packets. Video stream and audio stream data are packetized into MPEG2 PES (Packetized Elementary Stream) packets, and PES packets are packetized into transport packets.

  FIG. 6 is a block diagram illustrating a functional configuration example of the controller 21 of FIG.

  Each configuration in FIG. 6 is realized by executing a control program prepared in advance by the controller 21 or by executing a navigation program recorded on the optical disc 11 by the controller 21.

  The menu screen display control unit 31 deletes the audio of the content recorded on the optical disc 11 or the language of the subtitles, the button operated by the user when selecting the video angle, the update file to be downloaded, or the like. A menu screen including buttons operated by a user when selecting a file is displayed on an external display device.

  The operation input acquisition unit 32 acquires a signal indicating an operation input from the user, which is input from the operation input unit 29, and outputs a signal indicating the operation input from the user as a menu screen display control unit 31, a data acquisition unit 33, The data is output to a corresponding location in the local storage directory management unit 34 or the playback control unit 37.

  The data acquisition unit 33 controls communication performed in the Internet interface 25 in FIG. 1 or information exchange with the removable medium 28 by the drive 27. For example, the data acquisition unit 33 downloads and acquires the update file designated by the user from the server 3 and outputs the acquired file to the local storage directory management unit 34. In addition, the data acquisition unit 33 receives supply of information indicating a necessary file from the file system merge processing unit 36 described later, downloads the necessary file from the server 3, acquires the acquired file, and acquires the acquired file in the local storage directory. The data is output to the management unit 34.

  The local storage directory management unit 34 manages a directory of the local storage 24 and controls writing of data to the local storage 24, reading of data from the local storage 24, and deletion of data from the local storage 24. For example, the PlayList read from the local storage 24 under the control of the local storage directory management unit 34 is output to the memory 23, and the audio data and video data of the AV stream and the text of the text subtitle file read from the local storage 24 are read. The data is output to the decoder 26. In addition, when the file system merge processing unit 36 merges the file system of the optical disk 11 and the file system of the local storage 24 by the file system merge processing unit 36, the local storage directory management unit 34 stores information on the file system of the local storage 24. The data is output to the merge processing unit 36.

  The optical disc directory management unit 35 manages a directory of the optical disc 11 and controls reading of each data from the optical disc 11. Author_id and disc_id, which are identification information, are set in the optical disc 11, and the author_id and disc_id read from the optical disc 11 are controlled by the optical disc directory management unit 35 in the data acquisition unit 33 and the local storage directory management unit 34. Is output. Also, the PlayList read from the optical disc 11 is output to the memory 23 under the control of the optical disc directory management unit 35, and the audio data and video data of the AV stream and the text data of the text subtitle file read from the optical disc 11 are included. Are output to the decoder 26. In addition, when the file system merge processing unit 36 merges the file system of the optical disk 11 with the file system of the local storage 24, the optical disk directory management unit 35 performs file system merge processing on information related to the file system of the optical disk 11. To the unit 36. The author_id and disc_id will be described later.

  The file system merge processing unit 36 merges the file system of the optical disk 11 supplied from the optical disk directory management unit 35 and the file system of the local storage 24 supplied from the local storage directory management unit 34 to create one virtual file. Generate the system. The file system merge processing unit 36 outputs the virtual file system generated by merging to the reproduction control unit 37.

  Further, the file system merge processing unit 36, when some files recorded in the local storage 24 are deleted (erased, that is, data is deleted) by the process described later, by deleting some of the files. , A problem occurs in the file link structure in the virtual file system (that is, the linkage of data for playing a clip by a play list based on the application format of the optical disc 11 as described with reference to FIGS. 2 to 4). When it is determined that a problem occurs in the file link structure in the virtual file system, a file necessary for resolving the problem is extracted and information indicating the necessary file is supplied to the data acquisition unit 33 Then you can download the necessary files.

  Further, the file system merge processing unit 36 is not played back by any PlayList in the virtual file system, for example, by deleting some files recorded in the local storage 24 by the process described later (all If a file (not specified by the PlayList) is generated, the local storage directory management unit 34 can be instructed to delete such an unnecessary file.

  Note that the user may be able to set whether or not to delete unnecessary files that are generated when several files are deleted.

  The playback control unit 37 executes a navigation program specified by the virtual file system supplied from the file system merge processing unit 36, and controls playback of content. Specifically, the playback control unit 37 refers to the PlayList supplied to and stored in the memory 23, controls the local storage directory management unit 34 or the optical disc directory management unit 35, and records it on the optical disc 11 or the local storage 24. 1 is read out based on the virtual file system, and the decoder 26 in FIG. 1 is controlled to read the audio data of the AV stream, the video data, and the text data of the text subtitle file as necessary. The AV stream audio data and video data recorded in the storage 24 and, if necessary, the text data of the text subtitle file are decoded (reproduced).

  Here, merging of the file system of the optical disc 11 performed by the file system merge processing unit 36 and the file system for managing the data group recorded in the local storage 24 by downloading from the server 3 will be described. This merging is performed when, for example, when the optical disc 11 is loaded in the playback device, or when playback of content recorded on the optical disc 11 is instructed, any data recorded on the optical disc 11 or the local storage 24 is input. This is performed when an output is commanded or when a merge is commanded by the user.

  A virtual file system is defined as an upper layer of a native file system (file system of data actually recorded on the optical disk 11 or the local storage 24) possessed by the system of the playback apparatus 1. That is, as shown in FIG. 7, new data is downloaded from the server 3 and recorded on the local disk 24, or the process of reproducing the data actually recorded on the optical disk 11 or the local storage 24 is executed. An application program or a user who handles the application program can recognize only a virtual file system that is an upper layer. In other words, the virtual file system is constructed to abstract the native file system and conceal native structures such as a physical device and an operating system in the playback apparatus 1.

  The role of the virtual file system is mainly to mount a file / directory in a physical device (the optical disk 11 or the local storage 24) to configure a virtual disk file system recognized by the user, To provide the program with a file access API to the constructed virtual disk.

  For example, when the user performs an operation input requesting access to any file recorded on the optical disc 11 or the local storage 24, only the virtual file system is included in the application program as shown in FIG. Can only recognize. The structure of the local file system # 1, the local file system # 2, or the file system in the optical disk 11 recorded in the optical disk 11 or the local storage 24, which is an actual physical device, includes an application program and an application program. It is hidden from the user who handles it, and is accessible via a virtual file system.

  In order to execute the file access request shown in FIG. 8, the application program of the playback apparatus 1 calls the file input / output API (Application Programming Interface) provided by the virtual file system, thereby physically configuring the disk drive. It is possible to access data actually recorded on the optical disk 11 or the local storage 24 without being aware of the software configuration of the file system. In other words, the virtual file system API actually calls the native file system API inside the playback apparatus 1.

  The virtual file system provides various APIs, for example, open () to open the specified file, close () to close the specified file, seek () to set the reading or writing position of the specified file, specification APIs such as stat () to get the status of the specified file, read () to read the specified file, and write () to write the specified file are provided. An application program executed by the reproduction control unit 39 or the like operates a file recorded on the optical disc 11 or the local storage 24 using these APIs.

  The virtual file system has a function of dividing and managing the disk area of the local storage 24. For example, as shown in FIG. 9, the disk area of the local storage 24 has a directory structure divided for each content distribution source (content author), and the contents below the disc_id that are directly under the author_id are determined by the content author. A flexible file / directory structure can be configured. Where the data stored in the local storage 24 is arranged in the disk area of the local storage 24, that is, the file / directory structure of the downloaded file is the metadata included in the downloaded data (Manifest data described later) ).

  In the file / directory structure of the local storage 24, author_id for dividing the directory is an identifier for uniquely identifying the content creator, and disc_id uniquely identifies the optical disc 11 with respect to the content creator specified by author_id. Each of which is information included in metadata (manifest data described later) of downloaded data. The metadata (Manifest data), author_id, and disc_id will be described later.

  On the other hand, the directory / file structure of the virtual disk accessible from the application follows the directory / file structure of the optical disk 11. That is, the file structure of data corresponding to author_id and disc_id or less is merged with the file structure of the data recorded on the optical disk 11 for the optical disk 11 mounted on the playback device 1, and the directory / file structure of the optical disk 11 A virtual file system of a virtual disk having a directory / file structure based on the above is configured.

  In addition to the directory and file management mechanism, the virtual file system has a function of managing metadata, that is, a Manifest file to be described later, in disc units. The purpose of the virtual file system to define the metadata field for the file model of the native file system is to present to the user the path or file name of the file that is actually recorded on the local disk 24. Rather than providing a name representing the content content, preventing double updating of the same file in the download process, and a path name in the virtual file system, that is, a path name at the time of reproducing the optical disk And defining.

  The virtual file system provides two functions for managing metadata: a Manifest file and a metadata operation procedure. The Manifest file is metadata indicating various attributes of the downloaded file, and Manifest () is an identifier of the Manifest () section that is merged into one file even if saved in units of corresponding files. The manifest_id (described later in FIG. 10) may be identified using a key. Regardless of the form, here it is collectively referred to as a Manifest file. The playback device 1 holding a file downloaded to the local storage 24 must hold a Manifest file. The Manifest file can also take a text representation in a tagged language represented by XML.

  FIG. 10 is a diagram illustrating the syntax of the Manifest file.

  manifest_id is the identifier of this Manifest () section.

  The author_id is a field for designating an identifier for uniquely identifying the content creator. This identifier is determined by referring to the author_id field of the content distribution file, which will be described later with reference to FIG. 17, and the application program or user cannot freely set a value in this field.

  disc_id is a field for designating an identifier for uniquely identifying the optical disc 11 with respect to the content creator specified by author_id. This identifier is determined by referring to the disc_id field of the content distribution file, which will be described later with reference to FIG. 17, and the application program or the user cannot freely set a value in this field.

  version is a field used by the content author for history management. The history number is expressed by a numerical value from 1 to 255, and the larger the numerical value, the newer the content. This identifier is determined by referring to the versiond field of the content distribution file, which will be described later with reference to FIG. 17, and the application program or user cannot freely set a value in this field.

  In display_name, a user-friendly name is defined. Specifically, a character string that expresses content that is difficult to associate with the file name, such as “Japanese subtitle of title xxx”, is set in display_name. It is assumed that the character string is encoded according to the ISO / IEC 10646-1 standard.

  In the source, information indicating the file distribution source is described. This field value shall be encoded according to the ISO / IEC 646 standard. In the case of network download, the URL of the download source is described.

  The operation_type is an 8-bit field for the content author to specify the file update method. FIG. 11 shows a list of values that can be specified for operation_type.

  When 0x01 is described in the 8-bit field of operation_type, the update method of the file in the archive is PlayList replacement (exchange). That is, when an update file in which 0x01 is written in the 8-bit field of operation_type is downloaded, in a virtual file system created by merging using this update file, it is downloaded and recorded in the local storage 24. The PlayList being read is referred to as it is, and the PlayList on the optical disc 11 is not referred to at all.

  Details of the file update method when 0x01 is described in the 8-bit field of operation_type will be described later with reference to FIGS.

  Further, when 0x02 is described in the 8-bit field of operation_type, the SubPath element is extracted from the downloaded file, and the extracted SubPath element is added to the SubPath element recorded on the optical disc 11. The file system is merged and updated.

  Details of the file update method when 0x02 is described in the 8-bit field of operation_type will be described later with reference to FIGS.

  In addition, when 0x03 is described in the 8-bit field of operation_type, the SubPlayItem element is extracted from the downloaded file, and the extracted SubPlayItem element is added to the SubPlayItem element recorded on the optical disc 11 The file system is merged and updated.

  For example, details of a file update method when 0x03 is described in the 8-bit field of operation_type will be described later with reference to FIGS.

  Then, when 0x04 is written in the 8-bit field of operation_type, the SubClip_entry element is extracted from the downloaded file, and the extracted SubClip_entry element is added to the SubClip_entry element recorded on the optical disc 11. The file system is merged and updated.

  For example, details of a file update method when 0x04 is described in the 8-bit field of operation_type will be described later with reference to FIGS.

  Next, permission is a field for the content author to specify permission / authorization information such as whether to make the attribute visible to the user or whether to make it invisible.

  FIG. 12 shows a list of values that can be specified for the permissions included in Manifest () of FIG.

  As shown in FIG. 12, when 0x00 is described in the 8-bit field of permission, the attribute of the file accompanied by this metadata is an invisible attribute to the user, and the 8-bit permission is set. When 0x01 is described in the field of, the attribute of the file accompanying this metadata is a visible attribute to the user, and when 0x02 is described in the 8-bit field of permission, The attribute of the file accompanying this metadata is an overwrite prohibition attribute.

  The src_file_name is information that can uniquely specify where the file is recorded in the directory structure in the file system of the local storage 24, that is, the file position using the file position in the hierarchical structure of the file system of the local storage 24. This is a field for designating a “path name” representing a so-called path to be specified. It is assumed that the name of the file or directory for expressing the path name is encoded according to the ISO / IEC 646 standard.

  dst_file_name is information that can uniquely specify where the file is recorded in the directory structure at the binding destination of the file stored in the local storage 24 in the virtual disk, that is, the file in the hierarchical structure of the virtual file system. This is a field for specifying a “path name” representing a so-called path that specifies a file using a position. It is assumed that the name of the file or directory for expressing the path name is encoded according to the ISO / IEC 646 standard.

  Note that the same name can be specified for src_file_name and dst_file_name.

  Next, a metadata operation procedure will be described.

  The virtual file system defines an API for reading the contents of Manifest () without exposing the file name, file position, physical structure, etc. of Manifest () to an application program or user.

  That is, an application program or a resident program executed by the playback device 1 can indirectly access Manifest () by calling the following API.

getProperty
Argument 1:
String type data
Absolute path name of the file subject to metadata operations Argument 2:
String type data
Element name of metadata to be read
String type data
Metadata corresponding to the element specified in the argument Function:
Read metadata from Manifest ()

  Actually, the definition of detailed API such as type information must be changed depending on the programming language specification of the software execution environment of the playback apparatus 1.

  FIG. 13 is a diagram illustrating an example of a file system of the optical disc 11. As shown in FIG. 13, the file system of the optical disc 11 has a directory structure.

  A directory in which the name “BDMV” is set is prepared under “root” of the optical disc 11, and a file in which the name “Index.bdmv” is set in the directory and the name “MovieObjects.bdmv”. The set file is stored. Hereinafter, these files will be referred to as an Index file and a MovieObject file, respectively, as appropriate. As appropriate, each file is referred to by adding “file” to “file name”, or each directory is referred to by adding “directory” to “directory name”.

  The Index file includes information regarding a menu for playing the optical disc 11. The playback device 1 displays, for example, a playback menu screen including items such as playback of all the contents of the optical disc 11, playback of a specific chapter, repeated playback, and display of an initial menu based on the Index file. Display on the device. A MovieObject to be executed when each item is selected can be set in the Index file. When one item is selected from the playback menu screen by the user, the playback device 1 uses the MovieObject set in the Index file. Execute a command.

  The MovieObject file is a file including MovieObject. The MovieObject includes a command for controlling playback of the PlayList recorded on the optical disc 11. For example, the playback device 1 selects and executes one of the MovieObjects recorded on the optical disc 11, The content recorded on the optical disc 11 can be reproduced.

  The BDMV directory also includes a directory with the name “BACKUP” (BACKUP directory), a directory with the name “PLAYLIST” (PLAYLIST directory), and a directory with the name “CLIPINF” (CLIPINF directory). , A directory (STREAM directory) in which the name “STREAM” is set, and a directory (AUXDATA directory) in which the name “AUXDATA” is set.

  In the BACKUP directory, files and data for backing up files and data recorded on the optical disc 11 are recorded.

  A PlayList file is stored in the PLAYLIST directory. As shown in the figure, each PlayList file is given a name obtained by adding an extension “.mpls” to a file name consisting of a 5-digit number.

  A Clip Information file is stored in the CLIPINF directory. Each Clip Information file is named by adding the extension “.clpi” to a file name consisting of five digits as shown in the figure.

  In the STREAM directory, a Clip AV stream file and a substream file are stored. Each stream file is given a name obtained by adding an extension “.m2ts” to a file name consisting of five digits as shown in the figure.

  The AUXDATA directory is not included in the Clip AV stream file or substream file, but is referred to from the Clip AV stream file or substream file, or data used independently of the Clip AV stream file or substream file. And other files are stored. In the example of FIG. 13, the AUXDATA directory stores a subtitle font file with the name “11111.otf” and a sound effect with the name “sound.bdmv”.

  Also, the optical disk 11 has an author_id that is an identifier assigned to each content author in order to identify the content author (or also called the title author) that is the content producer of the optical disk 11 such as a production company or a movie distributor. The disc_id, which is an identifier assigned to identify the type of the optical disc 11 produced by the content author indicated by the author_id, is used as secure electronic data that cannot be rewritten by the user or the like or physically pit Is recorded by.

  FIG. 14 is a diagram illustrating an example of a file system of the local storage 24. As shown in FIG. 14, the file system of the local storage 24 also has a directory structure.

  A directory having at least one “author_id” name is prepared under “root” of the local storage 24, and at least one “disc_id” name is set under the “author_id” directory. A directory is provided. The directory “disc_id” includes a Manifest file including a set of Manifest () sections or one Manifest () section. Other directory and file structures can be freely set by the content author. For example, the directory / file structure of the optical disc 11 described with reference to FIG. 14, the directory / file structure of the optical disc 11 described with reference to FIG. 13 may be completely different.

  For example, in FIG. 14, in addition to the Manifest file, a plurality of folders such as a “MainMovie” directory, a “SubTitle” directory, and an “AUXDATA” directory are set in the “disc_id” directory. It can contain folders or files.

  The directory / file structure of the local storage 24 shown in FIG. 14 is hidden from the application program executed in the playback apparatus 1 or the user.

  For example, in the Manifest () section described with reference to FIG. 10, the path name “/MainMovie/movie01/main.r1.jp.mp2” is specified in the src_file_name field, and “/ STREAM / 01002. When the path name “m2ts” is designated, the downloaded data is stored in the main. directory in the movie01 directory in the MainMovie directory under the corresponding author_id and disc_id in the local storage 24, as shown in FIG. Although it is recorded with the file name r1.jp.mp2, in the virtual file system on the virtual disk, it is handled as a file with the file name 01002.m2ts in the STREAM directory.

  As described above, the content author specifies the path name in the local storage 24 in the src_file_name field of the Manifest () section of the downloaded file package, and specifies the path name of the virtual file system in the virtual disk in the dst_file_name field. can do. Therefore, if a path name adapted to the virtual file system in the virtual disk is set in the field of dst_file_name, the content author can use the file / directory structure below the disc_id of the data actually recorded in the local storage 24 of the playback device 1. Can be set freely, and directories and files can be newly added to the area under disc_id.

  Further, when the dst_file_name field in the Manifest () section is left blank when downloading an actual file, the file cannot be referenced from an application program executed on the playback device 1 (that is, on the playback device 1). The existence of the file cannot be recognized from the application program to be executed or the user). That is, the real file is stored in the local storage 24, and the file is correctly recognized in the file system of the local storage, but it does not exist in the virtual file system by leaving the dst_file_name field blank. And can be hidden from the application program executed by the playback apparatus 1 and the user.

  By using this, for example, the actual file is downloaded with the dst_file_name field in the Manifest () section blank, and the same Manifest_id is included at a later date, and a predetermined path name in the virtual file system is described in the dst_file_name field. By downloading the Manifest () section again and overwriting the Manifest () section, the actual file is downloaded from the application program executed on the playback apparatus 1 at the timing when the new Manifest () section is downloaded. Can be handled in the same way as

  In this way, for example, the dst_file_name field is set so that a plurality of bonus tracks can be downloaded at once or distributed on a predetermined recording medium, and then different bonus tracks can be recognized by the application. Users can download only the listed Manifest () section at a certain time and overwrite it, so that users can add a different bonus track at each time without frequently downloading large amounts of data. Can be provided.

  Further, the synchronization (binding) method between the actual file system in the optical disk 11 and the local storage 24 and the file system of the virtual disk may be a so-called static binding method or a dynamic binding method. A new API (for example, update ()) may be defined for updating, and the virtual file system may be updated when the API is explicitly called by a user operation or application program. .

  The static binding refers to the actual file system in the optical disk 11 and the local storage 24 at the time when the optical disk 11 is mounted on the playback apparatus 1 or when the playback title is switched, and the directory / The file structure is mapped, and dynamic binding searches for a necessary file when a file input / output request is issued.

  The directory / file structure of the virtual disk is preferably matched with the directory / file structure of the optical disk 11 as described above. The directory / file structure of the optical disc 11 is determined in advance by a standard or the like and cannot be changed in many cases, and the directory and file structure of the actual file system in the local storage 24 can be freely set by the content author. Is preferred. Therefore, if the directory / file structure of the virtual disk can be set based on the directory / file structure of the optical disk 11 that cannot be changed, the degree of freedom of data distributed by the content author is maintained. It is preferable because the reproduction process conforming to the standard such as the application format of the optical disc 11 can be executed.

  An example of the directory / file structure in the virtual disk is shown in FIG.

  In the directory / file structure of the virtual disk shown in FIG. 16, a directory with the name “BDMV” is prepared under “root”, and the name “Index.bdmv” is set in the directory. A file and a file with the name “MovieObjects.bdmv” are stored.

  The Index file includes information related to a menu for reproducing content recorded on the optical disc 11 and the local storage 24 and handled as being recorded on the virtual disc from the application program. The playback device 1 includes, for example, a playback menu screen including items such as playing back all content handled as recorded on the virtual disk, playing back only a specific chapter, playing back repeatedly, and displaying an initial menu. Is displayed on the display device based on the Index file. A MovieObject to be executed when each item is selected can be set in the Index file. When one item is selected from the playback menu screen by the user, the playback device 1 uses the MovieObject set in the Index file. Execute a command.

  Details of the Index file will be described later with reference to FIGS. 37 and 38.

  The MovieObject file is a file including MovieObject. The MovieObject includes a command for controlling the playback of the PlayList that is handled as recorded on the virtual disk. For example, the playback device 1 selects one of the MovieObjects that are handled as recorded on the virtual disk. By executing the content, it is possible to reproduce the content handled as recorded on the virtual disk.

  The BDMV directory also includes a directory with the name “BACKUP” (BACKUP directory), a directory with the name “PLAYLIST” (PLAYLIST directory), and a directory with the name “CLIPINF” (CLIPINF directory). , A directory (STREAM directory) in which the name “STREAM” is set, and a directory (AUXDATA directory) in which the name “AUXDATA” is set.

  In the BACKUP directory, files and data for backing up files and data handled as being recorded on the virtual disk are recorded.

  A PlayList file is stored in the PLAYLIST directory. As in the case of the optical disc 11, each PlayList file is given a name obtained by adding an extension “.mpls” to a file name consisting of five digits.

  A Clip Information file is stored in the CLIPINF directory. As in the case of the optical disc 11, each Clip Information file is given a name obtained by adding an extension “.clpi” to a file name consisting of five digits.

  In the STREAM directory, a Clip AV stream file and a substream file are stored. As in the case of the optical disc 11, each stream file is given a name obtained by adding an extension “.m2ts” to a file name consisting of a 5-digit number.

  The AUXDATA directory is not included in the Clip AV stream file or substream file handled as being recorded on the virtual disk, but is referenced from the clip AV stream file or substream file, or the clip AV stream file or substream file. A file such as data used independently of the stream file is stored.

  In the menu screen provided to the user, the information indicating the file is usually the name specified in the display_name field. For example, the directory / file structure in the virtual disk described with reference to FIG. Since it is not hidden from the application or the user, the directory / file structure in the virtual disk may be presented to the user depending on the application executed in the playback apparatus 1.

  Next, definition of a file format for content distribution when the content author distributes content will be described with reference to FIG. The file format for content distribution may be individual distribution in units of content files, but may also be an archive format including metadata (Manifest ()) as shown in FIG.

  However, for the Package_header () section and the Package_Body () section in the archive, it is possible to obtain a text representation in a tagged language represented by XML.

  Note that when the content author individually distributes content in units of files, the metadata (Manifest ()) is handled as a single binary file or text file. In other words, Manifest () associated with the content distributed in units of files must describe an appropriate state in anticipation of the directory structure after addition.

  compression_type is a field for designating the compression method of the data in Package_Body (). If 0 is specified in this field, the data in Package_Body () is in an uncompressed format.

  Encryption_type is a field for designating a scramble method (encryption method) of data in Package_Body (). When 0 is specified in this field, the data in Package_Body () is assumed to be in a non-scramble (plain text) format.

  Note that the order of the scramble and compression of the data in Package_Body () is performed in the order of 1. compression process and 2. scramble process.

  file_count is a field for designating the total number of files to be archived.

  manifest_id is a field for designating an identifier of this Manifest () section.

  After the archive data is downloaded, the Manifest () section is stored in the local storage 24 in a corresponding download file unit (archive data unit) or merged into a single file. () The identifier of the section, manifest_id, may be used as a key.

  The author_id is a field for the content author to specify an identifier for uniquely identifying the content creator.

  disc_id is a field for the content author to specify an identifier for uniquely identifying the optical disc 11 at a specific content creator. That is, this archive is update data for the optical disc 11 specified by disc_id.

  version is a field used by the content author for history management. The history number is expressed by a numerical value from 1 to 255, and the larger the numerical value, the newer the content.

  “source” is a field for describing a source URL of a file associated with this Manifest (). It is assumed that the character string is encoded according to the ISO / IEC 10646-1 standard.

  The operation_type is a field for the content author to specify the content update procedure. The values that can be specified for operation_type are the same as those described with reference to FIG.

  The display_name is a field for the content author to specify a user-friendly name. For example, it is a field for setting a character string that expresses contents that are difficult to associate with the file name, such as “Japanese subtitles of title xxx”. It is assumed that the character string is encoded according to the ISO / IEC 10646-1 standard.

  The permission is a field for the content author to specify permission / authorization information such as whether to make the attribute visible to the user or whether to make the attribute invisible. Values that can be specified in Permission are the same as those described with reference to FIG.

  src_file_name is a field for designating the path name of a file to be recorded in the local storage 24 as described with reference to FIG. It is assumed that the file / directory name is encoded in accordance with the ISO / IEC 646 standard.

  As described with reference to FIG. 15, dst_file_name is a field for designating the path name of the binding destination file in the virtual disk (virtual file system). It is assumed that the file / directory name is encoded in accordance with the ISO / IEC 646 standard.

  Note that the same name can be specified for src_file_name and dst_file_name.

  file_size is a field for designating the file size before compression in bytes.

  file_data is a field for designating file data as a byte sequence.

  Data in the file format for content distribution as described with reference to FIG. 17 is downloaded and merged with the data recorded on the mounted optical disk 11 in the playback apparatus 1 to construct a virtual file system in the virtual disk. . As a result, a user who reproduces the content recorded on the optical disc 11 using the reproducing apparatus 1 adds, for example, a bonus track, audio in different languages, or display subtitles to the content recorded on the optical disc 11. It feels like it has been updated.

  When content configured according to the above-described file format is updated, for example, in the virtual file system described with reference to FIG. 16, an index file (Index.bdmv), a movie object file (Movieobjects.bdmv), a playlist File (*****. Mpls), clip information file (*****. Clpi), stream file or AUX data file (*****. M2ts, ***** bdmv, **** New data files are downloaded and bound so that * .otf) etc. are added or updated. In order for these files to be downloaded and played back in association with the content recorded on the loaded optical disc 11, it is defined by the operation_type described above, such as addition of MainPath or addition of SubPath. Various types of additions are performed.

  First, as a first example, a case where MainPath is added to content recorded on the optical disc 11 mounted on the playback device 1 will be described.

  For example, 0x01 is described in the 8-bit field of operation_type, and as shown in FIG. 18, the optical disc 11 includes a PlayList # 1 file including MainPath # 1 and SubPath # 1, a ClipAV stream # 1 file, and The text subtitle stream # 1 file is recorded and the content package downloaded from the server 3 includes a PlayList # 2 file having MainPath # 2 and SubPath # 1 having PlayItem # 1 and PlayItem # 2, and a bonus track. When the corresponding ClipAV stream # 2 file is included, the PlayList # 2 file in the content package is extracted, and the extracted PlayList # 2 is the updated PlayList # 1 file read from the optical disc 11 and The file system is updated to the replaced state.

  That is, as shown in FIG. 19, in the PlayList # 1 before the update having the MainPath composed of PlayItems and the SubPath composed of SubPlayItems, that is, in the PlayList # 1 of the optical disc 11, the ClipAV stream # 1 referred to by the PlayItems The text subtitle stream # 1 that is referred to by the SubPlayItem and that is reproduced in synchronization with the Clip AV stream 1 is reproduced. In PlayList # 2 after updating the content recorded on the optical disc 11 (that is, after the file system has been merged and updated), ClipAV corresponding to the bonus track following ClipAV stream # 1. Stream # 2 is played back.

  As described with reference to FIGS. 18 and 19, when a PlayItem is added, for example, a bonus track can be additionally provided to the content recorded on the optical disc 11 mounted on the playback device 1. it can.

  Next, as a second example, a case where SubPath is added to the content recorded on the optical disc 11 mounted on the playback device 1 will be described.

  For example, when 0x02 is described in the 8-bit field of operation_type, as shown in FIG. 20, the optical disc 11 includes a PlayList # 1 file including SubPath # 1 (in addition to including MainPath, of course. Hereinafter, if the update is not related to the MainPath, the description of the MainPath is omitted.) The ClipAV stream # 1 file and, for example, the Audio stream # 1 file corresponding to the sub-audio are recorded and downloaded from the server 3 When the package includes a PlayList # 1 file having SubPath # 2 and a text subtitle stream # 1 file, SubPath # 2 of the PlayList # 1 file in the content package is extracted, and the extracted SubPath The file system is updated so that # 2 is added to the update source PlayList # 1 file read from the optical disc 11 Is done.

  That is, as shown in FIG. 21, in the PlayList before update, that is, the PlayList of the optical disc 11 having the MainPath composed of PlayItems and the SubPath composed of SubPlayItems, The Audio stream # 1, which is sub-audio data that is reproduced in synchronization with the Clip AV stream 1 with reference to the SubPlayItem, is reproduced. In the PlayList after updating the content recorded on the optical disc 11 (that is, after the file system is merged and updated), the content is played back in synchronization with ClipAV stream # 1 and independently. Since the second SubPlayItem for which the playback section can be set is added to the Sub Path, the ClipAV stream # 1 referred to by the PlayItem and the first SubPlayItem are referenced and played back in synchronization with the ClipAV stream # 1. In addition to the reproduction of the audio stream # 1 that is sub-audio data, the text subtitle stream # 1 in which the reproduction section can be set independently of the audio stream # 1 can be reproduced.

  As described with reference to FIGS. 20 and 21, when a SubPath is added, it is possible to increase the Path that can be selected by the SubPath. Therefore, for example, new subtitles that can be selected can be added and provided to the user.

  Next, as a third example, a case where SubPlayItem is added to content recorded on the optical disc 11 mounted on the playback device 1 will be described.

  For example, 0x03 is described in the 8-bit field of operation_type, and as shown in FIG. 22, the optical disc 11 includes a PlayList # 1 file including SubPath # 1 composed of SubPlayItem # 1, a ClipAV stream # 1 file, The text subtitle stream # 1 file is recorded, and the content package downloaded from the server 3 includes a PlayList # 1 file having SubPath # 1 composed of SubPlayItem # 2 and a text subtitle stream # 2 file. In the content package, SubPlayItem # 2 constituting SubPath # 1 of the PlayList # 1 file in the content package is extracted, and the extracted SubPlayItem # 2 is the updated PlayList # 1 file read from the optical disc 11 The file system is updated to be added to SubPath # 1.

  That is, as shown in FIG. 23, in the pre-update PlayList having a MainPath composed of PlayItems and a Sub Path composed of SubPlayItem # 1, ClipAV stream # 1 and SubPlayItem # referenced by the PlayItem 1 is referred to, and the text subtitle stream # 1 is reproduced in synchronization with the ClipAV stream # 1. In the PlayList after the content recorded on the optical disc 11 is updated (that is, after the file system is merged and updated), the ClipAV stream # 1 and SubPlayItem # 1 referenced by the PlayItem are referenced. In addition, not only the text subtitle stream # 1 that is reproduced in synchronization with the ClipAV stream 1 is reproduced, but also SubPlayItem # 2 is added to the SubPath, so that the text subtitle stream # 2 is synchronized with the ClipAV stream # 1. It is made reproducible.

  As described with reference to FIGS. 22 and 23, when SubPlayItem is added, SubPlayItem in SubPath is added. Therefore, it is possible to provide the user with additional selectable subtitles, for example.

  Next, as a fourth example, a case where SubPlayItem is replaced with content recorded on the optical disc 11 attached to the playback device 1 will be described.

  For example, 0x03 is described in the 8-bit field of operation_type. As shown in FIG. 24, the optical disc 11 includes a PlayList # 1 file including SubPath # 1 composed of SubPlayItem # 1, a ClipAV stream # 1 file, The content subtitle stream # 1 file recorded and downloaded from the server 3 includes SubPlayItem # 1 (hereinafter, recorded on the optical disc 11) having the same name as that recorded on the optical disc 11. In order to distinguish what is included in the content package, what is recorded on the optical disc 11 is referred to as SubPlayItem # 1, and what is included in the content package is referred to as SubPlayItem # 1 '. 25) and SubPath # 1 consisting of SunPlayItem # 2 When PlayList # 1 file and text subtitle stream # 2 file are included, SubPlayItem # 1 'and SunPlayItem # 2 constituting SubPath # 1 of PlayList # 1 file in the content package are extracted and extracted The file system is updated in such a manner that SubPlayItem # 1 ′ and SunPlayItem # 2 thus written are overwritten (replaced) by SubPath # 1 of the update source PlayList # 1 read from the optical disc 11.

  That is, as shown in FIG. 25, in the pre-update PlayList having a MainPath composed of PlayItems and a Sub Path composed of SubPlayItem # 1, ClipAV stream # 1 and SubPlayItem # referenced by the PlayItem 1 is referred to, and the text subtitle stream # 1 is reproduced in synchronization with the ClipAV stream # 1. In the PlayList after updating the content recorded on the optical disc 11 (that is, after the file system has been merged and updated), the ClipAV stream # 1 and SubPlayItem # 1 ′ to which the PlayItem refers are stored. Since the text subtitle stream # 1 to be referred to and the text subtitle stream # 2 to be referred to by the SubPlayItem # 2 are reproduced, the text subtitle to be reproduced in synchronization with the ClipAV stream # 1 is added. Also, for example, when SubPlayItem # 1 ′ is a SubPlayItem in which only the playback section of SubPlayItem # 1 is updated, the playback section of the text subtitle is extended.

  As described with reference to FIGS. 24 and 25, when the SubPlayItem is replaced and the text subtitle stream played back by the replaced SubPlayItem is different from that before the replacement, the text subtitle stream played back by the SubPlayItem in the SubPath Is changed. Therefore, for example, subtitles changed (corrected) from the middle can be provided to the user.

  Next, as a fifth example, a case where a clip is added to content recorded on the optical disc 11 mounted on the playback device 1 will be described.

  For example, 0x04 is described in the 8-bit field of operation_type, and as shown in FIG. 26, the PlayList # including SubPath # 1 composed of SubPlayItem # 1 associated with Clip # 1 on the optical disc 11 is shown. One file, a ClipAV stream # 1 file, and a text subtitle stream # 1 file corresponding to a subtitle in the first language, for example, are recorded, and a content package downloaded from the server 3 is associated with Clip # 2. When a PlayList # 1 file having SubPath # 1 composed of SubPlayItem # 1 and a text subtitle stream # 2 file corresponding to a subtitle in the second language is included, PlayList # 1 in the content package Clip # 2 of SubPlayItem # 1 constituting SubPath # 1 of the file is extracted, and the extracted Clip # 2 is the update source P read from the optical disc 11 The file system is updated to be added to SubPlayItem # 1 constituting SubPath # 1 of the layList # 1 file.

  That is, as shown in FIG. 27, in the pre-update PlayList having the MainPath composed of PlayItems and the SubPath composed of SubPlayItems, the ClipAV stream # 1 and SubPlayItem # 1 referenced by the PlayItem are referenced. The text subtitle stream # 1 corresponding to the subtitle in the first language is played back in synchronization with the ClipAV stream # 1. In the PlayList after updating the content recorded on the optical disc 11 (that is, after the file system is merged and updated), the ClipAV stream # 1 referred to by the PlayItem and the SubPlayItem refer to the PlayList. Since the text subtitle stream # 1 corresponding to the subtitle of the first language that is played back in synchronization with the ClipAV stream # 1 is played back, Clip # 2 is further added to the SubPlayItem constituting the SubPath. In synchronization with ClipAV stream # 1, text subtitle stream # 2 corresponding to the second language referred to by SubPlayItem can be further reproduced.

  As described with reference to FIGS. 26 and 27, when a clip is added, it is possible to provide a user with additional subtitles in selectable languages.

  It is possible to record AV stream data other than the above-described file structure on the optical disc 11, and to decode and reproduce it by the decoder 26. However, in the AV stream data other than the above-described file structure, the local storage 24 A virtual file system cannot be constructed using files downloaded in Therefore, the user who uses the playback apparatus 1 cannot handle data so that a file recorded on the optical disc 11 is added or only a part of the file is updated.

  In addition, the data distribution source (content author) pre-packages files necessary for addition / update so that the playback apparatus 1 does not have to execute the editing of the PlayList file. A file may be downloaded at every directory data indicated by Disc_id.

  When adding or updating a file, if the file name is the same, the file is overwritten. If the file name is different, the file is newly added.

  In this way, the playback apparatus 1 downloads new data having a configuration as shown in FIG. 17 from the server 3 via the network 2 and describes it in the Manifest () that is metadata. The path in the virtual file system is set based on the path name indicated in dst_file_name stored in the local storage 24 and described in Manifest () based on the path name indicated in src_file_name One application (for example, an application that performs playback processing) is recorded on the optical disk 11 and on the local storage 24 based on the virtual file system, that is, based on the path indicated by dst_file_name. Data can be processed without distinction.

  That is, when it is described as processing executed by an application program executed in the playback device 1, when an application program capable of executing data addition processing receives a data addition instruction (download instruction), the corresponding Manifest file (all Or a part of the Manifest file) is transmitted to the server 3 via the network 2 and a list of contents that can be currently added is acquired from the server 3. The application program presents a list of contents that can be added to the user, and the user selects contents to be downloaded from the presented list.

  When the content to be downloaded is selected by the user, an application that can execute a process of downloading data from the server 3 (for example, even if the application program is the same as an application program that can execute a data adding process and a reproducing process) Download of data is started.

  When downloading by the download application is completed, the downloaded file package group is mounted on the virtual file system by the application that manages the file system, and the native file system and the virtual file system are separated by static binding or dynamic binding. Be synchronized.

  Next, a process for deleting a file based on a user operation input will be described. The playback device 1 can display a menu screen that displays a list of files in the local storage 24 using the Manifest file, and the user can display a virtual file on a file (content) basis based on this menu screen. You can delete files from the system or delete files from the virtual file system on a disk basis.

  First, deletion of a file from the virtual file system on a file (content) basis will be described.

  From the user's point of view, deleting a file from a virtual disk on a content basis means, for example, English subtitles and Japanese dubbed audio that are not recorded in advance on the optical disk 11 and recorded on the virtual disk by downloading. Is selected for each content, and the corresponding file group is deleted.

  For example, an additional file update as described with reference to FIGS. 18 and 19 is performed on the optical disc 11 mounted on the playback apparatus 1, and a ClipAV stream corresponding to the bonus track is added. Then, the additional update of the file as described with reference to FIGS. 20 and 21 is executed, and the text subtitle stream corresponding to the SubPath corresponding to the new selectable subtitle is added. Further, the additional update of the file as described with reference to FIGS. 22 and 23 is executed, the SubPlayItem is added, the SubPlayItem in the SubPath is extended, and the text subtitle stream corresponding to the additional subtitle is added. At this time, the state of the content recorded on the virtual disc is, for example, as shown in FIG. 28, SubPath # 1 and SubPlayItem # 1, PlayList # 1 having SubPath # 2 and SubPlayItem # 2, ClipAV Stream # 1, ClipAV stream # 2, and text subtitle streams # 1 to # 3 are included. Then, as shown in FIG. 29, the ClipAV stream # 1 and the ClipAV stream # 2 are continuously played by the Main Path specified by the PlayItem, and the text by the Subpath # 1 specified by using the SubPlayItem # 1 The subtitle stream # 1 and the text subtitle stream # 3 are played back, and the text subtitle stream # 2 is played back by SubPath # 2 specified using SubPlayItem # 2. In this state, a case where the user instructs to start the process of deleting any file will be described.

  At this time, the local storage directory management unit 34 of the controller 21 controls the data acquisition unit 33 to access the server 3 via the Internet interface 25 and the network 2, for example, related to the content reproduced by this PlayList # 1. Information indicating the current state of the virtual file system, such as manifest_id, is transmitted to the server 3, and information corresponding to a list of possible updates, that is, items that can be deleted is received from the server 3. Then, by the process of the menu screen display control unit 31, for example, as shown in FIG. 30, a list of files that can be deleted is presented to the user. Here, French subtitles, bonus tracks, and Japanese additional subtitles are included in the list of files that can be deleted.

  When deletion of the bonus track is selected by the user, the local storage directory management unit 34 deletes a file corresponding to the bonus track selected by the user. At this time, the local storage directory management unit 34 can delete the file associated with the Manifest file in the file package corresponding to the bonus track, and can delete the corresponding Manifest () section itself in the Manifest file.

  By the way, a file recorded in the local storage 24 is not always referred to by only one PlayItem. That is, it can be assumed that the above-described deletion process causes trouble in the reproduction process of other parts.

  Specifically, the text subtitle file #n (n is an integer) referred to in the bonus track to be deleted is played back in synchronization with the AV stream file that is not deleted. When the text subtitle file #n is also deleted along with the deletion of the bonus track, the text subtitle file #n cannot be reproduced in synchronization with the AV stream file that is not deleted.

  Therefore, the file system merge processing unit 36 determines whether or not the above-described deletion processing in the virtual file system causes trouble in the reproduction processing of other parts. Is detected, the data file necessary for the reproduction processing of the other part is detected, and the data acquisition unit 33 is instructed to send a signal requesting the download of the data file to the server 3. Upon receiving the file download, it is expanded in the local storage 24 by the processing of the local storage directory management unit 34 in the same manner as described above.

  Then, the file system merge processing unit 36 performs the virtual file system binding process at the predetermined timing as described above, regardless of whether a new file is downloaded or not. . By such processing, content is reproduced based on the virtual file system in a state where the file selected by the user has been deleted.

  Next, deletion of a file from a disk-based virtual file system will be described.

  Deleting a file on a disk basis from the virtual disk means deleting all files included in the directory corresponding to the corresponding disc_id in the local storage 24. For example, all files associated with a Manifest file existing under a certain disc_id are deleted, and then all Manifest () sections are also deleted.

  From the user's point of view, specifically, the contents recorded on the optical disc 11 are deleted and added or updated files downloaded and bound to the virtual file system (that is, newly recorded on the virtual disc) are deleted. By doing so, it is equivalent to initializing the optical disc 11 (being only the content recorded on the optical disc 11).

  Next, processing executed by the playback device 1 will be described with reference to a flowchart.

  First, file-based addition and update processing will be described with reference to the flowchart of FIG.

  In step S1, the operation input acquisition unit 32 of the controller 21 performs a process for adding a file included in a file base, that is, a directory indicated by a predetermined disc_id, from the user based on a signal supplied from the operation input unit 29. It is determined whether or not a command to start is received. If it is determined in step S1 that the command for starting the file addition process has not been received, the process of step S1 is repeated until it is determined that the command for starting the file addition process has been received.

  If it is determined in step S1 that an instruction to start a file addition process has been received, in step S2, the local storage directory management unit 34 of the controller 21 controls the data acquisition unit 33 to connect the Internet interface 25 and the network 2 to each other. The server 3 is accessed, and information indicating the current state of the virtual file system, for example, Manifest_id of the corresponding Manifest () section is transmitted.

  In step S <b> 3, the data acquisition unit 33 controls the Internet interface 25 and determines whether information corresponding to a list of downloadable files has been received from the server 3 via the network 2.

  If it is determined in step S3 that information corresponding to the list of downloadable files has not been received, in step S4, the menu screen display control unit 31 notifies the user that file addition processing is impossible. Display of an error message to control, and the process is terminated.

  If it is determined in step S3 that information corresponding to the list of downloadable files has been received, the data acquisition unit 33 is transmitted from the server 3 and received by the Internet interface 25 in step S5. The information corresponding to the list is supplied to the menu screen display control unit 31. The menu screen display control unit 31 causes the display device to display a menu screen that allows the user to select a desired one from the list of downloadable files.

  In step S <b> 6, the operation input acquisition unit 32 determines whether an item to be added has been selected by operating a button or icon on the menu screen whose display is controlled by the process of the menu screen display control unit 31. To do. If it is determined in step S6 that the item to be added is not selected, the process of step S6 is repeated until it is determined that the item to be added is selected.

  If it is determined in step S6 that the item to be added has been selected, in step S7, the operation input acquisition unit 32 supplies information indicating the content of the update selected by the user to the data acquisition unit 33. The data acquisition unit 33 controls the Internet interface 25 to transmit information indicating the requested file to the server 3 and request download of the file selected by the user.

  In step S8, the data acquisition unit 33 controls the Internet interface 25 and is provided as a download file by the server 3, such as a PlayList file, ClipInformation file, ClipAV stream file, audio file, text subtitle stream file, or font file. And the local storage directory manager 34 is notified that these files have been downloaded.

  In step S <b> 9, the local storage directory management unit 34 determines whether the directory identified by the ID already exists in the local storage 24 based on the author_id and disc_id included in the Manifest () of the downloaded file. If the corresponding directory already exists, the downloaded data file is expanded. If the corresponding directory does not exist, a new directory specified by author_id and disc_id is stored in the local storage 24. Create and unpack the downloaded data file.

  In step S10, a binding process 1 described later with reference to FIG. 32 is executed, and the process ends.

  By such processing, an update file can be downloaded from the server 3 and recorded in the local storage 24 so that it can be handled as an update file of content recorded on the optical disc 11.

  That is, by such processing, for example, a user who has purchased the optical disc 11 on which content such as a movie is recorded can download files and bonus tracks necessary for displaying subtitles in a language not recorded in advance on the optical disc 11. An application program that acquires a file or the like necessary for viewing and stores it in the local storage 24, and executes a reproduction process on the data recorded on the optical disc 11 and the data stored in the local storage 24 Can be handled without distinction, and a virtual file system can be constructed so that storage of physical data can be hidden from a user or an application program.

  The download of the update file as described above may be performed for a fee or may be performed for free.

  Next, the binding process 1 executed in step S10 of FIG. 31 will be described with reference to the flowchart of FIG.

  In step S 21, the local storage directory management unit 34 extracts a corresponding disc_id directory from the downloaded data group recorded in the local storage 24, and supplies the directory to the file system merge processing unit 36.

  In step S22, the file system merge processing unit 36 refers to src_file_name and dst_file_name of the Manifest file.

  In step S23, the file system merge processing unit 36 binds the native file system and the virtual file system based on src_file_name and dst_file_name referred to in step S22.

  Specifically, in src_file_name, information that can uniquely specify where the file is recorded in the directory structure in the file system of the local storage 24, that is, a “path name” representing a so-called path is specified, and dst_file_name is specified in dst_file_name. Actually, in the binding destination of the file stored in the local storage 24 in the virtual disk, information that can uniquely specify where this file is recorded in the directory structure, that is, a “path name” representing a so-called path is specified. .

  For example, in the Manifest () section described with reference to FIG. 10, the path name “/MainMovie/movie01/main.r1.jp.mp2” is specified in the src_file_name field, and “/ STREAM / 01002. When the path name “m2ts” is specified, the file system merge processing unit 36, as described with reference to FIG. 15, the downloaded data is stored in the local storage 24 under the corresponding author_id and disc_id. It is recorded in the movie01 folder in the MainMovie folder with the file name main.r1.jp.mp2, but in the virtual file system on the virtual disk, it is bound so that it is handled as a file with the file name 01002.m2ts in the STREAM directory To do.

  The content author can specify the path name in the local storage 24 in the src_file_name field of the Manifest () section of the downloaded file package, and can specify the path name in the virtual file system in the virtual disk in the dst_file_name field. . Therefore, if the path name adapted to the virtual file system in the virtual disk (adapted to the file system of the optical disk 11) is set in the field of dst_file_name, the content author is actually recorded in the local storage 24 of the playback apparatus 1. It is possible to freely set the file / directory structure below the disc_id of the data to be added and newly add a directory or file to the area below the disc_id.

  Next, disk base addition and update processing will be described with reference to the flowchart of FIG.

  In step S <b> 41, the operation input acquisition unit 32 of the controller 21 receives a file based on the signal supplied from the operation input unit 29 from the user on the disc base, that is, a file below the disc_id of data actually recorded in the local storage 24 It is determined whether or not a command to start additional processing is received. If it is determined in step S41 that the command for starting the file addition process has not been received, the process of step S41 is repeated until it is determined that the command for starting the file addition process has been received.

  If it is determined in step S41 that an instruction to start a file addition process has been received, in step S42, the local storage directory management unit 34 of the controller 21 controls the data acquisition unit 33 to connect the Internet interface 25 and the network 2 to each other. The server 3 is accessed, and information indicating the current state of the virtual file system, for example, Manifest_id of all Manifest () sections included in the Manifest file below the corresponding disc_id is transmitted.

  In step S <b> 43, the data acquisition unit 33 controls the Internet interface 25 and determines whether information corresponding to a list of downloadable disk-based files is received from the server 3 via the network 2.

  If it is determined in step S43 that information corresponding to the list of downloadable disk-based files could not be received, in step S44, the menu screen display control unit 31 determines that file addition processing is impossible. The display of the error message for notifying the user is controlled, and the process is terminated.

  If it is determined in step S43 that information corresponding to the list of downloadable files has been received, in step S45, the data acquisition unit 33 is transmitted from the server 3 and received by the Internet interface 25. Information corresponding to the list of base files is supplied to the menu screen display control unit 31. The menu screen display control unit 31 causes the display device to display a menu screen that allows the user to select a desired one from the list of downloadable files.

  In step S <b> 46, the operation input acquisition unit 32 determines whether an item to be added has been selected by the user operating a button or icon on the menu screen whose display is controlled by the process of the menu screen display control unit 31. To do. If it is determined in step S46 that the item to be added is not selected, the process of step S46 is repeated until it is determined that the item to be added is selected.

  If it is determined in step S46 that the item to be added has been selected, in step S47, the operation input acquisition unit 32 supplies the data acquisition unit 33 with information indicating the content of the update selected by the user. The data acquisition unit 33 controls the Internet interface 25 to transmit information indicating the requested file to the server 3 and request download of the disk-based file selected by the user.

  In step S48, the data acquisition unit 33 controls the Internet interface 25 to download a disk-based file group prepared as a download file by the server 3, and indicates that the disk-based file group has been downloaded. Notify the management unit 34.

  In step S49, the local storage directory management unit 34 creates a directory identified by these IDs in the local storage 24 based on the author_id and disc_id included in the Manifest () of the downloaded file, and has been downloaded. Deploy disk-based data.

  In step S50, the binding process 1 described with reference to FIG. 32 is executed, and the process ends.

  By such processing, an update file can be downloaded from the server 3 on a disk basis, recorded in the local storage 24, and handled as an update file of content recorded on the optical disk 11.

  That is, by such a process, for example, a user who has purchased the optical disk 11 on which content such as a movie is recorded can download files and bonus tracks necessary for displaying subtitles in a language not recorded in the optical disk 11 in advance. A file necessary for viewing is acquired on a disk basis and stored in the local storage 24, and the data recorded on the optical disk 11 and the data stored in the local storage 24 are reproduced. It is possible to construct a virtual file system that can handle application programs without distinction, and can conceal physical data storage from users or application programs.

  In addition, the download of such a disk-based update file may be performed for a fee or may be performed free of charge, as in the case of downloading on a file basis. Also good.

  In addition, FIG. 31 illustrates the processing when the file-based download is instructed by the user, and FIG. 33 illustrates the processing when the disc-based download is instructed by the user. Needless to say, a file download start instruction may be given without distinguishing between the file base and the disk base. That is, depending on whether the format of data downloaded from the server 3 is file-based or disk-based, the method of expanding the downloaded data onto the local disk 24 by the local storage directory management unit 34 can be changed. Anyway.

  Next, the file-based deletion process will be described with reference to the flowchart of FIG.

  In step S <b> 71, the operation input acquisition unit 32 of the controller 21 starts a deletion process for each file included in the file base, that is, the directory indicated by disc_id, based on the signal supplied from the operation input unit 29. It is determined whether or not a command is received. If it is determined in step S71 that a command to start file-based deletion processing has not been received, the processing in step S71 is repeated until it is determined that a command to start file deletion processing has been received.

  If it is determined in step S71 that an instruction to start the file-based deletion process has been received, the local storage directory management unit 34 of the controller 21 controls the data acquisition unit 33 in step S72 to control the Internet interface 25 and the network 2. To the server 3, and transmits information indicating the current state of the virtual file system, that is, Manifest_id of the corresponding Manifest () section.

  In step S <b> 73, the data acquisition unit 33 controls the Internet interface 25 to determine whether or not information corresponding to a list of items that can be updated, that is, items that can be deleted, has been received from the server 3 via the network 2. To do.

  If it is determined in step S73 that information corresponding to a list of possible updates could not be received, in step S74, the menu screen display control unit 31 notifies the user that file deletion processing is impossible. Control the display of the error message, and the process is terminated.

  If it is determined in step S73 that the information corresponding to the list of possible updates has been received, the data acquisition unit 33 is transmitted from the server 3 and received by the Internet interface 25 in step S75. Is supplied to the menu screen display control unit 31. The menu screen display control unit 31 displays on the display device a menu screen that allows the user to select a desired one from a list of possible updates.

  In step S76, the operation input acquisition unit 32 determines whether an item (content) to be deleted has been selected by the user operating a button or icon on the menu screen whose display is controlled by the process of the menu screen display control unit 31. Determine whether. If it is determined in step S76 that the item to be deleted has not been selected, the process of step S76 is repeated until it is determined that the item has been selected.

  If it is determined in step S76 that the item to be deleted has been selected, in step S77, the operation input acquisition unit 32 supplies information representing the item to be deleted selected by the user to the local directory management unit 34. The local directory management unit 34 deletes the designated file from the local storage 24.

  In step S78, the file system merge processing unit 36 determines whether or not a failure occurs in the file link structure in the virtual file system due to the file deletion processing executed in step S77. If it is determined in step S78 that there is no problem with the file link structure in the virtual file system, the process proceeds to step S81 to be described later.

  If it is determined in step S78 that a problem occurs in the file link structure in the virtual file system, in step S79, the file system merge processing unit 36 selects a data file (in some cases, a folder depending on the case). Or a directory) is extracted and supplied to the data acquisition unit 33. The data acquisition unit 33 controls the Internet interface 25 to transmit information indicating the requested file to the server 3 and request download of the file selected by the user. Then, the data acquisition unit 33 controls the Internet interface 25, downloads files necessary for resolving clothing, prepared as download files by the server 3, and determines that these files have been downloaded locally. The storage directory management unit 34 is notified.

  In step S80, the local storage directory management unit 34 determines whether or not the directory identified by the ID already exists in the local storage 24 based on the author_id and disc_id included in the Manifest () of the downloaded file. If the corresponding directory already exists, the downloaded data file is expanded. If the corresponding directory does not exist, a new directory specified by author_id and disc_id is stored in the local storage 24. Create and unpack the downloaded data file.

  If it is determined in step S78 that there is no problem with the file link structure in the virtual file system, or after the processing in step S80 is completed, the file system merge processing unit 36 is executed in step S77 in step S81. It is determined whether or not the setting is such that a file that has become unnecessary due to the deletion processing of the file, for example, a file that is not played by any PlayList (not specified by all PlayLists) in the virtual file system is deleted . If it is determined in step S81 that the unnecessary file is set to remain without being deleted, the process proceeds to step S83 described later.

  If it is determined in step S81 that the unnecessary file is set to be deleted, in step S82, the file system merge processing unit 36 extracts the unnecessary file, and such an unnecessary file is obtained. The local storage directory management unit 34 is instructed to delete a new file. The local storage directory management unit 34 deletes unnecessary files recorded in the local storage 24 based on a command from the file system merge processing unit 36.

  If it is determined in step S81 that the unnecessary file is set to remain without being deleted, or after the process of step S82 is completed, the binding process 1 described with reference to FIG. 32 is performed in step S83. Is executed and the processing is terminated.

  By such processing, the update file downloaded from the server 3 and recorded in the local storage 24 is deleted in file units, that is, in units of files included in the directory indicated by disc_id, based on a user operation input. be able to.

  Next, disk-based deletion processing will be described with reference to the flowchart of FIG.

  In step S <b> 111, the operation input acquisition unit 32 of the controller 21 deletes all files included in the disc base, that is, the directory indicated by disc_id, from the user based on the signal supplied from the operation input unit 29. It is determined whether or not a command to start is received. If it is determined in step S111 that a command to start the disk-based deletion process has not been received, the process of step S111 is repeated until it is determined that a command to start the disk-based deletion process has been received.

  If it is determined in step S111 that an instruction to start the disk-based deletion process has been received, in step S112, the file system merge processing unit 36 applies a Manifest file corresponding to the part to be deleted, for example, the current playback device 1. A Manifest file corresponding to author_id and disc_id of the mounted optical disk 11 is extracted, and the corresponding Manifest file is read by the local storage directory management unit 34.

  In step S113, the local storage directory management unit 34 deletes the file associated with the Manifest file from the local storage 24 based on the read Manifest file.

  In step S <b> 114, the local storage directory management unit 34 deletes the Manifest file corresponding to the deleted portion from the local storage 24.

  In step S115, the binding process 1 described with reference to FIG. 32 is executed, and the process ends.

  That is, since the entire file included in the directory indicated by disc_id is deleted and the Manifest file corresponding to the deleted part is also deleted, the file system merge processing unit 36 cannot find the Manifest file in the binding process. Bind zero directories and zero files (that is, do not bind anything) and terminate the binding process. As a result, the directory / file structure on the optical disc 11 remains the virtual file system. It will be managed as.

  By such processing, the update file downloaded from the server 3 and recorded in the local storage 24 can be deleted as the entire file included in the directory indicated by disc_id.

  Even when a file is deleted on a disk basis, information indicating the current status of the virtual disk (virtual file system) is sent to the server 3 in the same manner as when adding a file or deleting a file base. Information indicating a possible change may be obtained from the server 3 and the deletion process may be performed based on the information.

  Next, the reproduction process and the file system configuration process will be described with reference to the flowchart in FIG. Here, a case where the binding method is static binding will be described.

  In step S141, the optical disc directory management unit 35 determines whether or not the optical disc 11 is loaded. If it is determined in step S141 that the optical disk 11 is not loaded, the process of step S141 is repeated until it is determined that the optical disk 11 is loaded. If it is determined in step S141 that the optical disc 11 is loaded, the optical disc directory management unit 35 reads author_id and Disc_id from the optical disc 11, and reads the read author_id and Disc_id to the local storage directory management unit 34 and the file system merge process. The process proceeds to step S142, and the binding process 1 described with reference to FIG. 32 is executed.

  In step S143, the playback control unit 37 determines whether or not an operation input for instructing playback of content has been received from the user based on the user's operation input supplied from the operation input acquisition unit 32. If it is determined in step S143 that an operation input for instructing content reproduction has not been received, the process proceeds to step S148 described later.

  If it is determined in step S143 that an operation input for instructing playback of content has been received, in step S144, the playback control unit 37 controls the local storage directory management unit 34 and the optical disk directory management unit 35 so that the navigation program The PlayList and SubPlayItem specified as the playback section are acquired, and stream files (AV file, audio file, text subtitle file, etc.) referenced by the acquired PlayList and SubPlayItem are read and supplied to the decoder 26. Here, a time stamp represented by PlayList or SubPlayItem is converted into an address by Clip information, and an AV stream or the like is accessed.

  In step S145, the reproduction control unit 37 controls the decoder 26 to reproduce the content specified by PlayItem.

  In step S146, the operation input acquisition unit 32 determines whether or not an operation input instructing switching of a reproduction title (content to be reproduced) has been received. If it is determined in step S146 that an operation input commanding to change the playback title has not been received, the process proceeds to step S148 described later.

  If it is determined in step S146 that an operation input for instructing the change of the playback title has been received, the operation input acquisition unit 32 supplies a signal corresponding to the user operation input to the optical disc directory management unit 35 to manage the optical disc directory management. The unit 35 reads the author_id and disc_id from the optical disc 11, and outputs the read author_id and disc_id to the local storage directory management unit 34. The process proceeds to step S147, and the binding process 1 described with reference to FIG. 32 is executed. The After the process of step S147 is completed, the process returns to step S144, and the subsequent processes are repeated.

  If it is determined in step S143 that an operation input for instructing playback of content has not been received, or if it is determined in step S146 that an operation input for instructing change of a playback title has not been received, in step S148, The operation input acquisition unit 32 determines whether the user has instructed to add or delete a file.

  If it is determined in step S148 that an instruction to add or delete a file has been issued, in step S149, the data acquisition unit 33, the local storage directory management unit 34, etc., for example, FIG. 31 and FIG. 33 to FIG. As described with reference to, the process of adding or deleting a file is executed.

  If it is determined in step S148 that no file addition or deletion has been instructed, or after the processing in step S149 is completed, the operation input acquisition unit 32 has instructed to update the virtual file system in step S150. Judge whether or not.

  If it is determined in step S150 that the virtual file system update has been commanded, for example, an API (for example, update ()) defined for updating the virtual file system is called. In step S151, FIG. The binding process 1 described above is executed.

  In step S150, when it is determined that the virtual file system update is not instructed, or after the process of step S151 ends, in step S152, the operation input acquisition unit 32 ends the process of the playback device 1 (for example, It is determined whether or not an application termination or power-off of the playback apparatus 1 has been commanded.

  In step S152, when it is determined that the end of the process of the playback device 1 is not instructed, the process returns to step S143, and the subsequent processes are repeated. In step S152, when it is determined that the end of the process of the playback device 1 has been commanded, the process ends.

  By such processing, the data recorded in advance on the optical disc 11 and the data downloaded from the server 3 and stored in the local storage 24 are bound at a predetermined timing to construct a virtual file system. Content is played back based on the file system.

  Through the processing described above, the content update file recorded on the optical disc 11 is downloaded and stored in the local storage 24 of the playback device 1, and the content file recorded on the optical disc 11 and stored in the local storage 24. Update files that have been updated can be handled easily.

  Specifically, a virtual file system is defined as an upper layer of a native file system (a file system of data actually recorded on the optical disc 11 or the local storage 24) possessed by the system of the playback apparatus 1. Then, the file system of the data actually recorded on the optical disk 11 and the local storage 24 is merged to generate a virtual file system. At that time, the Manifest file, which is metadata of the downloaded data, uniquely identifies the optical disc 11 with respect to the author_id that is an identifier for uniquely identifying the content creator and the content creator identified by the author_id. Disc_id that is an identifier for identification is described.

  The disk area of the local storage 24 has a directory structure divided for each content distribution source (content author). Below the disc_id, which is a directory immediately under the author_id, forms a flexible file / directory structure by the content author. be able to. Where the data stored in the local storage 24 is located in the disk area of the local storage 24, that is, the file / directory structure of the downloaded file is stored in the src_file_name field of the Manifest data included in the downloaded data. Described as a path name.

  On the other hand, the directory / file structure of the virtual disk accessible from the application follows the directory / file structure of the optical disk 11. That is, in the dst_file_name field of the Manifest data included in the downloaded data, a path name that can uniquely specify the binding destination in the virtual disk of the file stored in the local storage 24 is actually specified.

  By doing so, the directory / file structure of the local storage 24 is hidden from the application program executed in the playback apparatus 1 or the user.

  It is also possible to delete a part of the file recorded in the local storage 24. After a part of the file is deleted, the binding process is executed again at a predetermined timing to generate a new virtual file system. In addition, when a problem occurs in the file link structure in the virtual file system due to the deletion of the file, a file necessary for solving the problem is extracted and the necessary file is downloaded from the server 3. Can do.

  In the above-described processing, the file download from the server 3 has been described as being performed based on an instruction from the user. However, when the optical disc 11 is mounted on the playback device 1, the server 3 is immediately accessed, It is also possible to download files as necessary.

  For example, as described with reference to FIG. 13, the Index file (Index.bdmv) recorded on the optical disc 11 includes information on a menu for reproducing the optical disc 11. Based on the Index file recorded on the optical disc 11, the playback device 1 plays back all the contents of the optical disc 11, plays back only a specific chapter, repeatedly plays back, displays an initial menu, and the like. A playback menu screen including is displayed on the display device. A MovieObject to be executed when each item is selected can be set in the Index file. When one item is selected from the playback menu screen by the user, the playback device 1 uses the MovieObject set in the Index file. Execute a command.

  FIG. 37 shows the syntax of the Index file (Index.bdmv).

  Type_indicator is a field in which the value of “INDX” encoded based on ISO646 is described.

  The version_number is a 4-character string indicating the version number of Index.bdmv, and a value “0089” encoded based on ISO646 is described.

  Indexes_start_address is a field in which the start address of the Indexes () block is described.

  AppInfoBDMV () describes an individual identifier indicating the supply source of the optical disc 11.

  For Indexes (), for example, processing such as reading a menu, searching for a title, jumping to a predetermined title, or automatically starting when the optical disc 1 is mounted on a playback device is executed. A link to the application (MovieObject) to be executed is described. The syntax of Indexes () will be described later with reference to FIG.

  Padding_word is inserted based on the syntax of Index.bdmv, and is represented by 0 or a positive integer.

  The syntax of Indexes () is shown in FIG.

  The length is a field indicating how many bytes of information are described in Indexes ().

  FirstPlayback is a data block that includes information about a Movie Object that is automatically executed first when the optical disc 11 is loaded in the playback apparatus 1.

  FirstPlayback_mobj_id_ref is a field for designating the value of mobj_id of the Movie Object executed first. mobj_id is an ID uniquely assigned to each Movie Object. Further, in this optical disk 11, when a Movie Object that is automatically executed when the optical disk 11 is mounted on the playback apparatus 1 is not set, that is, when the optical disk 11 is only mounted on the playback apparatus 1, the application is In this field, “0Xffff” is described in this field when any application is executed in response to a command from the user.

  TopMenu () is a data block that includes information on the Movie Object of TopMenu that is called when the user displays a menu screen.

  TopMenu_mobj_id_ref is a field for designating the value of mobj_id of Movie Object of TopMenu. In the optical disc 11, when TopMenu is not set, “0xFFFF” is described in this field.

  number_of_Titles is a field representing the number of titles described in Indexes ().

  Title [title_id] () is a block in which information about each title uniquely distinguished by title_id is described. title_id is assigned from 0.

  Title_playback_type [title_id] is information indicating the playback type of the title specified by the title_id. For example, when the title is a moving image and audio content, playback processing based on the PlayList is executed.

  Title_access_type [title_id] is information indicating whether or not the title specified by the title_id is permitted to be reproduced using Title_Search.

  Title_mobj_id_ref [title_id] is a field for designating the value of mobj_id of the Movie Object in which the title designated by the title_id is entered.

  In FirstPlayback of the Index file (Index.bdmv) described with reference to FIGS. 37 and 38, an application for executing processing for accessing the server 3 and transmitting information indicating the current state of the virtual file system is specified. In this case, when the optical disk 11 is loaded, the playback device 1 immediately accesses the server 3, transmits information indicating the status of its own virtual file system to the server 3, and downloads a file as necessary.

  FIG. 39 is a block diagram showing the configuration of the server 3.

  A CPU (Central Processing Unit) 211 executes various processes according to a program stored in a ROM (Read Only Memory) 212 or a program loaded from a storage unit 218 to a RAM (Random Access Memory) 213. The RAM 213 also appropriately stores data necessary for the CPU 211 to execute various processes.

  The CPU 211, ROM 212, and RAM 213 are connected to each other via a bus 214. An input / output interface 215 is also connected to the bus 214.

  The input / output interface 215 includes an input unit 216 including a keyboard and a mouse, an output unit 217 including a display and a speaker, a storage unit 218 including a hard disk, and a communication unit 219 including a modem and a terminal adapter. It is connected. The communication unit 219 performs communication processing with the playback device 1 via the network 2 including the Internet.

  A drive 220 is connected to the input / output interface 215 as necessary, and a magnetic disk 231, an optical disk 232, a magneto-optical disk 233, a semiconductor memory 234, or the like is appropriately mounted, and a computer program read from them is loaded. The storage unit 218 is installed as necessary.

  FIG. 40 is a block diagram illustrating functions that can be realized by the CPU 211 of the server 3 executing a predetermined program. Here, the server 3 is described as realizing the function described with reference to FIG. 40 when the CPU 211 executes a predetermined program. However, the server 3 has the function described with reference to FIG. It may be realized by hardware.

  The virtual file system information acquisition unit 251 acquires information indicating the current virtual file system state of the playback device 1 supplied from the playback device 1 via the network 2 and supplies the information to the download file determination unit 252.

  The download file determination unit 252 performs playback based on the schedule management unit 253 based on the information supplied from the virtual file system information acquisition unit 251 and indicating the current virtual file system state of the playback device 1. The device 1 selects a file that can be downloaded at present, generates a list thereof, supplies the file to the control information transmission / reception control unit 256, and supplies it to the playback device 1 via the network 2. The download file determination unit 252 receives the supply of information specifying the file desired to be downloaded, which the control information transmission / reception control unit 256 acquired from the playback device 1 via the network 2, and downloads from the content database 254. The content data is read out, or the manifest file to be downloaded is read out from the manifest file database 255, supplied to the file transmission unit 257, and supplied to the playback device 1 via the network 2.

  The schedule management unit 253 manages the schedule used by the download file determination unit 252 to select content that can be downloaded to the playback device 1. The server 3 can, for example, update an advertisement reproduced in the reproduction device 1 by temporally managing selection of content that can be downloaded to the reproduction device 1. For example, the schedule management unit 253 downloads the preview of the movie B up to what month and day with the download of the content of the movie A, but prohibits the download of the movie B before or after what month, In order to download a preview of another movie C, a schedule for whether or not download is possible is managed for each content.

  In addition, for example, the schedule management unit 253 sets a download availability schedule for each content in order to make the commercial film match the season or to download special content only during a predetermined campaign period. Can be managed. Furthermore, the schedule management unit 253, for example, a schedule for whether or not each manifest file can be downloaded in order to make it possible to download the update manifest file to the playback apparatus 1 after a predetermined date and time or only during a predetermined period. Can be managed. As a result, the recognizable file can be changed in the playback device 1.

  The download permission schedule may be, for example, managed as table information such as an ID that can uniquely identify content or a manifest file, a download start date or a downloadable period, or, for example, constructing a database, etc. You may make it manage using another method. In addition, in the case where content (for example, CM) to be downloaded with respect to a predetermined content or a manifest file to be downloaded with the predetermined content is managed temporally, the schedule for download availability is, for example, An ID that can uniquely identify the content, an ID that can uniquely identify the content or manifest file that is downloaded along with the ID, and the download start date or downloadable period of the accompanying downloaded file Etc. may be managed as table information, or may be managed using other methods such as building a database.

  The content database 254 stores content data downloaded from the server 3 to the playback device 1. The manifest file database 255 stores a manifest file that is downloaded from the server 3 to the playback device 1 along with the content.

  The control information transmission / reception control unit 256 controls transmission / reception of control information between the server 3 and the playback device 1 via the network 2. Specifically, the control information transmission / reception control unit 256 controls, for example, transmission of information indicating a list of downloadable contents supplied from the download file determination unit 252 to the playback device 1 or from the playback device 1. The reception of information indicating a file desired to be downloaded is controlled and supplied to the download file determination unit 252. The file transmission unit 257 controls transmission of the downloaded file supplied from the download file determination unit 252 to the playback device 1.

  Next, referring to the arrow chart of FIG. 41, the playback device 1 and the server 3 when the playback device 1 accesses the server 3 as soon as the optical disk 11 is loaded and downloads a file as necessary. The process will be described.

  In step S201, the optical disc drive 22 of the playback device 1 determines whether or not the optical disc 11 is loaded. If it is determined in step S201 that the optical disk 11 is not loaded, the process of step S201 is repeated until it is determined that the optical disk 11 is loaded.

  If it is determined in step S201 that the optical disk 11 is loaded, in step S202, the controller 21 controls the optical disk drive 22 to store data in a predetermined area of the loaded optical disk 11, that is, the above-described Indexes (). The data described in FirstPlayback () is loaded and expanded in the memory 23, and the application specified in FirstPlayback () is read and started. Here, the application specified by the data described in FirstPlayback () is an application that accesses the server 3 and executes processing for downloading a file as necessary.

  In step S203, the local storage directory management unit 34 of the controller 21 controls the data acquisition unit 33 to access the server 3 via the Internet interface 25 and the network 2, and information indicating the current state of the virtual file system, for example, The Manifest_id of the Manifest () section corresponding to the disc_id of the mounted optical disc 11 is transmitted.

  In step S <b> 204, the virtual file system information acquisition unit 251 of the server 3 receives information indicating the current virtual file system state from the playback device 1 via the network 2 and supplies the information to the download file determination unit 252.

  In step S <b> 205, the download file determination unit 252 refers to the supplied information indicating the current state of the virtual file system, and determines whether or not the playback apparatus 1 can update the file. If it is determined in step S205 that the file cannot be updated, the process ends.

  If it is determined in step S205 that the file can be updated, in step S206, the download file determination unit 252 refers to the schedule managed by the schedule management unit 253, and the playback apparatus 1 needs to be updated. Determine if there is content. The schedule management unit 253 manages a schedule used to select content that can be downloaded to the playback device 1.

  If it is determined in step S206 that there is no content that needs to be updated, in step S207, the download file determination unit 252 of the server 3 provides information for notifying the playback apparatus 1 that there is no downloadable file. The control information transmission / reception control unit 256 is supplied. The control information transmission / reception control unit 256 transmits information for notifying that there is no downloadable file to the playback device 1 via the network 2.

  In step S <b> 208, the data acquisition unit 33 of the controller 21 of the playback device 1 receives a notification that there is no downloadable file from the server 3 via the network 2 and supplies the notification to the menu screen display control unit 31. The menu screen display control unit 31 presents to the user that there is no file that can be downloaded this time, for example, by displaying a message. Thereafter, the playback device 1 waits for a user operation input.

  If it is determined in step S206 that there is content that needs to be updated, in step S209, the download file determination unit 252 of the server 3 generates information corresponding to a list of downloadable files, and a control information transmission / reception control unit 256. The control information transmission / reception control unit 256 transmits information corresponding to the list of downloadable files to the playback device 1 via the network 2.

  In step S210, the data acquisition unit 33 of the controller 21 of the playback apparatus 1 receives information corresponding to the list of downloadable files from the server 3 via the network 2, and supplies the information to the menu screen display control unit 31. . The menu screen display control unit 31 causes the display device to display a menu screen that allows the user to select a desired one from the list of downloadable files.

  In step S <b> 211, the operation input acquisition unit 32 of the controller 21 of the playback device 1 determines whether or not an instruction for the content to be added has been received from the user. If it is determined in step S211 that the command has not been received, the process of step S211 is repeated until it is determined that the command has been received.

  If it is determined in step S211 that the command has been received, in step S212, the operation input acquisition unit 32 supplies information representing the content of the update selected by the user to the data acquisition unit 33. The data acquisition unit 33 controls the Internet interface 25 to transmit information indicating the requested file to the server 3 and request download of the file selected by the user.

  In step S <b> 213, the control information transmission / reception control unit 256 of the server 3 receives the signal indicating the file requesting download transmitted from the playback device 1 via the network 2 and supplies the received signal to the download file determination unit 252.

  In step S <b> 214, the download file determination unit 252 reads the requested file from the content database 254 or the manifest file database 255 and supplies it to the file transmission unit 257. The file transmission unit 257 transmits the requested file to the playback device 1 via the network 2.

  In step S215, the data acquisition unit 33 of the controller 21 of the playback device 1 controls the Internet interface 25, and a PlayList file, a ClipInformation file, a ClipAV stream file, an audio file, and a text subtitle stream prepared as download files by the server 3 Files or font files are downloaded, and the local storage directory management unit 34 is notified that these files have been downloaded.

  In step S216, the local storage directory management unit 34 determines whether or not the directory identified by the ID already exists in the local storage 24 based on the author_id and disc_id included in the Manifest () of the downloaded file. If the corresponding directory already exists, the downloaded data file is expanded. If the corresponding directory does not exist, a new directory specified by author_id and disc_id is stored in the local storage 24. Create and unpack the downloaded data file.

  In step S217, the binding process 1 described with reference to FIG. 32 is executed, and the process ends.

  As described above, in the first playback of the Index file (Index.bdmv), when the application that performs the process of accessing the server 3 and transmitting the information indicating the current state of the virtual file system is designated, the playback device 1 When the optical disk 11 is loaded, the server 3 can be accessed immediately, information indicating the status of its own virtual file system can be transmitted to the server 3, and files can be downloaded as necessary.

  Further, as described above, the server 3 manages a schedule used for selecting content that can be downloaded to the playback device 1. Thus, for example, the download of the movie B content is accompanied by downloading the movie B notice for up to what month and day, but the month B and later is prohibited from downloading the movie B notice or another movie is downloaded. C's notice can be downloaded. In addition, in the server 3, in order to make it possible to download the update manifest file to the playback apparatus 1 after a predetermined date and time or only during a predetermined period, the download is performed for each content or for each manifest file. The availability schedule can be managed. As a result, the recognizable file can be changed in the playback device 1.

  In the above-described processing, the content downloaded from the server 3 has been described as being unencrypted. However, the encryption key is stored in the optical disc 11, and a decryption processing unit is newly provided in the playback device. The controller 21 of the playback device 1 includes a function of executing a decryption process using an encryption key, and after the content downloaded from the server 3 is decrypted using the encryption key recorded on the optical disc 11, a binding process is performed. It may be possible to perform.

  FIG. 42 shows a configuration example of a playback apparatus having a decoding processing unit.

  The playback apparatus 301 has basically the same configuration as the playback apparatus 1 described with reference to FIG. 1 except that the decoding processing unit 311 is provided.

  The decryption processing unit 311 receives an encryption key read from the optical disc 11 by the optical disc drive 22 and a data file such as an encrypted content from the local storage 24, and controls the controller 21. Can be decoded and supplied to the memory 23 or the decoder 26.

  Next, processing executed by the playback device 301 and the server 3 in FIG. 42 will be described with reference to the arrow chart in FIG. 43.

  In steps S251 to S253, basically the same processing as the processing executed by the playback device 1 in steps S201 to S203 in FIG.

  That is, when the optical disc 11 is loaded, data recorded in a predetermined area of the loaded optical disc 11 is loaded, the server 3 described in FirstPlayback () is accessed, and a file is stored as necessary. The application for executing the process for downloading is executed, and information indicating the current state of the virtual file system, for example, Manifest_id of the corresponding Manifest () section is transmitted to the server 3.

  In step S 254, the optical disc drive 22 reads the encryption key recorded on the optical disc 11 and supplies it to the decryption processing unit 22. The decryption processing unit 22 holds the supplied encryption key.

  In steps S255 to S266, the playback apparatus 301 and the server 3 execute basically the same processes as those performed by the playback apparatus 1 and the server 3 in steps S204 to S215 of FIG.

  That is, the server 3 receives information indicating the current state of the virtual file system from the playback device 301 via the network 2, and determines whether the file can be updated in the playback device 301. Then, when it is determined that the file can be updated, the schedule managed by the schedule management unit 253 is referred to and it is determined whether there is content that needs to be updated in the playback device 301.

  When it is determined that there is no content that needs to be updated, the server 3 transmits information for notifying that there is no downloadable file to the playback device 301 via the network 2. The playback device 301 receives a notification that there is no downloadable file from the server 3 via the network 2 and displays a message to notify the user that there is no file that can be downloaded this time. Thereafter, the playback device 301 enters a state of waiting for a user operation input.

  When it is determined that there is content that needs to be updated, the server 3 generates information corresponding to the list of files that can be downloaded, and transmits the information to the playback device 301 via the network 2. The playback device 301 receives information corresponding to a list of downloadable files from the server 3 via the network 2 so that the user can select a desired one from the list of downloadable files. The displayed menu screen is displayed on the display device.

  Then, the playback device 301 determines whether or not a command for the content to be added has been received from the user. If it is determined that the command has been received, the playback device 301 stores information indicating the content of the update selected by the user in the server 3. Send to.

  The server 3 receives the signal transmitted from the playback device 301 via the network 2 indicating the file requesting download, reads the requested file from the content database 254 or the manifest file database 255, and requests the requested file. Is transmitted via the network 2.

  Then, the playback device 301 downloads a PlayList file, ClipInformation file, ClipAV stream file, audio file, text subtitle stream file, font file, or the like prepared as a download file by the server 3.

  In step S267, the local storage directory management unit 34 of the controller 21 of the playback device 301 determines whether or not the downloaded file is encrypted.

  When it is determined in step S267 that the downloaded file is encrypted, in step S268, the local storage directory management unit 34 supplies the downloaded file to the decryption processing unit 311. It is determined whether or not decryption is possible with the encryption key recorded in (1).

  If it is determined in step S268 that decryption cannot be performed with the encryption key recorded on the optical disc 11, the local storage directory management unit 34 controls the menu screen display control unit 31 to download it in step S269. An error message for notifying the user that the file cannot be played is output.

  If it is determined in step S268 that decryption can be performed with the encryption key recorded on the optical disc 11, the local storage directory management unit 34 controls the decryption processing unit 311 to download the downloaded file in step S270. Is decrypted.

  If it is determined in step S267 that the downloaded file is not encrypted, or after the processing in step S270 is completed, in step S271, the local storage directory management unit 34 displays the downloaded file Manifest (). Based on the author_id and disc_id included in the file, it is determined whether or not the directory identified by the ID already exists in the local storage 24. If the corresponding directory already exists, it is downloaded to that directory. If a corresponding directory does not exist, a new directory specified by author_id and disc_id is created in the local storage 24, and the downloaded data file is expanded.

  In step S272, the binding process 1 described with reference to FIG. 32 is executed, and the process ends.

  By doing so, for example, even if only the Index.bdmv file and the encryption key are recorded on the optical disc 11, the designated file is attached by attaching the optical disc 11 to the playback device 1. Since it is decrypted based on the encryption key recorded on the optical disk 11 that has been downloaded and loaded, and expanded in the local storage 24 (stored in the file system of the local storage 24), the optical disk 11 will be stored next time. It is possible to reproduce the previously downloaded and expanded content without performing download processing and decryption processing each time. Even if only a part of the content is recorded on the optical disc 11, if the Index.bdmv file for executing the above-described processing and the encryption key are recorded, the optical disc 11 is attached to the playback device 1. As a result, the remaining content data files are automatically downloaded, decrypted based on the encryption key recorded on the mounted optical disk 11, and expanded in the local storage 24 (in the local storage 24). Stored in the file system). That is, even if not all content data is recorded in advance on the optical disc 11 distributed to the user, the above-described processing is executed, so that for the user, the optical disc 11 on which all content data is recorded is stored. In addition to being handled in the same way as when distributed, it is possible to prevent illegal content downloads.

  In this way, the content author distributes the optical disc 11 to the user, so that the content author has a large capacity regardless of the recording capacity of the optical disc 11 (even when the optical disc 11 does not have sufficient capacity). It is possible to provide content.

  In the above processing, the path name in the local storage 24 is specified in the src_file_name field of the Manifest () section of the downloaded file package, and the path name in the virtual file system in the virtual disk is specified in the dst_file_name field. In the src_file_name field, not only the path name in the local storage 24 but also the data path name in the optical disk 11 may be designated.

  For example, in the description of index.bdmv, a part of the files recorded on the optical disc 11 can be transferred to the playback device 1 (or playback device 301, hereinafter) by making it impossible to access a predetermined file. Similarly, it is hidden from the application program executed by the user and the user. At a later date, the server 3 has a Manifest_id corresponding to the optical disc 11 from the server 3 and the src_file_name field specifies the data path name in the optical disc 11 of the concealed file, and the dst_file_name field By downloading a Manifest () section in which a predetermined path name in the virtual file system is downloaded, the application program executed in the playback apparatus 1 downloads a new Manifest () section to the optical disc 11 at the timing when the new Manifest () section is downloaded. Files recorded from the beginning can be handled in the same way as newly downloaded files.

  The schedule management unit 253 manages the download of the Manifest () section in which the path name of the data on the optical disc 1 is specified in the src_file_name field and the predetermined path name in the virtual file system is described in the dst_file_name field. It may be executed when the optical disk 11 is mounted on the playback apparatus 1 within a predetermined period or after a predetermined date and time, or a user using the playback apparatus 1 accesses the server 3 to register It may be possible when a predetermined process such as a process or an accounting process is executed.

  In the src_file_name field, the path name of the data on the optical disc 11 is specified, but when the Manifest () section in which the corresponding dst_file_name field is blank is downloaded and overwritten, the file is stored in the playback device. 1 returns to the state where it cannot be referred to from the application program executed in 1 (that is, the existence of the file cannot be recognized from the application program executed by the playback apparatus 1 or the user). That is, the real file is stored on the optical disc 11, but by making the dst_file_name field blank, it is recognized that this file does not exist in the virtual file system. And can be hidden from the user.

  By using this, for example, by causing the src_file_name field to specify the path name of the data on the optical disk 11 and the dst_file_name field to download the Manifest () section in which the predetermined path name in the virtual file system is described, It is possible to refer to a predetermined file recorded in advance on the optical disc 11, or to download a Manifest file in which the path name of the data in the optical disc 1 is specified in the src_file_name field and the corresponding dst_file_name field is blank. By overwriting the () section, it becomes possible to make it impossible to refer to a predetermined file that can be referred to.

  By doing so, for example, the src_file_name field and the dst_file_name field are described so that a plurality of bonus tracks can be recorded on the optical disc in advance, and thereafter, different bonus tracks can be recognized by the application. The Manifest () section can be downloaded at a specific time and overwritten, allowing users to add or delete different bonus tracks from time to time without having to download large amounts of data frequently. It becomes possible to provide.

  Next, the binding process 2 executed when the path name of the data on the optical disc 11 can be specified in the src_file_name field of the Manifest () section will be described with reference to the flowchart of FIG.

  In step S <b> 301, the local storage directory management unit 34 extracts a corresponding disc_id directory from the downloaded data group recorded in the local storage 24, and supplies the directory to the file system merge processing unit 36.

  In step S302, the file system merge processing unit 36 refers to src_file_name and dst_file_name of the Manifest file.

  In step S303, the file system merge processing unit 36 determines whether or not the path name of the data recorded in the optical disc 11 is described in the src_file_name of the Manifest file.

  If it is determined in step S303 that the path name of the data recorded in the optical disc 11 is described in src_file_name, the file system merge processing unit 36 sends the src_file_name to the optical disc directory management unit 35 in step S304. The path name in the optical disc 11 described in the above is supplied. The optical disc directory management unit 35 accesses predetermined information recorded on the optical disc 11 based on the information of src_file_name.

  In step S303, when it is determined that the path name of the data recorded in the optical disc 11 is not described in src_file_name, or after the process of step S304 ends, the file system merge processing unit 36 in step S305. Binds the native file system to the virtual file system based on src_file_name and dst_file_name referenced in step S302.

  When the path name of the data recorded in the optical disc 11 is not described in src_file_name, the binding process is executed as in the binding process 1 described with reference to FIG. When the path name of the data recorded in the optical disk 11 is described in src_file_name, the file system merge processing unit 36 uses the file recorded in the path indicated by src_file_name of the optical disk 11 as the virtual disk. In the virtual file system of, binding is performed so that the file having the path and file name described in the field of dst_file_name is handled.

  If nothing is described in the dst_file_name field, the file recorded in the path indicated by src_file_name on the optical disc 11 is not bound to the virtual file system.

  The content author records the actual file of the content on the optical disc 11 provided to the user, and the content cannot be accessed (playback the content from the application and the user) by reproducing the optical disc 11 alone, and downloaded. The path name in the optical disk 11 can be specified in the src_file_name field of the Manifest () section of the file package to be specified, and the path name of the virtual file system in the virtual disk can be specified in the dst_file_name field. Therefore, the content author freely sets the path name in the virtual file system of the real file of the content recorded on the optical disc 11 mounted on the playback device 301 by describing the Manifest () section of the downloaded file package. be able to. As a result, even though the file exists on the optical disc 11, the content author can allow the user to access the file or prevent the user from accessing the file.

  Incidentally, as described above, the update file can be recorded not only on the server 3 but also on the removable medium 28 for distribution. In such a case, the controller 21 reads the update file from the removable medium 28 via the drive 27 and writes it in the local storage 24. By doing so, when the playback apparatus 1 cannot connect to the server 3 (for example, when the playback apparatus 1 does not have a connection function with the server 3 or when the playback apparatus 1 cannot connect to the server 3). Data can be updated even if it occurs).

  Even in such a case, basically, the update file is recorded in the local storage 24 in a predetermined file format in the same manner as when the update file is downloaded from the server 3, and the data and binding recorded on the optical disk 11 are recorded. Processing is performed to build a virtual file system so that the updated content is played back.

  As shown in FIG. 45, the data structure of the update file recorded on the removable medium 28 describes media_id capable of individually distinguishing the removable medium 28 directly under the root. For media_id, data having the same configuration as data downloaded from the server 3 described with reference to FIG. 14, which is distinguished by author_id and disc_id, is described. The syntax of the Manifest file and other files below disc_id has the same configuration as the data downloaded from the server 3 described above. In the update file recorded on the removable medium 28, an “others” directory is prepared so that, for example, a predetermined application program and various data can be described.

  As an application program recorded in the “others” directory, for example, there is an application program that executes a process of writing an update file recorded in the removable medium 28 to the local storage 24. In addition, it is preferable to record data necessary for executing the process of writing the update file recorded in the removable medium 28 in the local storage 24 in the “others” directory.

  Further, the process for writing the update file from the removable medium 28 to the local storage 24 may be executed only when the optical disk 11 is mounted on the playback apparatus 1, or the optical disk 11 is mounted on the playback apparatus 1. It may be made executable even if it is not.

  That is, the process for writing the update file from the removable medium 28 to the local storage 24 is realized by the navigation program recorded on the optical disc 11 being executed by the controller 21, and the optical disc 11 is stored in the playback device 1. It may be executable only when it is attached. In addition, the process for writing the update file from the removable medium 28 to the local storage 24 is executed by the controller 21 by a control program prepared in advance in the playback apparatus 1 or recorded in the removable medium 28 (for example, An application program of the same format as the navigation program (recorded in the “others” directory shown in FIG. 45) is executed by the controller 21 so that it can be executed even if the optical disc 11 is not mounted on the playback device 1. You may do it.

  When downloading an update file from the server 3, the optical disk 11 is mounted on the playback device 1, information indicating the current state of the virtual file system is transmitted to the server 3, and data necessary for the update is downloaded. It was made like that. However, when the removable medium 28 is used for providing an update file, the supplied update data cannot be changed depending on the current state of the virtual file system.

  Therefore, for example, as shown in FIG. 46A, in the state where the manifest file and the file # 1 and the file # 2 associated with the manifest file are already recorded in the local storage 24, the file is recorded on the removable medium 28. When the update file including the file # 3 and the file # 4 shown in FIG. 46B is written in the local storage 24, the manifest file is overwritten (rewritten), so that the previously updated file # 1 and A situation occurs in which file # 2 is not referred to by the manifest file.

  In order to prevent the occurrence of such a situation as much as possible, the current manifest file and a manifest that can be overwritten (replaced) on the optical disk 11 or the removable medium 28 so that the previously updated file is not referred to. Information indicating the combination with the file can be recorded.

  For example, as shown in FIG. 47, Japanese captions are associated with manifest file # 1, English captions are associated with manifest file # 2, and French files are associated with manifest file # 3. Subtitles are associated, Japanese and English subtitles are associated with manifest file # 4, Japanese and French subtitles are associated with manifest file # 5, and English file is associated with manifest file # 6. , French, and German subtitles are associated, Japanese, English, and German subtitles are associated with manifest file # 7, and Japanese, English, French, and German subtitles are associated with manifest file # 8 It is known in advance that it is attached, and it can be recognized by the file number what subtitles are associated with other manifest files. That.

  Here, when the manifest file # 1 and the corresponding Japanese subtitle file are currently recorded in the local storage 24 of the playback device 1, the manifest file # 4, the manifest file # 5, the manifest file # 7, or the manifest file Even if data is updated using the removable medium 28 in which the file # 8 is recorded together with the corresponding subtitle stream file, Japanese subtitles can be selected by the user as before. However, when data is updated using the removable media 28 in which other manifest files and corresponding subtitle stream files are recorded, Japanese subtitles are not associated with the rewritten manifest file, so the user After the update using the removable medium 28, Japanese subtitles cannot be selected.

  Therefore, when the correspondence table of the manifest file as shown in FIG. 48 is recorded on the optical disk 11 or the removable medium 28 and the reproducing apparatus 1 updates the data using the removable medium 28, the reproducing apparatus 1 Referring to this correspondence table, the manifest file is rewritten so as not to cause inconvenience, or the user is notified.

  Specifically, the manifest file # 2 associated with the English subtitles is updated using the removable medium 28 while the manifest file # 1 associated with the Japanese subtitles is currently recorded in the local storage 24. If it is prepared as a file, if it is rewritten from manifest file # 1 to manifest file # 2, Japanese subtitles cannot be used. You may be able to present a message such as "Is it possible to use only English subtitles by updating?" Or rewrite from manifest file # 1 to manifest file # 2. Instead, Manifest file # 4 that associates Japanese and English subtitles. To produce similar manifest file, it may be able to overwrite the manifest file # 1.

  Furthermore, when the playback device 1 cannot prevent a failure caused by rewriting the manifest file by generating the manifest file, information indicating the manifest file before rewriting (if the server 3 can distinguish the manifest file). For example, it may be Manifest_id, code information generated based on Manifest_id, or other information). Then, the user uses the playback device 1 that can be connected to the server 3 or an information processing device such as a personal computer, a PDA, or a mobile phone that can be connected to the server 3 to send information indicating the manifest file before rewriting to the server. 3 and downloading the manifest file before rewriting from the server 3, it is possible to return the playback device 1 to at least the state before rewriting.

  Next, file update processing 1 using the removable medium 28 will be described with reference to the flowchart of FIG. The file update process 1 using the removable medium 28 is a reproduction in which the process for writing an update file from the removable medium 28 to the local storage 24 can be executed only when the optical disk 11 is mounted on the reproduction apparatus 1. This is processing executed in the device 1.

  In step S <b> 410, the optical disc 11 is mounted on the playback device 1, the navigation program recorded on the optical disc 11 is read by the optical disc drive 22 and expanded in the memory 23, and the navigation program is started by the controller 21.

  In step S411, the operation input acquisition unit 32 of the controller 21 determines whether or not a file addition using the removable medium 28 has been instructed based on the user's operation input. If it is determined in step S411 that the addition of a file using the removable medium 28 has not been instructed, the process in step S411 is repeated until it is determined that the addition of a file using the removable medium 28 has been instructed.

  If it is determined in step S411 that the addition of a file using the removable medium 28 has been instructed, in step S412, the menu screen display control unit 31 of the controller 21 prompts the user to attach the removable medium 28, or the like. Is output.

  In step S 413, the data acquisition unit 33 determines whether the removable medium 28 is loaded in the drive 27. If it is determined in step S413 that the removable medium 28 is not attached, the process of step S413 is repeated until it is determined that the removable medium is attached.

  If it is determined in step S413 that the removable medium 28 is attached, the data acquisition unit 33 in step S414, the predetermined part of the data recorded in the attached removable medium 28 (for example, a so-called header or Like the TOC, the playback device 1 can read the data, the data structure, the format, and the like on which the playback device 1 determines data, and can be played back by the playback device 1. Determine whether or not.

  If it is determined in step S414 that the mounted removable medium 28 cannot be played back by the playback device 1, the process proceeds to step S425 described later.

  If it is determined in step S414 that the attached removable media 28 can be played back by the playback device 1, the data acquisition unit 33 can execute the attached removable media 28 in the playback device 1 in step S415. It is determined whether or not a simple application program is recorded. If it is determined in step S415 that an application program executable by the playback apparatus 1 is not recorded on the removable medium 28, the process proceeds to step S418 described later.

  If it is determined in step S415 that an application program that can be executed by the playback apparatus 1 is recorded in the removable medium 28, the controller 21 stores the application program recorded in the removable medium 28 in the memory in step S416. 23 is executed. Then, the controller 21 determines whether or not the application program recorded on the removable medium 28 is an application that executes data addition processing. If it is determined in step S416 that the application program recorded on the removable medium 28 is an application for executing data addition processing, the processing proceeds to step S421 described later.

  If it is determined in step S416 that the application program recorded on the removable medium 28 is not an application for executing data addition processing, the controller 21 stores the application program recorded on the removable medium 28 in step S417. Execute. After the processing of the application program recorded on the removable medium 28 is completed, the playback apparatus 1 returns to the state in which the navigation program recorded on the optical disc 11 is executed on the controller 21 again.

  If it is determined in step S415 that an application program executable by the playback device 1 is not recorded on the removable medium 28, or after the process of step S417 is completed, the data acquisition unit of the controller 21 is determined in step S418. In step 33, it is determined whether additional data as described with reference to FIG. 45 is recorded in the mounted removable medium 28, for example. If it is determined in step S418 that additional data is not recorded on the mounted removable medium 28, the process proceeds to step S425 described later.

  If it is determined in step S418 that additional data is recorded on the attached removable medium 28, the data acquisition unit 33, in step S419, adds the additional data recorded on the attached removable medium 28. Read data.

  In step S420, a file update process 1 described later with reference to FIG. 50 is executed, and the process proceeds to step S424 described later.

  If it is determined in step S416 that the application program recorded on the removable medium 28 is an application for executing data addition processing, the application program recorded on the removable medium 28 is executed in step S421. The controller 21 determines whether or not additional data as described with reference to FIG. 45 is recorded on the mounted removable medium 28, for example. If it is determined in step S421 that additional data is not recorded on the mounted removable medium 28, the process proceeds to step S425 described later.

  If it is determined in step S421 that additional data is recorded on the attached removable medium 28, the controller 21 executing the application program recorded on the removable medium 28 in step S422 The additional data recorded in the removable media 28 is read.

  In step S423, a file update process 1 described later with reference to FIG. 50 is executed. After the process of step S423 is completed, that is, after the process of the application program recorded on the removable medium 28 is completed, the navigation program recorded on the optical disc 11 is again executed in the controller 21 in the controller 21. Return to state.

  After the process of step S420 or step S423 is completed, the binding process described with reference to FIG. 32 is executed in step S424, and the process proceeds to step S426.

  If it is determined in step S414 that the mounted removable medium 28 is not playable by the playback apparatus 1, or if it is determined in step S418 that additional data is not recorded on the mounted removable medium 28 Alternatively, if it is determined in step S421 that no additional data is recorded in the attached removable medium 28, the menu screen display control unit 31 of the controller 21 in step S425, for example, “adds data” Error message such as "Please check removable media" is output.

  After the process of step S424 or step S425 is completed, in step S426, the operation input acquisition unit 32 determines whether or not the end of the navigation program has been commanded. If it is determined in step S426 that the navigation program is not terminated, the process returns to step S411, and the subsequent processes are repeated. In step S426, when it is determined that the end of the navigation program is instructed, the process is ended.

  By such processing, the update file recorded on the removable medium 28 is read out by the navigation program recorded on the optical disc 11 or the application program recorded on the removable medium 28 and stored in the local storage 24. Written.

  Next, the file update process 1 executed in step S420 or step S423 in FIG. 49 will be described with reference to the flowchart in FIG.

  Note that the file update process 1 executed in step S423 of FIG. 49 is executed in a state where the data addition process is being executed by the controller 21 executing the application program recorded in the removable medium 28. When the application program recorded on the removable medium 28 executes a data addition process, the controller 21 basically has the same function as that described with reference to FIG. 50 will be described with reference to the functional block diagram described with reference to FIG.

  In step S451, the local storage directory management unit 34 uses the optical disk 11 managed by the optical disk directory management unit 35 or the removable medium 28 from which data can be read by the data acquisition unit 33, for example, using FIG. It is determined whether or not the information indicating the correspondence of the manifest file as described is described. If it is determined in step S451 that information indicating the correspondence of the manifest file is not described, the process proceeds to step S456 described later.

  If it is determined in step S451 that information indicating the correspondence of the manifest file is described, in step S452, the local storage directory management unit 34 records the information on the manifest file in the removable medium 28 based on the information indicating the correspondence of the manifest file. For example, as described with reference to FIG. 46, overwriting of the updated file that has been updated determines whether or not a failure has occurred such that the previously updated file cannot be used. If it is determined in step S452 that no failure has occurred, the process proceeds to step S458 described later.

  If it is determined in step S452 that a failure has occurred, in step S453, the local storage directory management unit 34 indicates the correspondence between the manifest file currently recorded in the local storage 24 and the manifest file described with reference to FIG. Based on the information and the manifest file of the update file recorded on the removable medium 28, it is determined whether or not failure avoidance processing for creating a manifest file that does not cause a failure can be executed. If it is determined in step S453 that the failure avoidance process cannot be executed, the process proceeds to step S456 described later.

  If it is determined in step S453 that the failure avoidance process is executable, in step S454, the local storage directory management unit 34 executes the failure avoidance program and creates a manifest file in which no failure occurs.

  For example, manifest file # 7 and subtitle data that can use Japanese, English, and German subtitles are currently recorded in local storage 24. Removable media 28 includes manifest file # 3 and French. Japanese subtitle data is already recorded, if the user overwrites the local storage with the update file recorded on the removable medium 28 in order to add the subtitle in French, German subtitles cannot be used (manifest file # 3 is not associated with Japanese, English, German subtitle data). In order to prevent this failure, the local storage directory management unit 34 executes a failure avoidance program to create a manifest file # 8 associated with subtitle data in Japanese, English, French, and German, , Recorded in the local storage 24 together with French subtitle data.

  In step S455, the local storage directory management unit 34 replaces the created manifest file with the manifest file recorded in the removable medium 28, stores the corresponding file in the removable medium 28 in the local storage 24, and the processing is performed. 49 returns to step S420 in FIG. 49 and proceeds to step S424, or returns to step S423 and proceeds to step S424.

  If it is determined in step S451 that information indicating the correspondence of the manifest file is not described, or if it is determined in step S453 that failure avoidance processing cannot be executed, the menu screen display control unit 31 in step S456. For example, a warning message such as “Are you sure you want to use English subtitles by this update?” Is notified to the user. Further, the menu screen display control unit 31 may be information indicating the manifest file before rewriting (the server 3 may be information that can distinguish the manifest file. For example, Manifest_id is generated based on the Manifest_id. Code information or other information may be presented to the user. Thus, the user can use the information processing device such as the playback device 1 that can be connected to the server 3 or a personal computer, PDA, or mobile phone that can be connected to the server 3 to display information indicating the manifest file before rewriting. By notifying the server 3 and downloading the manifest file before rewriting from the server 3, it is possible to return the playback device 1 to at least the state before rewriting.

  In step S457, the operation input acquisition unit 32 determines whether data writing to the local storage 24 is permitted based on the operation input from the user who confirmed the warning message. If writing of data to the local storage 24 is not permitted in step S457, the process returns to step S420 in FIG. 49 and proceeds to step S424, or returns to step S423 and proceeds to step S424.

  If it is determined in step S452 that a failure does not occur, or if writing of data to the local storage 24 is permitted in step S457, the local storage directory management unit 34 stores the removable media 28 in step S458. The corresponding file is stored in the local storage 24, and the process returns to step S420 in FIG. 49 and proceeds to step S424, or returns to step S423 and proceeds to step S424.

  By such processing, failure avoidance processing is executed, and a manifest file that does not cause inconsistency between the already updated file and the manifest file is generated and recorded together with the file recorded on the removable medium 28 together with the local storage 24. Or when a failure has occurred due to overwriting of a file recorded on the removable medium 28, the user is notified that there is a possibility that the failure may occur due to overwriting of the file. It is possible to present to the user information that can be used to return the file recorded on the removable medium 28 to the state before being overwritten.

  Next, the file update processing 2 using the removable medium 28 will be described with reference to the flowchart of FIG. The file update process 2 using the removable medium 28 is such that the process for writing the update file from the removable medium 28 to the local storage 24 can be executed even when the optical disk 11 is not attached to the playback device 1. This process is executed in the playback apparatus 1 that is being used.

  In step S <b> 481, the data acquisition unit 33 determines whether or not the removable medium 28 is attached to the drive 27. If it is determined in step S481 that the removable medium 28 is not attached, the process of step S481 is repeated until it is determined that the removable medium is attached.

  If it is determined in step S481 that the removable medium 28 is loaded, in step S482, the controller 21 starts an application program that executes a file update process. This application program is an application program (not recorded on the optical disc 11 or the removable medium 28) of the playback device 1.

  In step S483, the data acquisition unit 33 changes the data configuration, data structure, format, etc. of a predetermined portion (for example, a so-called header or TOC) of the data recorded on the mounted removable medium 28. A portion in which data for determination by the playback device 1 is recorded) is read, and it is determined whether or not the mounted removable medium 28 can be played back by the playback device 1.

  If it is determined in step S483 that the mounted removable medium 28 cannot be played back by the playback device 1, the process proceeds to step S495 described later.

  If it is determined in step S483 that the attached removable media 28 can be played back by the playback device 1, the data acquisition unit 33 can execute the attached removable media 28 in the playback device 1 in step S484. It is determined whether or not a simple application program is recorded. If it is determined in step S484 that no application program executable by the playback apparatus 1 is recorded in the removable medium 28, the process proceeds to step S489 described later.

  In step S484, when it is determined that the application program executable by the playback device 1 is recorded on the removable medium 28, in step S485, the controller 21 executing the application program included in the playback device 1 It is determined whether or not a preparation process for executing the application program recorded on the removable medium 28 is possible. Note that since the apparatus itself may know whether or not the preparation process is possible, in this case, the step of whether or not this preparation process is possible may be omitted.

  For example, if the application program recorded on the removable medium 28 is equivalent to the above-described MovieObject recorded on the optical disk 11 and data corresponding to the Index file is not prepared, the removable medium 28 is stored in the removable medium 28. In order to execute various commands of the recorded application program, data corresponding to the Index file is required. In this case, the preparation process for executing the application program recorded on the removable medium 28 is a process for creating a corresponding Index file. If the optical disk 11 is already loaded in the playback device 1, the index file is created and expanded, and in this case, the preparation process is not necessary.

  If it is determined in step S485 that the preparation process for executing the application program recorded on the removable medium 28 cannot be performed (or if the apparatus cannot perform the preparation process), the process proceeds to step S489 described later.

  If it is determined in step S485 that preparation processing for executing the application program recorded on the removable medium 28 is possible, the controller 21 executing the application program included in the playback device 1 in step S486. Then, a preparation process for executing the application program recorded on the removable medium 28 is executed.

  In step S487, the controller 21 develops and executes the application program recorded in the removable medium 28 in the memory 23. Then, the controller 21 determines whether or not the application program recorded on the removable medium 28 is an application that executes data addition processing. If it is determined in step S487 that the application program recorded on the removable medium 28 is an application for executing data addition processing, the processing proceeds to step S492 described later.

  If it is determined in step S487 that the application program recorded on the removable medium 28 is not an application for executing data addition processing, the controller 21 stores the application program recorded on the removable medium 28 in step S488. Execute. After the processing of the application program recorded on the removable medium 28 is completed, the controller 21 returns to the state in which the application program of the playback device 1 is being executed in the controller 21 again.

  If it is determined in step S484 that the removable medium 28 does not contain an application program that can be executed by the playback device 1, preparation for executing the application program recorded in the removable medium 28 is performed in step S485. If it is determined that the process cannot be performed, or after the process of step S488 ends, in step S489, the data acquisition unit 33 of the controller 21 has been described with reference to, for example, FIG. It is determined whether or not such additional data is recorded. If it is determined in step S489 that additional data is not recorded on the mounted removable medium 28, the process proceeds to step S495 described later.

  If it is determined in step S489 that additional data is recorded on the attached removable medium 28, the data acquisition unit 33, in step S490, adds the additional data recorded on the attached removable medium 28. Read data.

  In step S491, a file update process 2 described later with reference to FIG. 52 is executed, and the process proceeds to step S496 described later.

  If it is determined in step S487 that the application program recorded on the removable medium 28 is an application for executing data addition processing, the application program recorded on the removable medium 28 is executed in step S492. The controller 21 determines whether or not additional data as described with reference to FIG. 45 is recorded on the mounted removable medium 28, for example. If it is determined in step S492 that additional data is not recorded on the mounted removable medium 28, the process proceeds to step S495 described later.

  If it is determined in step S492 that additional data is recorded on the attached removable medium 28, the controller 21 executing the application program recorded on the removable medium 28 in step S493 The additional data recorded in the removable media 28 is read.

  In step S494, file update processing 2 described later with reference to FIG. 52 is executed. After the process of step S494 is completed, that is, after the process of the application program recorded on the removable medium 28 is completed, the application program held by the reproduction apparatus 1 is executed again by the controller 21 in the reproduction apparatus 1. Return to the state.

  If it is determined in step S483 that the mounted removable medium 28 is not reproducible by the playback apparatus 1, or if it is determined in step S489 that additional data is not recorded on the mounted removable medium 28 Alternatively, if it is determined in step S492 that additional data is not recorded on the attached removable medium 28, the menu screen display control unit 31 of the controller 21 in step S495, for example, “adds data” Error message such as "Please check removable media" is output.

  After the process of step S491, step S494, or step S495 is completed, in step S496, the operation input acquisition unit 32 determines whether or not the application program is instructed to end. If it is determined in step S496 that the termination of the application program is not instructed, the process returns to step S483 and the subsequent processes are repeated. If it is determined in step S496 that the end of the application program has been commanded, the process ends.

  By such processing, the update file recorded on the removable medium 28 is read out by the application program recorded in advance on the playback device 1 or the application program recorded on the removable medium 28, and is stored in the local storage. 24 is written.

  In the file update process 2 using the removable medium 28, it is not necessary to mount the optical disc 11 in the playback apparatus 1. Therefore, the binding process described with reference to FIG. This is executed when the optical disk 11 is loaded in the playback apparatus 1.

  Next, the file update process 2 executed in step S491 or S494 in FIG. 51 will be described with reference to the flowchart in FIG.

  Note that the file update process 2 executed in step S491 in FIG. 51 is executed in a state where the data addition process is being executed by the controller 21 executing the application program that the playback apparatus 1 itself has in advance. The The controller 21 basically has the same function as that described with reference to FIG. 6 when the data addition process is executed by an application program that the playback apparatus 1 itself has in advance. Further, the file update process 2 executed in step S494 of FIG. 51 is executed in a state where the data addition process is being executed by the controller 21 executing the application program recorded in the removable medium 28. When the application program recorded on the removable medium 28 executes a data addition process, the controller 21 basically has the same function as that described with reference to FIG. Therefore, the flowchart of FIG. 52 will be described with reference to the functional block diagram described with reference to FIG.

  In step S521, the local storage directory management unit 34 describes information indicating the correspondence of the manifest file as described with reference to FIG. 48 in the removable medium 28 from which data can be read by the data acquisition unit 33. It is judged whether it is done. If it is determined in step S521 that information indicating the correspondence of the manifest file is not described, the process proceeds to step S523 described later.

  When it is determined in step S521 that information indicating the correspondence of the manifest file is described, in step S522, the local storage directory management unit 34 records on the removable medium 28 based on the information indicating the correspondence of the manifest file. For example, as described with reference to FIG. 46, overwriting of the updated file that has been updated determines whether or not a failure has occurred such that the previously updated file cannot be used. If it is determined in step S522 that no failure has occurred, the process proceeds to step S525 described later.

  If it is determined in step S521 that information indicating the correspondence of the manifest file is not described, or if it is determined in step S522 that a failure occurs, in step S523, for example, “By performing this update, "Are you sure you want to use English subtitles only?" Further, the menu screen display control unit 31 may be information indicating the manifest file before rewriting (the server 3 may be information that can distinguish the manifest file. For example, Manifest_id is generated based on the Manifest_id. Code information or other information may be presented to the user. Thus, the user can use the information processing device such as the playback device 1 that can be connected to the server 3 or a personal computer, PDA, or mobile phone that can be connected to the server 3 to display information indicating the manifest file before rewriting. By notifying the server 3 and downloading the manifest file before rewriting from the server 3, it is possible to return the playback device 1 to at least the state before rewriting.

  In step S524, the operation input acquisition unit 32 determines whether data writing to the local storage 24 is permitted based on the operation input from the user who confirmed the warning message. If writing of data to the local storage 24 is not permitted in step S524, the process returns to step S491 in FIG. 51 and proceeds to step S496, or returns to step S494 and proceeds to step S496.

  If it is determined in step S522 that a failure does not occur, or if writing of data to the local storage 24 is permitted in step S524, the local storage directory management unit 34 stores the removable media 28 in step S525. The corresponding file is stored in the local storage 24, and the process returns to step S491 in FIG. 51 and proceeds to step S496, or returns to step S494 and proceeds to step S496.

  By such a process, the user can be notified that a failure may occur due to overwriting of a file, or when a failure occurs due to overwriting of a file recorded on the removable medium 28, the removable medium. It is possible to present to the user information that can be used to return the file recorded in 28 to the state before the file was overwritten.

  The processing for writing the update file recorded on the removable medium 28 to the local storage 24 has been described with reference to FIGS. 45 to 52. The removable medium 28 has the same processing as that of the optical disk 11 described with reference to FIG. Data having the file structure may be recorded. Then, as shown in FIG. 53, the playback device 1 stores the file recorded on the removable medium 28 in the first area of the local storage 24, and stores it in a second area different from the first area. The data having the structure described with reference to FIG. 14 downloaded from the server 3 or the data having the structure described with reference to FIG. 45 recorded on the removable medium 28 is stored, and the optical disk 11 and the local storage are stored. 24, the file system of the data file recorded in the first area of the local storage 24 and the second area of the local storage 24 are processed in the same manner as in the case of binding the file system of the data file recorded in Bind with the file system of the recorded data file It can be.

  That is, the data acquisition unit 33 reads data having the same file structure as that of the optical disk 11 described with reference to FIG. 13 from the removable medium 28 and supplies the data to the local storage directory management unit 34. The local storage directory management unit 34 stores data having the same file structure as that of the optical disc 11 in the first area of the local storage 24. In addition, the data acquisition unit 33 downloads data having the structure described with reference to FIG. 14 downloaded from the server 3 or data having the structure described with reference to FIG. 45 recorded on the removable medium 28. Read and supply to the local storage directory management unit 34. The local storage directory management unit 34 downloads the data having the structure described with reference to FIG. 14 downloaded from the server 3 or the data having the structure described with reference to FIG. 45 recorded on the removable medium 28. Store in the second area of the local storage 24. Then, the file system merge processing unit 36 binds the file systems recorded in the first area and the second area of the local storage 24 to construct a virtual file system. The playback control unit 37 controls the playback process with reference to this virtual file system.

  Also, along with the acquired subtitle stream, Clip AV stream, etc., the playback of those streams is managed, that is, the PlayList file that manages the playback processing using PlayItem, SubPlayItem, and Subpath is downloaded or from other recording media With the acquisition configuration, playback of the acquired stream can be managed using the acquired PlayList file. In that case, for example, if the virtual file system is constructed using the PlayList file that is bound according to the specification of src_file_name and dst_file_name instead of the PlayList existing on the optical disc 11, the operation_type described above is not used. The newly acquired stream can be managed.

Further, in the above-described processing, the PlayList is edited according to the specification of operation_type. For example, a MovieObject that is a navigation program including a PlayList editing program is newly acquired, and the Movieobject is shown in FIG. The PlayList may be automatically edited or edited by the user based on the editing program during the binding process. Further, a Movieobject in which an application program for executing a process for editing and saving a PlayList or a Clip AV stream may be recorded on the optical disc 11 in advance. MovieObject does not necessarily need to store a program therein, and may be configured to call a program stored in another directory (not shown).

  By the way, in the above-described processing, reading of each file constituting a stream to be played using the virtual file system is controlled, but the file to be read does not exist on the constructed virtual file system. Alternatively, a file external acquisition program that is a program independent of the navigation program may be started so that a file to be read from outside the virtual file system can be acquired.

  The content reproduction process will be described with reference to the flowchart in FIG.

  In step S551, the playback control unit 37 controls the local storage directory management unit 34 and the optical disc directory management unit 35 to acquire the PlayList and SubPlayItem specified by the navigation program as playback sections, and the acquired PlayList and SubPlayItem refer to the PlayList and SubPlayItem. A stream file (AV file, audio file, text subtitle file, etc.) is read.

  In step S552, the playback control unit 37 determines whether there is a stream file to be read. If it is determined in step S552 that there is a stream file to be read, the process proceeds to step S558 described later.

  If it is determined in step S553 that there is no stream file to be read, the playback control unit 37 starts an external file acquisition program.

  Here, the file external acquisition program is a program independent of the navigation program activated by the navigation program. While the file external acquisition program is executing a predetermined file acquisition process, the navigation program is in a standby state, and after the file acquisition is executed by the file external acquisition program, the PlayList and PlayItem are used. The replay processing performed can be resumed.

  The file external acquisition program is stored in the local storage 24 of the playback device 1. When activation is instructed by the navigation program processing, the file is read from the local storage 24 by the controller 21 and expanded in the memory 23. It may be executed, or recorded on the optical disk 11 or the removable medium 28 and read out from the optical disk 11 or the removable medium 28 by the controller 21 when the activation is instructed by the processing of the navigation program. It may be developed and executed.

  In step S554, the controller 21 executing the file external acquisition program registers the information regarding the external acquisition destination of the file that did not exist in the local storage 24 of the playback apparatus 1, the optical disc 11, or the removable medium 28. Judge whether or not.

  Note that the information related to the external acquisition destination of the file is, for example, the local storage 24 of the playback device 1 as information managed only by the external acquisition program of the file, separately from the PlayList or PlayItem and the stream file related to the content. Alternatively, it may be recorded in any recording area of the optical disc 11 or the removable medium 28. Further, the information on the source of the above-mentioned Manifest file stored in the local storage 24 may be used as the information regarding the external acquisition destination of the file.

  Further, the information regarding the external acquisition destination of the file may be registered in association with dst_file_name or src_file_name, or may be registered in association with author_id, disc_id, or the like, or For example, it may be registered in different units such as for each content.

  For example, when information related to an external acquisition destination of a file is registered in association with dst_file_name or src_file_name, the file and the information on the registration destination correspond one-to-one. The file can be easily determined and acquired. On the other hand, for example, when information corresponding to a directory including a plurality of files such as author_id and disc_id is registered in association with the external acquisition destination of the file, the information on the file and the registration destination is stored. Since there is no one-to-one correspondence, information indicating the file to be acquired by the playback apparatus 1 is supplied to the external acquisition destination, or the file system at the external acquisition destination is the file system of the optical disc 11, the file in the local storage 24. By having the same configuration as that of the system or the virtual file system, a file to be acquired by the playback apparatus 1 can be acquired.

  If it is determined in step S554 that the information regarding the external acquisition destination of the file that did not exist is not registered, in step S555, the controller 21 executing the file external acquisition program, for example, an external display device In such a case, an error message is output and the process is terminated.

  If it is determined in step S554 that the information regarding the external acquisition destination of the file that did not exist is registered, the controller 21 that executes the external acquisition program for the file in step S556 sets the file that does not exist. Based on the information about the external acquisition destination of the corresponding file, the external acquisition destination of the file is accessed through the Internet interface 25 or the drive 27 to which the removable medium 28 is attached.

  The information regarding the external acquisition destination of the file may specifically be the URL of the server 3 accessed via the Internet 2, or the recording area of the removable medium 28 mounted on the drive 27. It may be an address or a path of a file system, and further, device information of a recording device or other information processing device connected via a predetermined local network, and a storage unit included in those devices. It may be a recording area address or a file system path.

  In step S557, the controller 21 executing the file external acquisition program acquires the file or the corresponding data from the external acquisition destination of the designated file. Then, the controller 21 executing the file external acquisition program resumes the processing of the navigation program.

  Here, the acquisition method of the file or the corresponding data from the external acquisition destination of the designated file is a so-called download in which all the corresponding files are acquired, stored in the local storage 24, etc., and then played back. There may be a so-called streaming reproduction in which data constituting a corresponding file is acquired and sequentially reproduced without being stored in the local storage 24 or the like.

  If it is determined in step S552 that there is a stream file to be read, or after the processing in step S557 ends, in step S558, the playback control unit 37 reads the acquired file or corresponding data into the decoder 26. And the decoder 26 is controlled to reproduce the content, and the process is terminated.

  By such processing, even if a file to be read by PlayList or SubPlayItem is not recorded at a predetermined recording position, if the external acquisition source of the file is registered, the file to be reproduced or its Data constituting the file can be acquired and reproduced.

  The file external acquisition program is described as being a program independent of the navigation program, but may be included in the navigation program as a subroutine program, for example.

  In the processing described with reference to the flowchart of FIG. 54, if the file to be read does not exist on the constructed virtual file system, the file external acquisition program that is a program independent of the navigation program is started. In the above description, the file to be read from outside the virtual file system has been described. For example, when the file to be read or the folder or directory including the file does not exist on the constructed virtual file system, Start a program that executes processing to acquire a file or a folder or directory that contains a file that is an independent program from the navigation program, and read it from outside the virtual file system Rubeki file or it may be able to get the folder or directory containing the file, of course.

  In the playback apparatus 1, as described above, the local storage 24 may be configured by a semiconductor memory, and the local storage configured by the semiconductor memory may be detachable from the playback apparatus 1. In addition, the same data as in the content distribution file format when the content author distributes content as described with reference to FIG. 17 is stored in the removable medium 28 that can be attached to the drive 27 as shown in FIG. By recording in the directory structure described above, the file system of the data recorded on the removable medium 28 and the data recorded on the optical disk 11 can be stored without storing the data in the local storage 24. Bind the file system as described above. It may be can be.

  Further, both the local storage 24 and the removable medium 28 are made to record the content data and data necessary for reproduction thereof (for example, PlayList, SubPlayItem, or Manifest file) with the directory structure described with reference to FIG. As described above, the file system of data recorded in the local storage 24, the file system of data recorded on the removable medium 28, and the file system of data recorded on the optical disc 11 are as described above. You may make it possible to make it bind. In such a case, by applying the above-described processing, for example, the file system of the data recorded on the local storage 24 and the file system of the data recorded on the optical disc 11 are bound, and the first virtual file A system is generated, and a file system of data recorded on the removable medium 28 and the first virtual file system are bound to generate a second virtual file system.

  Next, with reference to FIG. 55 and FIG. 56, a method of manufacturing an optical disc on which data that can be reproduced by the reproducing apparatus 1 is recorded will be described. Here, the recording medium is illustrated and illustrated as an optical disk, and the recording medium in the figure corresponds to the optical disk 11 or the removable medium 28 in FIG. If the removable medium 28 is other than a disk-shaped recording medium, data that can be reproduced by the reproducing apparatus 1 is recorded on the recording medium in the same manner by a known recording medium manufacturing method.

  That is, as shown in FIG. 55, a master disc made of glass or the like is prepared, and a recording material made of photoresist or the like is applied thereon. As a result, a recording master is produced.

  Then, as shown in FIG. 56, video data in a format that can be played back by the playback device 1 and encoded by the encoding device (video encoder) is stored in a temporary buffer in the software production processing unit, and the audio encoder The encoded audio data is stored in the temporary buffer, and data other than the stream (for example, Indexes, Playlist, PlayItem, etc.) encoded by the data encoder is further stored in the temporary buffer. Video data, audio data, and data other than the stream stored in each buffer are multiplexed together with a synchronization signal by a multiplexer (MPX), and an error correction code is added by an error correction code circuit (ECC). Is done. Then, a predetermined modulation is applied by a modulation circuit (MOD), software that is once recorded on, for example, a magnetic tape or the like according to a predetermined format and can be played back by the playback device 1 or recorded on the removable medium 28 Is produced.

  This software is edited (premastered) as necessary, and a signal in a format to be recorded on the optical disc is generated. In response to this recording signal, the laser beam is modulated, and this laser beam is irradiated onto the photoresist on the master. Thereby, the photoresist on the master is exposed in accordance with the recording signal.

  Then, this master is developed and pits appear on the master. The master plate thus prepared is subjected to a process such as electroforming to produce a metal master plate in which pits on the glass master plate are transferred. A metal stamper is further produced from this metal master, and this is used as a molding die.

  A material such as PMMA (acrylic) or PC (polycarbonate) is injected into this molding die by, for example, injection and fixed. Alternatively, 2P (ultraviolet curable resin) or the like is applied on the metal stamper and then cured by irradiation with ultraviolet rays. Thereby, the pits on the metal stamper can be transferred onto the replica made of resin.

  A reflective film is formed on the replica thus generated by vapor deposition or sputtering. Alternatively, a reflective film is formed on the generated replica by spin coating.

  Thereafter, the inner and outer diameters of the disk are processed, and necessary measures such as bonding two disks are performed. Further, a label is attached or a hub is attached and inserted into the cartridge. In this way, the optical disk 11 or the removable medium 28 on which data reproducible by the reproducing apparatus 1 is recorded is completed.

  The series of processes described above can also be executed by software. The software is a computer in which the program constituting the software is incorporated in dedicated hardware, or various functions can be executed by installing various programs, for example, a general-purpose personal computer For example, it is installed from the program storage medium.

  As shown in FIG. 1, the program storage medium includes a magnetic disk (including a flexible disk) on which a program is recorded, an optical disk (CD-ROM) distributed to provide a program to a user separately from a computer. (Including Compact Disk-Read Only Memory), DVD (Digital Versatile Disk), magneto-optical disk (including MD (Mini-Disk) (trademark)), or removable medium 28 made of semiconductor memory, etc. Instead, it is configured by a memory 23 such as a ROM or a RAM in which a program is recorded and a local storage 24 such as a hard disk, which are provided to the user in a state of being incorporated in the apparatus main body in advance.

  In addition, in this specification, the step of describing the program recorded in the program storage medium is not limited to the processing performed in time series according to the described order, but is not necessarily performed in time series. Or the process performed separately is also included.

  In the present specification, the term “system” represents the entire apparatus constituted by a plurality of apparatuses.

  The embodiment of the present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the gist of the present invention.

It is a block diagram which shows the structure of the reproducing | regenerating apparatus in 1st Embodiment to which this invention is applied. It is a figure which shows the example of the application format on the recording medium with which the reproducing | regenerating apparatus in 1st Embodiment to which this invention is applied is mounted | worn. It is a figure for demonstrating a different example of the example of the application format on the recording medium with which the reproducing | regenerating apparatus to which this invention is applied is mounted | worn. It is a figure for demonstrating the state by which the file was downloaded. It is a figure for demonstrating the structure of AV stream. It is a functional block diagram for demonstrating the function of the controller of FIG. It is a figure for demonstrating a virtual file system. It is a figure for demonstrating a virtual file system. It is a figure for demonstrating the directory structure of a local storage. It is a figure which shows the syntax of a Manifest file. It is a figure for demonstrating the value which can be designated to operation_type. It is a figure for demonstrating the value which can be designated to permission contained in Manifest (). It is a figure for demonstrating the example of the file system of an optical disk. 3 is a diagram for explaining an example of a file system of a local storage 24. FIG. It is a figure for demonstrating designation | designated of a path name. It is a figure for demonstrating the example of the directory / file structure in a virtual disk. It is a figure for demonstrating the definition of the file format for content distribution when a content author distributes content. It is a figure for demonstrating the case where MainPath is added with respect to the content currently recorded on the optical disk with which the reproducing | regenerating apparatus was mounted | worn. It is a figure for demonstrating the case where MainPath is added with respect to the content currently recorded on the optical disk with which the reproducing | regenerating apparatus was mounted | worn. FIG. 10 is a diagram for describing a case where a SubPath is added to content recorded on an optical disc mounted on a playback device. FIG. 10 is a diagram for describing a case where a SubPath is added to content recorded on an optical disc mounted on a playback device. FIG. 38 is a diagram for describing a case where a SubPlayItem is added to content recorded on an optical disc attached to a playback device. FIG. 38 is a diagram for describing a case where a SubPlayItem is added to content recorded on an optical disc attached to a playback device. FIG. 25 is a diagram for describing a case where SubPlayItem is replaced with content recorded on an optical disc mounted on a playback device. FIG. 25 is a diagram for describing a case where SubPlayItem is replaced with content recorded on an optical disc mounted on a playback device. FIG. 10 is a diagram for describing a case where a Clip is added to content recorded on an optical disc mounted on a playback device. FIG. 10 is a diagram for describing a case where a Clip is added to content recorded on an optical disc mounted on a playback device. It is a figure for demonstrating states, such as PlayList after the addition update of a file is performed. It is a figure for demonstrating states, such as PlayList after the addition update of a file is performed. It is a figure which shows the example of the list | wrist of the file which can be deleted shown to a user. It is a flowchart for demonstrating a file base addition and update process. 10 is a flowchart for explaining binding processing 1; It is a flowchart for demonstrating a disk base addition and update process. It is a flowchart for demonstrating a file-based deletion process. It is a flowchart for demonstrating a disk-based deletion process. It is a flowchart for demonstrating a reproduction | regeneration process and a file system structure process. It is a figure which shows the syntax of an Index file (Index.bdmv). It is a figure which shows the syntax of Indexes (). 3 is a block diagram showing a configuration of a server 3. FIG. FIG. 4 is a functional block diagram for explaining functions of the server 3. It is an arrow chart for demonstrating the process of a reproducing | regenerating apparatus and a server. It is a figure which shows the structural example of the reproducing | regenerating apparatus which has a decoding process part. It is an arrow chart for demonstrating the process of a reproducing | regenerating apparatus and a server. 10 is a flowchart for explaining binding processing 2; It is a figure explaining the file structure of the update file recorded on a removable medium. It is a figure explaining the failure which may generate | occur | produce by the update using a removable medium. It is a figure explaining the failure which may generate | occur | produce by the update using a removable medium. It is a figure explaining the example of the relationship between the manifest file and the language of the subtitle which can be referred. It is a figure explaining the correspondence table of a manifest file. It is a flowchart for demonstrating the update process 1 of the file using a removable medium. 10 is a flowchart for explaining file update processing 1; It is a flowchart for demonstrating the update process 2 of the file using a removable medium. 10 is a flowchart for explaining file update processing 2; It is a figure explaining the binding of the file system of the data file recorded on the 1st area | region and 2nd area | region of local storage. It is a flowchart for demonstrating a content reproduction process. It is a figure for demonstrating manufacture of the recording medium which recorded the data which can be reproduce | regenerated with a reproducing | regenerating apparatus. It is a figure for demonstrating manufacture of the recording medium which recorded the data which can be reproduce | regenerated with a reproducing | regenerating apparatus.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 Playback apparatus, 11 Optical disk, 21 Controller, 22 Optical disk drive, 23 Memory, 24 Local storage, 26 Decoder, 31 Menu screen display control part, 32 Operation input acquisition part, 33 Data acquisition part, 34 Local storage directory management part, 35 Optical disk directory management unit, 66 file system merge processing unit, 37 playback control unit, 252 download file determination unit, 253 schedule management unit, 301 playback device, 311 decoding processing unit

Claims (5)

In a playback device for playing back an AV stream using a first data group and a second data group recorded on an optical disc,
First acquisition means for acquiring the first data group;
Second acquisition means for acquiring a second data group reproduced together with the first data group;
Storage means for storing the second data group acquired by the second acquisition means;
First information indicating a path of the second data group in the directory structure of the storage unit from the second data group stored in the storage unit, and a virtual file of the second data group Extraction means for extracting second information indicating a path in the system;
Detecting means for detecting a directory structure of the first data group;
Based on the directory structure of the first data group detected by the detection means, and the first information and the second information extracted by the extraction means, the first data group and the first data group Virtual file system generation means for generating the virtual file system including at least a part of each of the two data groups;
A playback apparatus comprising: a playback unit that reads the acquired first data group and the second data group based on the virtual file system and plays back the AV stream. In a playback method of a playback device for playing back an AV stream using a first data group and a second data group recorded on an optical disc,
Obtaining a second data group to be reproduced together with the first data group;
Storing the acquired second data group in a storage unit;
From the second data group stored in the storage unit, first information indicating a path of the second data group in the directory structure of the storage unit, and a virtual file of the second data group Extracting second information indicating a path in the system;
Detecting a directory structure of the first data group;
Based on the detected directory structure of the first data group, and the extracted first information and second information, at least each of the first data group and the second data group. Generating the virtual file system including a portion;
A reproduction method comprising the steps of: reading out the first data group and the second data group based on the virtual file system and reproducing the AV stream. A program for causing a computer to execute a process of reproducing an AV stream using a first data group and a second data group recorded on an optical disc,
Obtaining the second data group to be reproduced together with the first data group;
Storing the acquired second data group in a storage unit;
First information indicating a path of the second data group in the directory structure of the storage unit from the second data group stored in the storage unit, and a virtual file of the second data group Extracting second information indicating a path in the system;
Detecting a directory structure of the first data group;
Based on the detected directory structure of the first data group, and the extracted first information and second information, at least each of the first data group and the second data group. Generating the virtual file system including a portion;
A program for causing a computer to execute a process including a step of reading the first data group and the second data group based on the virtual file system and reproducing the AV stream.   A program storage medium in which the program according to claim 3 is stored. A playback device for playing back an AV stream based on information recorded on a removable optical disk;
In a data distribution system configured by a data distribution device that distributes data to the playback device,
The playback device
Detecting means for detecting a directory structure of the first data group recorded on the optical disc;
Data acquisition means for acquiring a second data group distributed from the data distribution device;
First storage means for storing the second data group acquired by the data acquisition means;
The first data group directory structure of the first data group detected by the detection means, and the first information indicating the path in the directory structure of the storage means of the second data group and the virtual group of the second data group A virtual for generating the virtual file system including at least a part of each of the first data group and the second data group based on attribute information including second information indicating a path in the file system A file system generating means, and
The data distribution device includes:
Second storage means for storing a plurality of the second data groups;
Schedule management means for managing a schedule of distribution of the second data group to the playback device;
Selection means for selecting, based on the schedule managed by the schedule management means, a plurality of the second data groups stored in the second storage means that can be distributed to the playback device. A data distribution system comprising:

Images