Audio playback apparatus and method for resuming interrupted playback recording Number:6,832,293 from the United States Patent and Trademark Office (PTO) owispatent A semiconductor memory card stores a plurality of audio objects (AOBs) that compose a plurality of tracks and playlist information showing a reproduction order for the tracks. The semiconductor memory card also stores, as resume information (PLMG_RSM_PL), (1) a Playlist_Number showing which playlist information was used the last time playback was performed for the semiconductor memory card, (2) a Track_Number showing the last track to be played back, and (3) a Playback_Time showing a position at which where playback was stopped as a time expressed in relation to the start of the track.<H interrupted, recording, Audio, playback, , 6832293.html, Patent, pto, 6832293

Title: Audio playback apparatus and method for resuming interrupted playback recording

Abstract: A semiconductor memory card stores a plurality of audio objects (AOBs) that compose a plurality of tracks and playlist information showing a reproduction order for the tracks. The semiconductor memory card also stores, as resume information (PLMG_RSM_PL), (1) a Playlist_Number showing which playlist information was used the last time playback was performed for the semiconductor memory card, (2) a Track_Number showing the last track to be played back, and (3) a Playback_Time showing a position at which where playback was stopped as a time expressed in relation to the start of the track.

Patent Number: 6,832,293 Issued on 12/14/2004 to Tagawa, et al.

Inventors: Tagawa; Kenji (Katano, JP); Matsushima; Hideki (Studio City, CA); Hirota; Teruto (Moriguchi, JP); Ishikawa; Tomokazu (Toyonaka, JP); Inoue; Shinji (Neyagawa, JP); Kozuka; Masayuki (Arcadia, CA)
Assignee: Matsushita Electric Industrial Co., Ltd. (Osaka-fu, JP)

Appl. No.: 580909

Filed: May 26, 2000

Foreign Application Priority Data


May 28, 1999 [JP]			11-149893
Aug 24, 1999 [JP]			11-236724
Dec 28, 1999 [JP]			11-372605

Current U.S. Class: 711/115 ; 369/30.36; 369/83; 711/103; 711/111; 711/4; 711/5

Field of Search: 711/4,5,114,115,103 369/30.36,83

References Cited [Referenced By]

U.S. Patent Documents


5122999	June 1992	Kimura et al.
5510924	April 1996	Terui et al.
5689704	November 1997	Yoshida et al.
6188650	February 2001	Hamada et al.
6199076	March 2001	Logan et al.
6388961	May 2002	Ijichi
6434103	August 2002	Shitara et al.
6606707	August 2003	Hirota et al.

Foreign Patent Documents


0 5233 452	Jan., 1993	EP
0 883 130	Dec., 1998	EP
10-097766	Apr., 1998	JP

Other References

"Let's Play with MP3", DOS/Vmagazine, Soft Bank Publishing, Mar., 1998. (partial translation)..

Primary Examiner: Nguyen; T
Attorney, Agent or Firm: Wenderoth, Lind & Ponack, L.L.P.

Claims

What is claimed is:

1. A semiconductor memory card storing: an audio sequence in which a plurality of audio objects are arranged; resume information including a type 1 resume position set according to a user operation, and including, using time information, a type 2 resume position that was automatically set when playback of the audio sequence last stopped; and a plurality of pieces of entry information, each of which is respectively associated with a different audio object, each piece of entry information showing at least one entry position in the respectively associated audio object, adjacent entry positions being separated by an interval equivalent to y seconds, wherein each audio object includes a plurality of audio frames, each audio frame has a reproduction time of x seconds and comprises a header part and a data part, the data part having been compressed by a variable-length encoding method, and the y seconds are not less than twice the x seconds.

2. A semiconductor memory card in accordance with claim 1 further storing at least one piece of playback route information, each of which defines a playback route by including identification information of at least one audio object and a playback position of the at least one audio object in the playback route, wherein the resume information further includes specifying information that specifies one piece of playback route information, and the resume information shows the type 1 resume position by using a piece of identification information and a playback position of an audio object in the specified piece of playback route information, and shows the type 2 resume position by using the time information combined with a piece of identification information and a playback position of an audio object in the specified piece of playback route information.

3. A semiconductor memory card in accordance with claim 2, further storing a piece of supplementary resume information respectively corresponding to each piece of playback route information, wherein each piece of supplementary resume information shows a position in an audio object from which playback should start when audio objects are to be played back in accordance with the respectively corresponding piece of playback route information, using the time information combined with a piece of identification information of the audio object from which playback should start, and each resume position shown by the resume information is one of a plurality of positions shown by a plurality of pieces of supplementary resume information.

4. A semiconductor memory card in accordance with claim 3, wherein a first value is set in each piece of supplementary resume information when playback is complete for all audio objects whose identification information is indicated by the respectively corresponding piece of playback route information, and a second value, which is represented by the time information combined with a piece of identification information of an audio object, is set in each piece of supplementary resume information when playback is not complete for all audio objects whose identification information is indicated by the respectively corresponding piece of playback route information.

5. A playback apparatus for a semiconductor memory card that stores (1) an audio sequence in which a plurality of audio objects are arranged, (2) resume information including a resume position for use when playback of the audio sequence resumes within the audio sequence, and (3) a plurality of pieces of entry information, each of which is respectively associated with a different audio object, each piece of entry information showing at least one entry position in the respectively associated audio object, adjacent entry positions being separated by an interval equivalent to y seconds, the playback apparatus comprising: a receiving unit operable to receive, from a user, a first playback operation specifying one of the audio objects or a second playback operation that does not specify any of the audio objects; and a playback unit operable to play back the specified audio object when the receiving unit has received the first playback operation, and read the resume information from the semiconductor memory card and play back the audio sequence starting from the resume position shown by the resume information when the receiving unit has received the second playback operation, wherein the playback unit, when resuming a playback from an audio object, (a) detects, when the audio object has a plurality of entry positions, an entry position that is before and closest to the resume position, and (b) detects an audio frame corresponding to the resume position by referring to header parts of audio objects after the detected entry position.

6. The playback apparatus of claim 5, wherein the playback unit detects the audio frame corresponding to the resume position by: (1) acquiring a size of an audio frame u from the audio frame u; (2) adding a playback time period of the audio frame u to a playback time v; and (3) accessing an audio frame that follows the audio frame u, based on the acquired size of the audio frame u, and recognizing the accessed audio frame as the audio frame u, and wherein the audio frame u represents an audio frame that exists immediately after the detected entry position, and the playback time v represents a playback time indicated by a piece of entry information corresponding to the audio object.

7. A recording apparatus for a semiconductor memory card, the recording apparatus comprising: a receiving unit operable to receive an operation made by a user; a playback unit operable to play back audio objects included in an audio sequence when the received operation is a playback operation; and a recording unit operable to specify, when the received operation is a stop operation, a resume position based on a playback time corresponding to a playback position where the user made the stop operation, the resume position showing where playback of the audio sequence should be resumed, and record resume information including the resume position onto the semiconductor memory card.

8. A playback method for a semiconductor memory card that stores (1) an audio sequence in which a plurality of audio objects are arranged, (2) resume information including a resume position for use when playback of the audio sequence resumes within the audio sequence, and (3) a plurality of pieces of entry information, each of which is respectively associated with a different audio object, each piece of entry information showing at least one entry position in the respectively associated audio object, adjacent entry positions being separated by an interval equivalent to y seconds, the playback method comprising: a receiving operation of receiving, from a user, a first playback operation specifying one of the audio objects or a second playback operation that does not specify any of the audio objects; and a playback operation of playing back the specified audio object when the receiving step operation has received the first playback operation, and reading the resume information from the semiconductor memory card and playing back the audio sequence starting from the resume position shown by the resume information when the receiving operation has received the second playback operation, wherein the playback operation, when resuming a playback from an audio object, (a) detects, when the audio object has a plurality of entry positions, an entry position that is before and closest to the resume position, and (b) detects an audio frame corresponding to the resume position by referring to header parts of audio objects after the detected entry position.

9. The playback method of claim 8, wherein the playback operation detects the audio frame corresponding to the resume position by: (1) acquiring a size of an audio frame u from the audio frame u; (2) adding a playback time period of the audio frame u to a playback time v; and (3) accessing an audio frame that follows the audio frame u, based on the acquired size of the audio frame u, and recognizing the accessed audio frame as the audio frame u, and wherein the audio frame u represents an audio frame that exists immediately after the detected entry position, and the playback time v represents a playback time indicated by a piece of entry information corresponding to the audio object.

10. A recording method for a semiconductor memory card, the recording method comprising: receiving an operation made by a user; playing back audio objects included in an audio sequence when the received operation is a playback operation; and specifying, when the received operation is a stop operation, a resume position based on a playback time corresponding to a playback position where the user made the stop operation, the resume position showing where playback of the audio sequence should be resumed, and recording resume information including the resume position onto the semiconductor memory card.

Description

This application is based on application Nos. H11-149893, H11-236724, and H11-372605 filed in Japan, the contents of which are hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a semiconductor memory card that stores audio data, still image data and control data, and to a playback apparatus, recording apparatus, playback method, recording method, and computer-readable recording medium relating to such a semiconductor memory card. In particular, the present invention relates to improved storage of audio data and control data distributed as contents by a content distribution service, such as an electronic music distribution service.

2. Description of Background Art

Electronic music distribution enables users to purchase and receive music contents (e.g., songs and albums) via the Internet. Such technology has the potential to greatly increase the market for recorded music and is gradually becoming possible as the necessary hardware infrastructure is implemented. One way to store music contents that are obtained from an electronic music distribution service is on semiconductor memory cards whose portability makes them ideal. Accordingly, a great increase is expected in the demand for such cards.

Various kinds of semiconductor memory cards are available, such as Flash ATA cards and Compact Flash cards. Music contents can also be stored onto disc media, such as CD-R (Compact Disc-Recordable) or MiniDisc (MD). While there are a great variety of recording media that can be used for recording music contents, there are only a limited number of methods for indicating where the playback of a music content (track) should start. This operation is generally performed according to one of the following patterns.

When a music album is composed of a plurality of music contents (tracks), there are two main methods for indicating where the playback should start. The first method has the playback start from the first track in the album. The second method has the user indicate a track number and then has the playback start from the beginning of the indicated track.

In the first of these methods, the playback always starts with the same track and continues through all of the tracks in the album in the same order. If the user stops the playback midway through the album, recommencing the playback according to this method will result in the playback apparatus returning to the first track. The user will therefore end up having to listen to tracks that have just been played.

In the second method, the playback starts from the track indicated by the user. When the user stops the playback at a given point in the album and then starts playback once again, the user can have the playback restart from any track, such as the track following the track where playback was stopped. This means that the user does not have to listen to the tracks from the start once more. In this latter case, however, the user will still have to make several operations, such as inputting a track number. This can be troublesome, especially if the user does not know which track corresponds to which track number. In such cases, the user may indicate the wrong track, which will then be played back by the playback apparatus.

As described above, when playback is stopped and then recommenced, the two methods currently used either force the user to listen to all of the tracks in order from the beginning or to input a track number for the track from which the playback should start. This is far from ideal.

The following two methods are also sometimes used to indicate a position at which playback should commence. A third method has the user indicate a move of the playback position to a desired start time within a desired track using a forward or backward search function provided by a playback apparatus. A fourth method has the user indicate a desired track and a desired position within this track using a jog dial (or the like) and then commences reproduction from this position. Since both methods have the user indicate how far the playback previously progressed, they have the same drawback as the second method described above.

Current MiniDisc (MD) playback apparatuses use a reproduction method that indicates the playback position in a more user-friendly manner than the first to fourth methods given above.

When the user stops the playback of an MD, resume information showing the position where playback stopped is recorded in a nonvolatile memory in the MD player. When the user indicates playback of the same MD, the playback of the tracks recorded on the MD starts at the position given in the resume information.

The resume information is recorded in the MD player in a nonvolatile manner so that an interruption to the power supply does not result in the loss of the information. This means that the user can listen to part of a music album, turn off the player, and still have the playback resume at the position where playback was stopped. In this case, the user does not have to repeatedly listen to the tracks at the start of the album as in the first method, or to have to input a track number as in the second method, making this an ideal way to listen to all of the tracks included in an album.

With an MD, however, the resume information showing how far an album has been played back is stored within the hardware of the MD player. Accordingly, there is the problem that when an MD is ejected from a player and inserted into another player, the second player will play back the tracks on the MD starting from the first track in the album, in the same way as the first method.

As a specific example, when a user listens to some of the tracks on an album using a first playback apparatus, stops the playback, and then transfers the disc to another playback apparatus, this second playback apparatus will not store resume information showing the position reached by the playback of this disc. As a result, the playback will start from the start of the album and so make the user listen to the same tracks again.

Since discs are rarely transferred from one player to another during the playback of an album, the playback returning to the start of the album may not be such a significant problem. When the album is subjected to electronic music distribution before being recorded onto a recording medium, however, it is believed that there will be many cases where an album will be partially played back on one player and then transferred to another.

Electronic music distribution is achieved by having a computer owned by the user download a music album from a server computer operated by a record label. The user can then have the downloaded album played back on their computer. Since modern personal computers are capable of playing back music contents, users can listen to albums they have bought on their computer. Assume that the user listens to the album on a portable playback apparatus after listening to it on his/her computer.

In this case, the portable playback apparatus cannot know how far playback by the computer progressed, so that the album will be played back once again from the start. As the user will be subjected to the same songs that were played back by the computer, the user is likely to tire of the album quicker than if all of the tracks were played back.

As recording media become smaller and lighter, though larger in capacity, it becomes increasingly possible to record albums containing large numbers of tracks onto a single recording medium. It is believed that such a recording medium will often be transferred between playback apparatuses. If the playback returns to the beginning after a large number of tracks have been played, this will be very annoying for listeners.

SUMMARY OF THE INVENTION

It is a first object of the present invention to provide a semiconductor memory card that enables playback to be resumed from a previously stopped position without the same recorded material being played back and without a user having to indicate the playback position, even when the semiconductor memory card has been transferred between playback apparatuses.

It is a second object of the present invention to provide a semiconductor memory card that enables a playback apparatus to recommence the playback of an album that was commenced on a different playback apparatus without the same recorded material being played back.

The first object can be achieved by a semiconductor memory card, storing: an audio sequence in which a plurality of audio objects are arranged; and resume information showing a resume position for use when playback of the audio sequence resumes midway through the audio sequence.

Assume that an audio sequence corresponds to a music album, and that the user listens to a first part of the album on a playback apparatus. If the user then transfers the semiconductor memory card to another playback apparatus, this playback apparatus will be able to recommence the playback of the album at the stopped position by referring to the playback resume position shown by the resume information.

The resumption of playback based on the resume information does not require the user to make any particular operation. This means that the user does not have to go to the trouble of indicating a track (audio object) when transferring the semiconductor memory card to another playback apparatus.

The resume information may include at least one of type 1 position information and type 2 position information, the type 1 position information showing a type 1 resume position set according to a user operation, and the type position information showing a type 2 resume position that was automatically set when playback of the audio sequence last stopped.

Here, each audio object in the audio sequence may be provided with unique identification information, the type 1 position information showing the type 1 resume position using the identification information of one of the audio objects, and the type 2 position information showing the type 2 resume position using the identification information of one of the audio objects and time information showing an offset from a start of the one of the audio objects to the type 2 resume position.

The second object is achieved by the above construction. The type 2 position information includes an offset from the start of an audio object. When the semiconductor memory card is transferred between playback apparatuses, the second playback apparatus can commence playback at a position immediately following a point where playback by the first playback apparatus was stopped. This means that a user can start to listen to an album on a first playback apparatus, stop the playback, transfer the semiconductor memory card to another playback apparatus, and then have the playback continue from right after the stopped position. Unlike conventional technologies, the user does not have to put up with hearing the same tracks whenever the semiconductor memory card is transferred between playback apparatuses.

Albums obtained from an electronic music distribution service will often be transferred between different playback apparatuses. In such case, however, the user will not have to listen to the same tracks whenever the album is transferred to another playback apparatus.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, advantages and features of the invention will become apparent from the following description thereof taken in conjunction with the accompanying drawings which illustrate a specific embodiment of the invention. In the Drawings:

FIG. 1 shows the appearance of a flash memory card 31 when viewed from above;

FIG. 2 shows the construction of the flash memory card 31 when viewed from below;

FIG. 3 shows the hierarchical composition of the flash memory card 31 in the embodiments;

FIG. 4A shows the special region, the authentication region and the user region provided in the physical layer of the flash memory card 31;

FIG. 4B shows the composition of the authentication region and the user region in the file system layer;

FIG. 5 shows the detailed composition of the file system layer;

FIG. 6 is a representation of when the AOB file "AOB001.SA1" is divided into five parts that are stored in clusters 003, 004, 005, 00A, and 00C;

FIG. 7 shows one example of the settings of the directory entries and file allocation table when the AOB file "AOB001.SA1" is recorded in a plurality of clusters;

FIGS. 8A and 8B show what directories are provided in the user region and the authentication region in the file system layer when the above two types of data are recorded in the application layer, as well as what kind of files are recorded in which directories;

FIG. 9 shows the correspondence between the file "AOBSA1.KEY" and the AOB files in the SD_Audio directories;

FIG. 10 shows the hierarchical composition of the data in an AOB file;

FIG. 11A shows the parameters stipulated by ISO/IEC 13818-7 standard in tabular form;

FIG. 11B shows the parameters that should be used when encoding a file in MPEG-Layer 3 (MP3) format in tabular form;

FIG. 11C shows the parameters that should be used when encoding a file in Windows Media Audio (WMA) format in tabular form;

FIG. 12 shows the detailed construction of an AOB_FRAME;

FIG. 13 shows how the byte length of the audio data in each of three AOB_FRAMEs is set;

FIG. 14 shows the correspondence between the sampling_frequency and the number of AOB_FRAMEs included in an AOB_ELEMENT;

FIG. 15 shows examples of the playback periods of AOB_ELEMENTs and the playback periods of AOB_FRAMEs;

FIG. 16 shows what is reproduced when the AOBs and AOB_BLOCKs recorded in an AOB file are consecutively played back;

FIG. 17 shows the hierarchical composition of the PlaylistManager and TrackManager used in the embodiments in detail;

FIG. 18 shows the sizes of the PlaylistManager and the TrackManager;

FIG. 19 shows the correspondence between the TKIs shown in FIG. 17 and the AOBs and AOB files shown in FIG. 16;

FIG. 20 shows the detailed data composition of the TKTMSRT shown in FIG. 17;

FIG. 21 shows one example of the TKTMSRT;

FIG. 22 shows the detailed composition of the TKGI;

FIGS. 23A and 23B show the composition of the BIT;

FIG. 23C shows the Time_Length field;

FIG. 24 shows cluster 007 to 00E into which the AOB composed of AOB_ELEMENT#1 to AOB_ELEMENT#4 are stored;

FIG. 25 shows how the next AOB_FRAME#x+1 to be played back is set when forward search is performed starting from the AOB_FRAME#x in an arbitrary AOB_ELEMENT#y in an AOB;

FIGS. 26A and 26B show how an AOB, an AOB_ELEMENT, and an AOB_FRAME that correspond to an arbitrary playback time code are specified;

FIGS. 27A and 27B show the deletion of a track;

FIG. 28A shows the TrackManager after the deletion of a track has been performed several times;

FIG. 28B shows how a new TKI and AOB file are written when "Unused" TKIs are present in the TrackManager;

FIGS. 29A and 29B shows how the TKIs are set when two tracks are combined to produce a new track;

FIG. 30A shows a Type1 AOB;

FIG. 30B shows Type2 AOBS;

FIG. 31A shows the combining of a plurality of tracks into a single track for a combination of a Type1+Type2+Type2+Type1 AOB;

FIG. 31B shows the combining of a plurality of tracks into a single track for a combination of a Type1+Type2+Type2+Type2+Type1 AOB;

FIG. 32A shows a pattern where a Type1 AOB is present at the end of a preceding track and a Type1 AOB is present at the start of a next track;

FIG. 32B shows a pattern where a Type1 AOB is present at the end of a first track and a Type2 AOB is present at the start of a next track;

FIG. 32C shows a pattern where Type1 and Type2 AOBs are present at the end of a first track and a Type1 AOB is present at the start of a next track;

FIG. 32D shows a pattern where Type1 and Type2 AOBs are present at the end of a first track and Type2 and Type1 AOBs are present at the start of a next track;

FIG. 32E shows a pattern where two Type2 AOBs are present at the end of a first track and a Type1 is present at the start of a next track;

FIGS. 33A and 33B show the division of a track to produce two tracks;

FIGS. 34A and 34B show the content of the SD_Audio directory entries in the SD_Audio directory including the AOB file "AOB003.SA1" before and after the division of the track;

FIG. 35A shows the division of an AOB midway through AOB_ELEMENT#2;

FIG. 35B shows the two AOBs, AOB#1 and AOB#2, obtained by dividing an AOB midway through AOB_ELEMENT#2;

FIG. 36 shows how the BIT is set when an AOB is divided as shown in FIG. 35;

FIG. 37 shows a specific example of changes in the BIT before and after division;

FIG. 38 shows a specific example of changes in the TKTMSRT before and after division;

FIG. 39A shows the format of a DPL_TK_SRP;

FIG. 39B shows the format of a PL_TK_SRP;

FIG. 40 shows the interrelation between the Default_Playlist_Information, the TKIs, and the AOB files;

FIG. 41 shows example settings for the Default_Playlist and several PLIs;

FIG. 42 shows how the DPL_TK_SRPs correspond to TKIs using the same notation as FIG. 40;

FIGS. 43A and 43B show how the order of tracks is rearranged;

FIGS. 44A and 44B show how the Default_Playlist, TrackManager, and AOB files will be updated when DPL_TK_SRP#2 and TKI#2 are deleted from the Default_Playlist shown in FIG. 40;

FIGS. 45A and 45B show how a new TKI and DPL_TK SRP are written when an "Unused" TKI and DPL_TK_SRP are present;

FIGS. 46A and 46B show how tracks are combined;

FIGS. 47A and 47B show how a track is divided;

FIG. 48 shows the appearance of a portable playback apparatus for the flash memory card 31 of the present embodiments;

FIG. 49 shows one example of the display on the LCD panel when a playlist is selected;

FIGS. 50A to 50E show examples of the display on the LCD panel when a track is selected;

FIGS. 51A to 51C show example operations of the jog dial;

FIG. 52 shows the internal construction of the reproduction apparatus;

FIG. 53 shows how data is transferred in and out of the double buffer 15;

FIGS. 54A and 54B show how areas in the double buffer 15 are cyclically allocated using ring pointers;

FIG. 55 is a flowchart showing the AOB file read procedure;

FIG. 56 is a flowchart showing the AOB file output procedure;

FIG. 57 is a flowchart showing the AOB file output procedure;

FIG. 58 is a flowchart showing the AOB file output procedure;

FIGS. 59A to 59D show how the playback time code displayed in the playback time code frame on the LCD panel 5 is updated in accordance with the updating of the variable Play time;

FIG. 60 is a flowchart shows the processing of the CPU 10 when the forward search function is used;

FIGS. 61A to 61D show how the playback time code is incremented when the forward search function is used;

FIGS. 62A and 62B show specific examples of how the time search function is used;

FIG. 63 is a flowchart showing the processing in the editing control program;

FIG. 64 is a flowchart showing the processing in the editing control program;

FIG. 65 is a flowchart showing the processing in the editing control program;

FIG. 66 shows one example of a recording apparatus for recording data onto the flash memory card 31;

FIG. 67 shows the hardware configuration of the recording apparatus;

FIG. 68 is a flowchart showing the processing during recording;

FIG. 69 shows the internal composition of the PlaylistManager and TrackManager in the second embodiment;

FIG. 70 shows the detailed composition of the PlaylistManager_Information;

FIG. 71 shows how the PLMG_AP_PL and PLMG_RSM_PL are set when the flash memory card of the second embodiment is transferred between a plurality of playback apparatuses;

FIG. 72 shows the menu screen used to receive a user setting of the PLMG_AP_*PL and the activation setting;

FIG. 73 is a flowchart showing the playback position determining procedure performed based on the PLMG_AP_PL en and the PLMG_RSM_PL;

FIG. 74 shows the data construction used when the upper six bytes of the PLI_RSM_PL (DPLI_RSM_PL) are stored in the DPLGI for the DPLI and in the PLGI for a PLI;

FIG. 75 shows how the PLI_RSM_PL (DPLI_RSM_PL) is set for the Default_Playlist_Information and each PLI;

FIG. 76 shows the track sequences composed of the playback orders indicated by the playlists shown in FIG. 41 referred to by the first embodiment;

FIG. 77 shows one example of a menu screen that shows each playlist together with the setting of the PLI_RSM_PL for a case where the playback ranges (1) to (3) in FIG. 76 have been already played back; and

FIG. 78 shows the data format of the DPLGI, PLGI, TKGI in the fourth embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following describes a semiconductor memory card (flash memory card) that is an embodiment of the present invention, with reference to the attached figures.

The following paragraphs are arranged into a hierarchy using reference numbers with the notation given below.

The length of a reference number shows the level of the topic in the hierarchy. As a specific example, the number x1 is the number of a drawing that is being referred to in the explanation. The drawings attached to this specification have been numbered in the order in which they are referred to in the specification, so that the order of the drawings roughly matches the order of the explanation. The explanation of certain drawings has been divided into sections, with the reference number x2 giving the section number of a section in the explanation of a drawing indicated by the reference number x1. The reference number x3 shows the number of an additional drawing that is provided to show the details of the section indicated by the section number x2. Finally, the reference number x4 shows the number of a section in the explanation of this additional drawing.

First Embodiment

{1-1.sub.-- 2} External Appearance of the Flash Memory Card 31

The present explanation starts with the external, appearance of the flash memory card 31. FIG. 1 shows the appearance of the flash memory card 31 when viewed from above, while FIG. 2 shows the construction of the flash memory card 31 when viewed from below. As shown in FIGS. 1 and 2, the flash memory card 31 is around the same size as a postage stamp, and so is large enough to be held by hand. Its approximate dimensions are 32.0 mm long, 24.0 mm wide, and 2.0 mm thick.

The flash memory card 31 can be seen to have nine connectors on its bottom edge for connecting the card to a compatible device and a protect switch 32 on one side to enable the user to set whether overwriting of the stored content of the flash memory card 31 is permitted or prohibited.

{3-1} Physical Construction of the Flash Memory Card 31

FIG. 3 shows the hierarchical structure of the semiconductor memory card (hereafter referred to as the "flash memory card 31") of the present embodiment. As shown in FIG. 3, the flash memory card 31 is constructed with a physical layer, a file system layer and an application layer in the same way as a DVD (Digital Video Disc), though the logical and physical constructions of these layers are very different to those on a DVD.

{3-2} Physical Layer of the Flash Memory Card 31

The following describes the physical layer of the flash memory card 31. The flash memory is composed of a plurality of sectors, each of which stores 512 bytes of digital data. As one example, a 64 MB flash memory card 31 will have a storage capacity of 67,108,864 (=64*1,024*1.024) bytes, so that this card will include 131,072 (=67108864/512) valid sectors. Once the number of replacement sectors, which are provided for use in case of errors, is subtracted, the remaining number of valid sectors into which various kinds of data can be written is around 128,000.

{3-2.sub.-- 4A-1} Three Regions in the Physical Layer

The three regions shown in FIG. 4A are provided in the storage area composed of these valid sectors. These regions are the "special region", the "authentication region" and the "user region", and are described in detail below. The user region is characterized in that a device to which the flash memory card 31 is connected can freely read or write various kinds of data from or into this region. Areas within the user region are managed by a file system.

The special region stores a media ID that is a value uniquely assigned to each flash memory card 31. Unlike the user region, this region is read-only, so that the media ID stored in the special region cannot be changed.

The authentication region is a writeable region, like the user region. This region differs from the user region in that a device connected to the flash memory card 31 can access (i.e., read or write data in) the authentication region only if the flash memory card 31 and the device have first confirmed that each other is an authentic device. In other words, data can only be read from or written into the authentication region if mutual authentication has been successfully performed by the flash memory card 31 and the device connected to the flash memory card 31.

{3-2.sub.-- 4A-2} Uses of the Three Regions in the Physical Layer

When the device connected to the flash memory card 31 writes data into the flash memory card 31, the region used to store this data will depend on whether copyright protection is necessary for the data being written. When data that requires copyright protection is written into the flash memory card 31, the data is encrypted using a predetermined encryption key (called a "FileKey") before being written into the user area. This FileKey can be freely set by the copyright holder and, while the use of this FileKey provides some level of copyright protection, the FileKey used for encrypting the written data is itself encrypted to make the copyright protection more secure. Any value obtained by subjecting the media ID stored in the special region into a predetermined calculation can be used to encrypt the FileKey. The encrypted FileKey produced in this way is stored in the authentication region.

Since data that requires copyright protection is subjected to a two-step encryption process where the data is encrypted using a FileKey that is itself encrypted based on the media ID, copyright infringement, such as the production of unauthorized copies of this data, will be extremely difficult.

{3-2.sub.-- 4B-1} Overview of the File System

As can be understood, the construction of the physical layer of the flash memory card 31 strengthens the copyright protection of the data written in the flash memory card 31. The following describes the file system layer present on this physical layer. While the file system layer of a DVD uses a UDF (UniverSA1Disk Format)-type file system, the file system layer of the flash memory card 31 uses a FAT (File Allocation Table)-type file system, as described in ISO/IEC 9293.

FIG. 4B shows the construction of the authentication region and the user region in the file system layer. As shown in FIG. 4B, the authentication region and the user region in the file system each include "partition boot sectors", a "file allocation table (FAT)", a "root directory", and a "data region", meaning that the authentication region and the user region have the same construction. FIG. 5 shows the various parts of these file systems in more detail. The following describes the construction of the user region with reference to FIGS. 4A, 4B and 5.

{3-2.sub.-- 4B-2} Partition Boot Sectors

The partition boot sectors are sectors that store the data that will be referred to by a standard personal computer that is connected to the flash memory card 31 when the flash memory card 31 is set as the boot disk for the operating system (OS) of the personal computer.

{3-2.sub.-- 4B-3.sub.-- 5} Data Region

The data region can be accessed by a device connected to the flash memory card 31 in units no smaller than a "cluster". While each sector in the flash memory card 31 is 512 bytes in size, the cluster size is 16 KB, so that the file system layer reads and writes data in units of 32 sectors.

The reason the cluster size is set at 16 KB is that when data is written onto the flash memory card 31, part of the data stored in the flash memory card 31 first has to be erased before the write can be performed.

The smallest amount of data that can be erased in the flash memory card 31 is 16 KB, so that setting the smallest erasable size as the cluster size means that data writes can be favorably performed. The arrow ff2 drawn using a broken line in FIG. 5 shows the plurality of clusters 002, 003, 004, 005 . . . included in the data region. The numbers 002, 003, 004, 005, 006, 007, 008 . . . used in FIG. 5 are the three-digit hexadecimal cluster numbers that are exclusively assigned to identify each cluster. Since the c) smallest unit by which access can be performed is one cluster, storage positions within the data region are indicated using cluster numbers.

{3-2.sub.-- 4B-4.sub.-- 5} File Allocation System

The file allocation system has a file system construction in accordance with ISO/IEC 9293 standard, and so is made up of a plurality of FAT values. Each FAT value corresponds to a cluster and shows which cluster should be read after the cluster corresponding to the FAT value. The arrow ff1 shown by a broken line in FIG. 5 shows the plurality of FAT values 002, 003, 004, 005 . . . that are included in the file allocation table. The numbers 002, 003, 004, 005 . . . assigned to each FAT value show which cluster corresponds to each FAT value and therefore are the cluster numbers of the clusters corresponding to the FAT values.

{3-2.sub.-- 4B-5.sub.-- 5-1} Root Directory Entries

The "root directory entries" are information showing what kinds of files are present in the root directory. As specific examples, the "filename" of an existing file, its "filename extension", the "revision time/date" and "number of first cluster in file" showing where the start of the file is stored can be written as the root directory entry of a file.

{3-2.sub.-- 4B-5.sub.-- 5-2} Directory Entries for Subdirectories

Information relating to files in the root directory is written as root directory entries, though information relating to subdirectories is not written as the root directory entries. Directory entries for subdirectories are instead produced in the data region. In FIG. 5, the SD-Audio directory entry given in the data region is one example of a directory entry for a subdirectory. Like a root directory entry, an SD-Audio directory entry includes the "filename" of a file present in this subdirectory, its "filename extension", the "revision time/date" and "number of first cluster in file" showing where the start of the file is stored.

{3-2.sub.-- 4B-5.sub.-- 6-1} Storage Format for AOB Files

The following describes the file storage method by showing how a file named "AOB001.SA1" is stored in the SD-Audio directory, with reference to FIG. 6. Since the smallest unit by which the data region can be accessed is one cluster, the file "AOB001.SA1" needs to be stored in the data region in parts that are no smaller than one cluster. The file "AOB001.SA1" is therefore stored having first been divided into clusters. In FIG. 6, the file "AOB001.SA1" is divided into five parts in keeping with the cluster size, and the resulting parts are stored into the clusters numbered 003, 004, 005, 00A, and 00C.

{3-2.sub.-- 4B-5.sub.-- 7-1} Storage Format for AOB Files

When the file "AOB001.SA1" is divided up into parts and stored, a directory entry and the file allocation table need to be set as shown in FIG. 7. FIG. 7 shows one example of how the directory entry and file allocation table need to be set when the file "AOB001.SA1" is stored having been divided up into parts and stored. In FIG. 7, the start of the file "AOB001.SA1" is stored in cluster 003, so that cluster number 003 is written into "the number of first cluster in file" in the SD-Audio directory entry to indicate the cluster storing the first part of the file. As shown in FIG. 7, the following parts of the file "AOB001.SA1" are stored in clusters 004 and 005. As a result, while the FAT value 003(004) corresponds to cluster 003 that stores the first part of the file "AOB001.SA1", this value indicates cluster 004 as the cluster storing the next part of the file "AOB001.SA1". In the same way, while the FAT values 004 (005) and 005 (00A) respectively correspond to clusters 004 and 005 that store the next parts of the file "AOB001.SA1", these values respectively indicate cluster 005 and cluster 00A as the clusters storing the next parts of the file "AOB001.SA1". By reading the clusters with the cluster numbers written into these FAT values in order as shown by the arrows fk1, fk2, fk3, fk4, fk5 . . . in FIG. 7, all of the parts produced by dividing the file "AOB001.SA1" can be read. As explained above, the data region of the flash memory card 31 is accessed in units of clusters, each of which is associated with a FAT value. Note that the FAT value that corresponds to the cluster storing the final part of an AOB file (the cluster 0.degree. C. in the example shown in FIG. 7) is set the cluster number FFF to show that the corresponding cluster stores the final part of a file.

This completes the explanation of the file system in the flash memory card 31 of the present invention. The following describes the application layer that exists on this file system.

{3-3} Overview of the Application Layer in the Flash Memory Card 31

An overview of the application layer in the flash memory card 31 is shown in FIG. 3. As shown by the arrow PN1 drawn with a broken line in FIG. 3, the application layer in the flash memory card 31 is composed of presentation data and navigation data that is used to control the playback of the presentation data. As shown by the arrow PN2, the presentation data includes sets of audio objects (AOB sets) that are produced by encoding audio data that represents music, for example. As shown by the arrow PN3, the navigation data includes a "PlaylistManager" (PLMG) and a "TrackManager" (TKMG).

{3-3.sub.-- 8A,B-1} Directory Composition

FIGS. 8A and 8B show what kind of directories are present in the user region and the authentication region in the file system layer when these two types of data are stored in the application layer, as well as showing what files are arranged into these directories.

The filenames "SD_AUDIO.PLM" and "SD_AUDIO.TKM" in FIG. 8A indicate the files in which the PlaylistManager (PLMG) and TrackManager (TKMG) composing the navigation information are stored. Meanwhile, the filenames "AOB001.SA1", "AOB002.SA1", "AOB003.SA1", "AOB004.SA1", . . . indicate the files ("AOB" files) storing the audio objects that are, the presentation data. The letters "SA" in the filename extension of the filename "AOB0xx.SA1" are an abbreviation for "Secure Audio", and show that the stored content of this file requires copyright protection. Note that while only eight AOB files are shown in the example in FIG. 8A, a maximum of 999 AOB files can be stored in an SD-Audio directory.

When copyright protection is required for presentation data, a subdirectory called an "SD-Audio directory" is provided in the authentication region and an encryption key storing file "AOBSA1.KEY" is produced in this SD-Audio directory.

FIG. 8B shows the encryption key storing file "AOBSA1.KEY" that is stored under the "SD-Audio" legend (i.e., within the "SD-Audio directory"). This encryption key storing file "AOBSA1.KEY" stores a sequence of encryption keys that is produced by arranging a plurality of encryption keys into a predetermined order.

The SD-Audio directory shown in FIGS. 8A and 8B is stored in a server computer managed by a record label that uses electronic music distribution. When a consumer orders a music content, the corresponding SD-Audio directory is compressed, encrypted and transmitted to the consumer via a public network. The consumer's computer receives this SD-Audio directory, decrypts it, decompresses it and so obtains the original SD-Audio directory. Note that the expression "public network" here refers to any kind of network that can be used by the public, such as a wired communication network, e.g., an ISDN network, or a wireless communication network, e.g., a mobile telephone system. It is also possible for a consumer's computer to download an AOB file from a server computer operated by a record label and then produce an SD-Audio directory, such as that shown in FIGS. 8A and 8B, in the flash memory card 31.

{3-3.sub.-- 9-1} Correspondence Between the "AOBSA1.KEY" File and the AOB Files

FIG. 9 shows the correspondence between the "AOBSA1.KEY" file in the SD-Audio directory and the AOB files. The FileKeys used when encrypting files in the user region shown in FIG. 9 are stored in the corresponding encryption key storing file in the authentication region.

The encrypted AOB files and the encryption key storing file correspond according to the predetermined rules (1), (2), and (3) described below.

(1) The encryption key storing file is arranged into a directory with the same directory name as the directory in which the encrypted file is stored. In FIG. 9, AOB files are arranged into the SD-Audio directory in the user region and the encryption key storing file is arranged into a directory called the SD-Audio directory in the authentication region, in accordance with this rule.

(2) The encryption key storing file is given a filename produced by combining the first three letters of the filename of the AOB files in the data region with the predetermined ".key" extension. When the filename of an AOB file is "AOB001.SA1", the encryption key storing file is given the filename "AOBSA1.KEY" produced by adding the first three characters "AOB", "SA1", and the extension ".key", as shown by the arrows nk1 and nk2 in FIG. 9.

(3) The filename of an AOB file is given a serial number showing the position of the FileKey corresponding to this audio object in the sequence of encryption keys given in the encryption key storing file.

The "File Key Entries #1, #2, #3, . . . #8" show the first positions of the regions in which the respective FileKeys in the encryption key storing file are stored. Meanwhile, the filenames of AOB files are assigned the serial numbers "001", "002", "003", "004" . . . . These serial numbers show the positions of the corresponding FileKeys in the encryption key sequence, so that the FileKey that was used to encrypt each AOB file will be present in the "FileKey Entry" with the same serial number. In FIG. 9, the arrows Ak1, Ak2, Ak3, . . . show the correspondence between AOB files and FileKeys. In other words, the file "AOB001.SA1" corresponds to the FileKey whose storage position is indicated by the "FileKey Entry#2", and the file "AOB003.SA1" corresponds to the FileKey whose storage position is indicated by the "FileKey Entry#3". As can be understood from rule (3), different FileKeys are used to encrypt different AOB files, with these FileKeys being stored in "FileKey Entries" with the serial numbers "001", "002", "003", "004", etc., given in the filenames of the corresponding AOB files.

Since each AOB file is encrypted using a different FileKey, the exposure of the encryption key used for one AOB file will not enable users to decrypt other AOB files. This means that when AOB files are stored in an encrypted form on a flash memory card 31, the damage caused by the exposure of one FileKey can be minimized.

{3-3.sub.-- 10-1} Internal Composition of an AOB File

The following describes the internal composition of an AOB file. FIG. 10 shows the hierarchical data structure of an AOB file. The first level in FIG. 10 shows the AOB file, while the second level shows the audio object (AOB) itself. The third level shows the AOB_BLOCKs, the fourth level an AOB_ELEMENT, and the fifth level an AOB_FRAME.

The AOB_FRAME on the fifth level in FIG. 10 is the smallest unit composing the AOB, and is composed of audio data in ADTS (Audio Data Transport Stream) format and an ADTS header. Audio data in ADTS format is encrypted according to MPEG2-AAC (Low Complexity Profile) format and is stream data that can be played back at a transfer rate of 16 Kbps to 144 Kbps. Note that the transfer rate for PCM (Pulse Code Modulation) that is recorded on a conventional compact disc is 1.5 Mbps, so that data in ADTS format generally uses a lower transfer rate than PCM. The data construction of a sequence of AOB_FRAMEs is the same as the sequence of audio frames included in an audio data transport stream distributed by an electronic music distribution service. This means that the audio data transport stream to be stored as AOB_FRAME sequence is encoded according to MPEG2-ACC standard, encrypted, and transmitted on a public network to the consumer. AOB files are produced by dividing the transmitted audio data transport stream into a sequence of AOB_FRAMEs and storing these AOB_FRAMEs.

{3-3.sub.-- 10-1.sub.-- 11} MPEG2-AAC

MPEG2-AAC is described in detail in ISO/IEC 13818-7:1997(E) "Information Technology--Generic Coding of Moving Pictures and Associated Audio Information--Part7 Advanced Audio Coding (AAC)".

It should be noted that audio objects can only be compressed according to MPEG2-AAC using the parameters in the parameter table shown in FIG. 11A that is defined in ISO/IEC13818-7. This parameter table is composed of a "Parameter" column, a "Value" column, and a "Comment" column.

The legend "profile" in the Parameter column shows the only LC-profile can be used, as stipulated under ISO/IEC 13838-7. The legend "sampling_frequency#index" in the Parameter column shows that the sampling frequencies "48 kHz, 44.1 kHz, 32 kHz, 24 kHz, 22.05 kHz, and 16 kHz" can be used.

The legend "number_of_data_block_in_frame" in the Parameter column shows that the ratio of one header to one raw_data_block is used.

Note that while this explanation describes the case where AOB_FRAMEs are encoded according to MPEG-AAC format, AOB_FRAMEs may instead be encoded according to another format, such as MPEG-Layer3 (MP3) format or Windows Media Audio (WMA). When doing so, the parameters shown in the parameter tables of FIG. 11B or FIG. 11C must be used.

{3-3.sub.-- 10-2.sub.-- 12} Composition of an AOB_FRAME

While each AOB_FRAME includes audio data that is encoded according to the restrictions described above, the data length of the audio data in each AOB_FRAME is restricted to a playback time of only 20 ms. However, since MPEG2-AAC is a variable bitrate (VBR) encoding method, the data length of the audio data in each AOB_FRAME will vary. The following describes the composition of an AOB_FRAME, with reference to FIG. 12.

The first level in FIG. 12 shows the overall composition, while the second level shows how each part of an AOB_FRAME is encrypted. As can be seen from the drawing, the ADTS header corresponds to a non-encrypted part. The audio data includes both an encrypted part and a non-encrypted part. The encrypted part of the audio data is composed of a plurality of eight-byte pieces of encrypted data, each of which is produced by encrypting an eight-byte piece of audio data using a 56-bit FileKey. When encryption is performed on 64-bit pieces of audio data, the non-encrypted part of the audio data is simply a final part of the data that cannot be encrypted due to it being shorter than 64 bits.

The third level in FIG. 12 shows the content of the ADTS header that is in the non-encrypted part of the AOB_FRAME. The ADTS header is seven bytes long, and includes a 12-bit synch word (set at FFF), the data length of the audio data in this AOB_FRAME, and the sampling frequency used when the audio data was encoded.

{3-3.sub.-- 10-3.sub.-- 13} Setting of the Byte Length of an AOB_FAM

FIG. 13 shows how the byte length of the audio data in each of three AOB_FRAMEs is set. In FIG. 13, the data length of audio data#1 included in AOB_FRAME#1 is x1, the data length of audio data#1 included in AOB_FRAME#2 is x2, and the data length of audio data#1 included in AOB_FRAME#3 is x3. When the data lengths x1, x2, and x3 are all different, the data length x1 will be written in the ADTS header of AOB_FRAME#1, the data length x2 will be written in the ADTS header of AOB_FRAME#2, and the data length x3 will be written in the ADTS header of AOB_FRAME#3.

Although the audio data is encrypted, the ADTS header is not, so that a playback device can know the data length of the audio data in an AOB_FRAME by reading the data length given in the ADTS header of the AOB_FRAME.

This completes the explanation of an AOB_FRAME.

{3-3.sub.-- 10-4} AOB_ELEMENT

The following describes the AOB_ELEMENT shown on the fourth level in FIG. 10.

An "AOB_ELEMENT" is a group of consecutive AOB_FRAMEs. The number of AOB_FRAMEs in an AOB_ELEMENT depends on the value set as the sampling_frequency_index shown in FIG. 1A and the encoding method used. The number of AOB_FRAMEs in an AOB_ELEMENT is set so that the total playback time of the included AOB_FRAMEs will be around two seconds, with this number depending on the sampling frequency and encoding method used.

{3-3.sub.-- 10-5.sub.-- 14} Number of AOB_FRAMEs in an AOB_ELEMENT

FIG. 14 shows the correspondence between the sampling frequency and the number of AOB_FRAMEs included in an AOB_ELEMENT. The number N given in FIG. 14 represents the playback period of an AOB_ELEMENT in seconds. When MPEG-ACC is used as the encoding method, the value of N is "2".

When the sampling_frequency is 48 kHz, the number of AOB_FRAMEs included in an AOB_ELEMENT is given as 94 (=47*2), while when the sampling_frequency is 44.1 kHz, the number of AOB_FRAMEs included in an AOB_ELEMENT is given as 86(=43*2). When the sampling_frequency is 32 kHz, the number of AOB_FRAMEs is given as 64 (=32*2), when the sampling_frequency is 24 kHz, the number of AOB_FRAMEs is given as 48(=24*2), when the sampling_frequency is 22.05 kHz, the number of AOB_FRAMEs is given as 44 (=22*2), and when the sampling_frequency is 16 kHz, the number of AOB_FRAMEs included in an AOB_ELEMENT is given as 32 (=16*2). However, when an editing operation, such as the division of an AOB, has been performed, the number of AOB_FRAMEs included in an AOB_ELEMENT at the start or end of an AOB may be less than a number calculated in this way.

While no header or other special information is provided for each AOB_ELEMENT, the data length of each AOB_ELEMENT is instead shown by a time search table.

{3-3.sub.-- 10-6.sub.-- 15} One Example of the Playback Periods of AOB_ELEMENTS and AOB_FRAMEs

FIG. 15 shows one example of the playback periods of AOB_ELEMENTs and AOB_FRAMEs. The first level in FIG. 15 shows a plurality of AOB_BLOCKs, while the second level shows a plurality of AOB_ELEMENTs. The third level shows a plurality of AOB_FRAMEs.

As shown in FIG. 15, an AOB_ELEMENT has a playback period of around 2.0 seconds, while an AOB_FRAME has a playback period of 20 milliseconds. The "TMSRT_entry" given to each AOB_ELEMENT shows that the data length of each AOB_ELEMENT is given in the time search table. By referring to the TMSRT_entries, a playback apparatus can perform a forward or backward search where, for example, intermittent bursts of music are played back by repeatedly playing back 240 milliseconds of audio data and then skipping two seconds of audio data in the desired direction.

{3-3.sub.-- 10-7} AOB_BLOCK

This completes the explanation of an AOB_ELEMENT. The following descri