Language selection

Search

Patent 2528035 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 2528035
(54) English Title: FILE MANAGEMENT METHOD
(54) French Title: METHODE DE GESTION DE FICHIERS
Status: Expired and beyond the Period of Reversal
Bibliographic Data
(51) International Patent Classification (IPC):
  • G11B 20/12 (2006.01)
  • G11C 08/18 (2006.01)
(72) Inventors :
  • IWANO, YURI (Japan)
  • IKEDA, NATSUKO (Japan)
  • KIYAMA, JIRO (Japan)
  • NISHIMURA, MOTOHIDE (Japan)
  • YAMAMURA, HIROYUKI (Japan)
  • YAMAGUCHI, TAKAYOSHI (Japan)
(73) Owners :
  • SHARP KABUSHIKI KAISHA
  • SHARP KABUSHIKI KAISHA
(71) Applicants :
  • SHARP KABUSHIKI KAISHA (Japan)
  • SHARP KABUSHIKI KAISHA (Japan)
(74) Agent: G. RONALD BELL & ASSOCIATES
(74) Associate agent:
(45) Issued: 2011-12-13
(22) Filed Date: 2001-02-22
(41) Open to Public Inspection: 2001-08-30
Examination requested: 2005-12-23
Availability of licence: N/A
Dedicated to the Public: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
2000-50428 (Japan) 2000-02-28

Abstracts

English Abstract

When one recording medium is accessed from a multiple number of applications, the medium is usually divided into multiple areas. If this area division is performed and managed by partitioning, it is difficult to change the size of the partitions. Therefore, there has been the problem that the recording medium can not be used effectively. The recording medium is divided into multiple areas, and for each area, dummy data is written into the blank space in the area so that dummy data can only be overwritten using a particular application or with a file of a particular type. This configuration makes it easy to divide the medium into multiple areas and change the size of the areas.


French Abstract

Lorsqu'un support d'enregistrement est sollicité à partir de multiples applications, ce support est habituellement divisé en zones multiples. Si cette division par zones est effectuée et gérée par partitionnement, il est difficile de modifier la taille des partitions. Par conséquent a surgi le problème selon lequel il n'est pas possible d'utiliser efficacement le support d'enregistrement. Ledit support d'enregistrement est divisé en zones multiples, et pour chaque zone, des données factices sont inscrites dans l'espace en blanc de la zone, de sorte que ces données factices peuvent être seulement recouvertes au moyen d'une application particulière ou avec un fichier de type particulier. Cette configuration facilite la division du support en zones multiples et permet de modifier la taille de ces zones.

Claims

Note: Claims are shown in the official language in which they were submitted.


31
THE EMBODIMENTS OF THE PRESENT INVENTION IN WHICH AN
EXCLUSIVE PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED
AS FOLLOWS:
1. A file management method for securing on a
recording medium, a data area for storing actual data
to be recorded and an area for storing management
information with respect to the actual data, and
managing the data as a file, comprising the steps of:
securing a first area for storing a first
management information with respect to first actual
data on the recording medium,
setting up an unused space in the first area as a
dummy file,
writing the first management information on the
dummy file when a request for writing the first
management information has occurred, and
reducing the dummy file by deducing an area
allotted by the first management information from the
dummy file.
2. A file management method for securing on a
recording medium, a data area for storing actual data
to be recorded and an area for storing management

32
information with respect to the actual data, and
managing the data as a file, comprising the steps of:
securing a first area for storing a first
management information with respect to first actual
data on the recording medium,
setting up an unused space in the first area as a
dummy file, and
enlarging the dummy file by adding an area allotted
for the first management information to be reduced when
the first management information is reduced from the
first area.
3. The file management method according to Claim 1 or
2, wherein the first management information is
application management information for reproducing the
first actual data.
4. The file management method according to Claim 1,
wherein the first management information is comprised
of application management information for reproducing
the first actual data and filesystem management
information for managing a directory hierarchy of a
file of the application management information.

33
5. The file management method according to Claim 1 or
2, wherein the first management information is file
management information for managing a directory
hierarchy of a file of the first actual data.
6. The file management method according to Claim 1 or
2, wherein file management information of the dummy
file exists in the first area.
7. The file management method according to Claim 1 or
2, further comprising the steps of:
comparing a size of the dummy file with a size of
the first management information requested of writing
when a request for writing the first management
information has occurred, and
enlarging the dummy file by including an adjacent
unused area adjoining the first area when the size of
the dummy file is insufficient for writing the first
management information.
8. The file management method according to Claim 1 or
2, further comprising the steps of:
comparing a size of the dummy file with a size of
the first management information requested of writing
when a request for writing the first management
information has occurred, and

34
setting up a non-adjacent unused area separated
from the first area as a non-adjacent dummy file when
the size of the dummy file is insufficient for writing
the first management information, wherein the
non-adjacent dummy file is defined by a file name that
is connected with the dummy file.
9. The file management method according to Claim 7,
wherein the adjacent unused area is made by displacing
actual data or a management information that has
already been recorded adjacent to the dummy file.
10. The file management method according to Claim 1 or
2, wherein a trailing end of the first area is always
constituted by the dummy file.
11. The file management method according to Claim 1 or
2, wherein a leading end and a trailing end of the
first area are always constituted by the dummy files.
12. A file management apparatus for performing the file
management method according to any one of Claims 1 to
11, comprising a recording medium and a recording
control means for managing data input and output with
respect to the recording medium.

Description

Note: Descriptions are shown in the official language in which they were submitted.


CA 02528035 2011-05-18
1
FILE MANAGEMENT METHOD
This application is a division of Canadian
Application Serial No. 2,400,870, filed February 22,
2001. The claims of the present application are
directed to a file management method for securing a data
area to store data and area to store management
information on a recording medium and managing the data
as a file. However, for the purpose of understanding
the invention, including all features which are
inextricably bound-up in one and the same inventive
concept, the teachings of those features claimed in the
parent Canadian Application Serial No. 2,400,870 are
retained herein.
Accordingly, the retention of any such features
which may be more particularly related to the parent
application or a separate divisional thereof should not
be regarded as rendering the teachings and claiming
ambiguous or inconsistent with the subject matter
defined in the claims of the divisional application
presented herein when seeking to interpret the scope
thereof and the basis in this disclosure for the claims
recited herein.
Field of the Invention
The present invention relates to a file management
method whereby a single recording medium is divided into

CA 02528035 2010-04-01
la
a plurality of areas when files of different
applications should be written into the recoding medium.
Background of the Invention
It provides a marked advantage for users if there
are multipurpose disk media which can be used in common
based on different platforms such as for PC (Personal
Computer) usage, or AV (audio/visual) usage. For
example, if a disk recorded with an AV disk recorder is
accessible from a disk drive connected to a PC and if
the reversal access can be made easily, this implies
that the AV data recorded by an AV disk recorder can be
accessed or edited from a PC and the edited product
etc., can be readily reproduced by the AV disk recorder
and the like. Further, a single disk may be used in
common by AV usage and PC usage such that AV data may be
recorded and application software for PCs may be stored
into a single disk.
However, there are differences in characteristics
between the data recorded for AV usage and that for PC
usage. For example, when AV data recorded on a disk is

CA 02528035 2001-02-22
2
reproduced, the AV data needs to be read out from the
disk and displayed on the display at determined timing.
If the data cannot be reproduced at the determined
timing, this means that the pictures of the reproduced
view become discontinuous, resulting in disorder, which
is unacceptable.
Because disk media are advantageous in random
accessibility, it is not necessary to arrange even a
series of data in continuous locations on the disk but
the data may be recorded in parts by making effective
use of blank spaces on the disk. For example, for PC
usage, if a document data file has been recorded at
scattered locations on the disk, seeks or track jumps
occur during reading the file at the positions where the
data is disconnected, and in this while data reading
from the disk is, stopped. However, there will not occur
any problem at all with regards to the functional
aspect, even though this configuration needs a somewhat
longer time for data reading, compared to the case where
the data can be read out continuously.
However, for AV usage, as stated above, if the data
to be reproduced is discontinuous on the disk,
interruptions occur during data reading at the
disconnected positions, possibly causing problems. In
general, AV data read out from a disk is once stored in
a buffer memory to some extent, so as to prevent
interruption in the reproducing pictures by compensating
for disconnections occurring during data reading, such

CA 02528035 2001-02-22
3
as seeks, track jumps etc., with the data stored in the
buffer memory. Though the buffer memory absorbs such
disconnections of reproduced pictures, it will not be
able to keep up if seeks or track jumps occur too often.
Therefore, when AV data is recorded on the disk,
continuous recording of data free from occurrences of
seeks and track jumps which will cause disconnections
during data reading is preferred.
Now, if it is contemplated that one single disk is
used in common for AV usage and PC usage, each type of
data is desirably recorded to an area different from
that of the other. If data for PC usage which is much
smaller than AV data becomes recorded at random in the
disk area where AV data needs to be recorded
continuously, this will obstruct continuous recording of
the AV data, and may cause difficulties in recording and
reproduction of AV data.
The data to be recorded for AV usage not only
includes AV data but also contains various kinds of data
such as management information files for reproducing the
AV data and still images. Since the data to be recorded
may be for the same usage but different in type, there
occurs the demand for managing the data in separated
areas dependent on the types of data to be recorded.
Examples are the area where management information of
the logical filesystem is recorded, the area where
management information and the like for reproducing AV

CA 02528035 2010-04-01
4
data is recorded, the area where AV data itself is
recorded and the area where still images are recorded..
In order to use one single disk by dividing it into
a plurality of areas, there have been methods as
follows. First, in a sense of dividing the area
clearly, there exists the partitioning function based on
the logical filesystem. For 'example, by defining
partitions for AV usage and PC usage, it is possible to
provide a dedicated area for each.
The example shown in Fig. 16 illustrates the way
one disk is divided into three partitions, namely
partition 1, partition 2 and partition 3.
As a second method where the partitioning function
is not used, it is possible to consider that the areas
are managed by the management information in the
application layer at the implementation level, instead
of letting the logical filesystem manage the areas for
AV usage and PC usage. For example, a management
information file, which includes positional information
of areas, is recorded on the disk so that the positional
information of each area can be grasped by reading the
file. In the example shown in Fig. 17, a file 'AREA.DAT'
has positional information as to area 1, area 2 and area
3 recorded therein. Therefore, applications capable of
understanding the file 'AREA.DAT' alone can grasp the
ranges of the areas.

CA 02528035 2010-04-01
Differing from the above first method, areas 1 through
3 here belong to a single partition on the logical filesystem,
and are sectioned therein.
5 A third method can be considered in which, for the purpose
of reserving an area for recording a file or data, a dummy
file is created as if the area were used despite no actual
data being recorded. In the area shown in Fig.18, areas to
be used for files to be recorded are secured by three dummy
files, DUMMYI.DAT, DUMMY2.DAT and DUMMY3.DAT.
In this way, dummy data equal in size to the data to
be recorded has been recorded beforehand and when a file of
the predetermined data type is written in, the dummy data
is erased and then the file is written in place, thus enabling
continuous writing of files of different data types.
In the above first method, it is possible to create
dedicated divided areas for AV usage and PC usage by using
the partitioning function. However, in general, for
partitioning, it is necessary to decide the number of
partitions and their sizes when the disk is initialized. Hence,
it is not easy to change the configuration of the partitions,
during use. This is because every partition usually has
independent logical addresses and management information for
blank spaces and hence it is necessary to reconstruct many
pieces of management information if the configuration needs

CA 02528035 2001-02-22
6
to be changed. Further, the user needs to decide the size
allotted for AV usage and that for PC usage at the time of
initialization. However, it may happen that either one become
lacked as use proceeds.
As stated above, since the sizes etc., of partitions
are not easy to change, if, for example, there are blank spaces
in the area for PC usage, it is no longer possible to record
AV data when the area for AV usage has become full, thus posing
the problem of the disk being unable to be used efficiently.
Further, there are cases where a plurality of areas are needed
to manage even the same type of data for AV usage, such as
an area for recording the management information of the logical
filesystem, area for recording the management information
for reproducing AV data, area for recording AV data, and area
for recording still images. In this case, if each area is
managed as a partition, many partitions need to be formed.
Therefore, when one partition becomes full, the possibility
of more data, etc. , being unable to be recorded becomes higher
even with blank spaces still remaining on the disk.
As in the second method, when the areas are managed based
on the management information in the application layer at
the implementation level, instead of managing with the
partitioning function provided by the logical filesystem,
the areas are controlled by a specific application. Therefore,
the management information with the positional data of the

CA 02528035 2001-02-22
7
areas recorded therein is of no use for applications
other than the specific one. No problem will occur as
long as the disk is used only by the specified
application. These areas cannot be recognized when
accessed from an application other than the specified
one since the secured areas are not established at the
logical filesystem level. Therefore, there is a
possibility of unexpected data being written in the
secured area, posing a problem.
Further, as in the third method, it is possible to
secure an area by using a dummy file for reserving an
area for allowing one file or data to be recorded. In
this method, if, for example, a continuous area for
recording management information needs to be secured,
the sizes and number of files to be recorded in the
future must be predicted, whereby dummy files equal in
size and in number should be recorded to secure the
area. Therefore, dummy files are primarily prepared
with the maximum size of expected files to be recorded.
When an actually written file is smaller in size than
the dummy file, there occurs the problem that much space
is used wastefully.
In the area 1 shown in Fig. 18, when it is assumed
that the size of each file to be written in is 1 M Byte,
dummy files having a size of 1 M Byte will be formed.
When a file of 0.8 M Byte is written in, the data of 0.8
M Byte is written first into the location of the first
dummy file (DUMMYl.DAT). When a second file of 0.9 M

CA 02528035 2011-05-18
8
Byte is written in, the data is written into the
location of the second dummy file (DUMMY2.DAT). This
results in a waste of 0.1 M Byte. Further, there is a
problem that a file cannot be handled if the size of the
file to be written in cannot be estimated (the maximum
size cannot be expected).
Accordingly, the present invention provides a
solution to the problems with the above three methods,
and the present invention prevents data other than the
desired data from being written into the predetermined
area, without sectioning using partitions based on the
logical filesystem.
Summary of the Invention
According to an aspect of the present invention,
there is provided a file management method for securing
on a recording medium, a data area for storing actual
data to be recorded and an area for storing management
information with respect to the actual data, and
managing the data as a file, comprising the steps of
securing a first area for storing a first management
information with respect to first actual data on the
recording medium, setting up an unused space in the
first area as a dummy file, writing the first management
information on the dummy file when a request for writing
the first management information has occurred, and
reducing the dummy file by deducing an area allotted by
the first management information from the dummy file.

CA 02528035 2010-04-01
9
According to the invention, there is provided a
file management method for a recording device having a
recording medium and a recording control means for
managing data input and output with respect to the
recording medium, wherein at least one area is secured
in the recording medium and the blank space in each area
is managed by a dummy file, the method characterized in
that, when a file is written into the area, the file is
written over the dummy file in the area and the size of
the dummy file is updated to the size of the blank space
in the area.
According to another aspect of the present
invention, there is provided a file management method
for securing on a recording medium, a data area for
storing actual data to be recorded and an area for
storing management information with respect to the
actual data, and managing the data as a file, comprising
the steps of securing a first area for storing a first
management information with respect to first actual data
on the recording medium, setting up an unused space in
the first area as a dummy file, and enlarging the dummy
file by adding an area allotted for the first management
information to be reduced when the first management
information is reduced from the first area.
According to the invention, each of the dummy files
permits writing from a predetermined application.

CA 02528035 2001-02-22
According to the present invention, each of the
dummy files permits files of a predetermined type to be
written in.
5 According to the present invention, the trailing
end of each area is always constituted by a dummy block.
According to the present invention, the leading end
and the trailing end of each area are always constituted
by dummy blocks.
10 According to the present invention, there is
provided a file management method for securing a data
area to store data and an area to store management
information on a recording medium and managing the data
as a file, comprising the steps of securing a first area
for storing a first management information on the
recording medium, and setting up an unused space in the
first area as a dummy file, wherein the dummy file is
defined by a file name which is designated as a blank
area when the first management information is written on
the recording medium.
According to the present invention, there is
provided a file management method for securing a data
area to store data and an area to store management
information on a recording medium and managing the data
as a file, comprising the steps of securing a first area
for storing a first management information on the
recording medium, and setting up an unused space in the
first area as a dummy file, wherein file management
information of the dummy file has an attribute which

CA 02528035 2010-04-01
11
designates a hidden file or a write protected file to
predetermined application.
According to the invention, by creating a dummy file
so as to manage the unused portion within the secured
continuous area, the whole part of this area will appear
as being used for applications other than that specified
to use this area, so that it is possible to inhibit data
from being written in.
Further, by obtaining the file size and positional
information of the dummy file, it is possible for the
application defining the dummy file to readily grasp the
size of the unused space in the secured area and its
position and easily perform updating and file creation
within the area.
When a multiple number of applications of different
manufacturers which all can recognize the dummy file are
provided, the secured continuous area is not always
consistent in size between the manufacturers. Also in
this case, only referring tot he dummy 'file information
enables grasp of the unused portion, thus making it
possible to provide compatibility between the
manufacturers.
Since the partitioning function as a function based
on the logical filesystem is not used, it is possible to
change the area size by merely updating the dummy file
only, which is a simpler procedure compared to the case
where the size, etc. of partitions are altered. When it
is necessary to know the range of the secured continuous

CA 02528035 2010-04-01
12
area, the continuous area can be managed by arranging
the logical block or blocks of the dummy file at the
trailing end or both the leading and trailing ends of
the continuous area as required, whereby it is possible
to readily grasp the range of the continuous area being
managed.
Brief Description of the Drawings
Fig. 1 is a block diagram showing the configuration
of a disk device as one embodiment of the present
invention;
Fig. 2 is an illustrative view of the embodiment of
an area management method of the present invention,
showing the way a dummy file is used to secure an area;
Fig. 3 is an illustrative view of the embodiment of
an area management method of the present invention,
showing the arrangement of the dummy file when a file is
erased;
Fig. 4 is an illustrative view of the embodiment of
an area management method of the present invention,
showing the relationships of UDF management information;
Fig. 5 is a flowchart showing the procedures for
securing a continuous area in the mode of an area
management method of the present invention;
Fig. 6 is a flowchart showing the procedures of
creating a file within a continuous area secured in the
embodiment of an area management method of the present
invention;

CA 02528035 2001-02-22
12a
Fig. 7 is a flowchart showing the flow of
operations when an update accompanied with size change
of the file secured within the continuous area is made
in the embodiment of an area management method of the
present invention;
Fig. 8 is a flowchart showing the flow of
operations when the file in the secured continuous area
is erased in the embodiment of an area management method
of the present invention;
Fig. 9 is a flowchart showing the flow of
operations when the secured continuous area is expanded
in the embodiment of an area management method of the
present invention;
Fig. 10 is an illustrative view of the embodiment
of an area management method of the present invention,
showing an example when the secured continuous area is
expanded;
Fig. 11 is an illustrative view of the embodiment
of an area management method of the present invention,
showing the way the dummy file in the area necessarily
manages the last logical block;
Fig. 12 is an illustrative view of the embodiment
of an area management method of the present invention,
showing the way the dummy file in the area necessarily
manages the first and last logical blocks;
Fig. 13 is an illustrative view of the embodiment
of an area management method of the present invention,
showing the way the dummy file in the area necessarily

CA 02528035 2010-04-01
12b
manages the last logical block and the file entry of the
dummy file is arranged at the first logical block;
Fig. 14 is an illustrative view showing a practical
application example, in the embodiment of an area
Fig. 14 is an illustrative view showing a practical
application example, in the embodiment of an area
management method of the present invention;
Fig. 15 is an illustrative view showing the
directory hierarchy of the example of Fig 12 in the
embodiment of an area management method of the present
invention;
Fig. 16 is an illustrative view showing the prior
art method of securing areas by partitioning;
Fig. 17 is an illustrative view showing the prior
art method of area securement by the file that records
positional information as to the areas; and
Fig. 18 is an illustrative view showing the prior
art method of area securement using unit dummy files.
Detailed Description of the Invention
An embodiment of an area management method of the
present invention will hereinbelow be described in
detail with reference to the drawings. In the present
embodiment, the disk devices are assumed to be a
hand-held video camera and video deck which use a disk
aiming at AV recording and reproduction, an external
storage device connected to a PC and the like. The disk
medium is preferably of a removable type but may be of
a mounted type such as a hard disk. For

CA 02528035 2001-02-22
13
description convenience, the logical filesystem used for the
disk is assumed to be based on the UDF (Universal Disk Format)
as the standard of the OSTA(Optical Storage Technology
Association), but other generalized logical filesystems can
be used.
Fig. 1 shows the configuration of a typical disk device.
A data input/output portion 1 inputs video signals from a
camera etc., and outputs data to be reproduced to a monitor
or the like. A data processor 2 is a processing portion which
performs signal processings such as encoding and decoding
MPEG codes. The processed data is stored in a memory 3. When
data is recorded, a disk controller 5 controls a disk 6 so
that data can be recorded at a target position on the disk.
When the data is reproduced, the controller controls disk
6 so that data is read out from a target position on the disk
and stored into memory 3. Each processing portion is
controlled by a system controller 4.
In such a disk device, when the disk needs to be divided
into multiple areas and managed, the partitioning function
based on the logical filesystem is usually used. However,
as stated above, once the disk is divided into partitions,
it is difficult to change the partitions in size or combine
one partition with another to create an enlarged one. Since
in this embodiment, area division is not performed by the
partitioning function, one partition is formed so as to manage

CA 02528035 2001-02-22
14
the entire user area of the disk as shown in Fig.2. Areas
for recording specified types of information are defined
within the created partition. Since the partitioning
function is not used and since the UDF as one of general purpose
filesystems is used, there exists no management information
which manages multiple areas within one partition at the
logical filesystem level. Here, important is the fact that
there is a possibility of one disk being used based on multiple
platforms. For example, there is a possibility that a disk
which has been recorded for AV usage might be accessed from
a drive of a PC. Therefore, it is not good enough if area
securement is performed based only on the information that
can be understood only by a particular application such as
an AV application. In other words, defining an area for
recording a particular type of information not only means
management of the recording areas in accordance with the types
of data of AV usage but also limiting data to be written into
the secured area even if an access is made from a PC application
or the like. In order to achieve this, the secured area must
look as if it had data already recorded and were being occupied,
from the viewpoint of the logical filesystem.
For this purpose, in the present invention, in order
to secure an arbitrary number of continuous areas for recording
particular types of information, a dummy file is created to
manage the unused portion where no data is recorded in the

CA 02528035 2001-02-22
area. That is, the unused portion in the area is made
to show up as if data on the disk managed by the dummy
file had been written therein.
In the UDF, there is management information at the
5 volume level and management information at the
filesystem level. The management information at the
filesystem level, which is concerned herein, will be
briefly described. Within the partition defined by the
management information at the volume level, the space
10 bitmap descriptor for managing the blank space, the file
set descriptor including the basic information of the
director structure in the partition and the pointer
information to the file entry that manages the root
directory, the terminating descriptor representing that
15 the file set descriptor terminates and the file entry of
the root directory are recorded basically as the
management information at the filesystem level.
Within the space bitmap descriptor, one bit is
allotted to every logical block managed in the partition
so that whether each logical block is used or not is
indicated by the value of the bit data, either 0 or 1.
Here, the logical block is the smallest accessible unit
in the filesystem and each logical block within the UDF
partition is allotted with a logical block number in
ascending order.
Once the directory is defined, the file entry that
manages the directory will manage the files included in
the directory and the recording position of the set of

CA 02528035 2001-02-22
16
file identifier descriptors corresponding to the
directory. The file identifier descriptor holds address
information at which the name of a file or directory and
the file entry corresponding to attribute data are
recorded. The file entry manages the attribute data
such as date, etc., and the positional information on
the disk of the data managed by this file (file entry)
or if it is a directory, the positional information at
which the directory information (in the case of a file
identifier descriptor) is recorded. In this way, it is
possible to grasp the directory hierarchy by tracking
the file entry and file identifier descriptor. These
pieces of information form the management information of
the UDF filesystem and are usually used by the
filesystem driver only so that they cannot be usually
seen by the user. Fig. 4 shows the relationship between
file entries and file identifier descriptors for
representing the directory hierarchy in the UDF.
As an example of area securement using a dummy
file, Fig. 2 shows the way areas 1, 2 and 3 are defined
as continuous areas for recording an arbitrary number of
pieces of information of a particular type and files,
FILE1.DAT, FILE2.DAT and FILE3.DAT are recorded in
continuous area 2. In an actual disk, the FE (file
entry) of the UDF management information corresponding
to FILE1.DAT and the data itself

CA 02528035 2001-02-22
17
or file 1 are recorded. In this example, the file identifier
descriptor including the pointer information to FE( file entry)
of the file management information is not illustrated assuming
that it is recorded in area 1, for example.
The positional information on the disk is managed by
the set of allocation descriptors each indicating the starting
logical block number and the number of logical blocks. That
is, when the data managed by a single file(file entry) has
been recorded continuously, the positional information of
a file is managed by one allocation descriptor. When the data
has been recorded in separate two parts, the positional
information of the file is managed by two allocation
descriptors.
Similarly to FILE1.DAT, FEs(file entries) and their
actual data corresponding to FILE2.DAT and FILE3.DAT are
recorded in the secured continuous area. At this stage, a
dummy file DUMMY1. DAT is created for the unused part in which
no data is recorded within the secured continuous area. That
is, dummy file DUMMY1.DAT is formed as if data were written
in the unused area. This dummy file is managed by the
allocation descriptor of the FE(file entry). The space bitmap
descriptors which, as the UDF filesystem management
information, manage the blank space, in the part managed by
dummy file DUMMYI.DAT are treated as being used.
During the use process, if, for example, FILE2.DAT in

CA 02528035 2001-02-22
18
Fig.3 is erased, the area in which the FE(file entry) and
data corresponding to FILE2.DAT was recorded is indicated
as being unused by their space bitmap descriptors and becomes
set free. However, in the present invention, the portion where
the data was erased will not be set free but is treated as
being managed by the aforementioned dummy file DUMMY1. DAT,
as shown in the drawing. Upon this, the allocation descriptor
in the FE(file entry) of DUMMY1.DAT is updated so that
DUMMY1.DAT is made up of two separated parts.
When a dummy file is created, the name of the dummy file
should be defined as being understandable by the driver of
the filesystem which uses the secured continuous area. In
the example of the drawing, the dummy file in the secured
continuous area is defined as DUMMY1.DAT. This DUMMY1.DAT
is recognized as a blank space from the viewpoint of the
filesystem driver corresponding to the present invention.
Thus, by always creating a dummy file so as to control
the unused portion in the secured continuous area, the whole
of this area will be regarded as being used by applications
other than that specified to use this area, so that no data
will be written in. Further, this configuration not only
inhibits data writing from other applications, but also makes
it possible for the filesystem driver defining this dummy
file to obtain the information as to the dummy file and thereby
easily grasp the size and position of the unused portion in

CA 02528035 2001-02-22
19
the secured area. For example, the size of the unused portion
can be known by referring to the file size of the dummy file,
and the positional information can be easily obtained by
referring to the allocation descriptor in the FE(file entry)
of the dummy file. In short, the dummy file itself represents
the unused portion in the secured area.
When a multiple number of the filesystem drivers of
different manufacturers which all can recognize the dummy
file is provided, the secured continuous area is not always
consistent in size between the manufacturers. Also in this
case, only referring to the dummy file information enables
grasp of the unused portion in the secured area, so that it
is possible to provide compatibility between the manufacturers
without limiting the area size. Further, the area size-can
be grasped, if required, from the information relating
to the dummy file and files to be recorded within the area.
Referring now to the flowchart shown in Fig.5, the
procedures of securing the continuous area of a specified
size for recording new information of a particular type will
be described in detail. When a request for securing a
continuous area occurs at Step Si, blank spaces on the disk
are searched and grasped by referring the space bitmap
information of the management information of the UDF logical
filesystem at Step S2. When a needed continuous area cannot
be secured at any place on the disk at Step S3, an error routine

CA 02528035 2001-02-22
is made at Step S5 and the operation is ended. At Step S3,
when the needed continuous area can be secured at a site on
the disk, a dummy file is created at Step S4 in such a manner
that it manages the continuous area to be secured, and the
5 operation is ended. Specifically, the pointer information
of the dummy file to the file entry, i.e. , the file identifier
descriptor is added to the directory information of the
directory on which the dummy file is created and the file
entry for managing the positional information and attribute
10 information of the data of the dummy file is recorded. At
this time, the starting logical block number and the number
of logical blocks as the positional information of the secured
area are recorded in the allocation descriptor in the file
entry.
15 Next, the procedures when a file creation request arises
will be described. When a file creation request has occurred,
it is judged as to which area the file can be written in.
For example, there are divided areas, namely, area 1, area
2, area 3 = = = , as shown in Fig. 2. In this case, it is assumed
20 that when a certain AV application made a write request of
a file, the file is adapted to be written into area 1. This
determination is made, for example, by instructing the
filesystem driver to cause the AV application to write into
the position of DUMMY1.DAT. Other applications, f or example,
PC applications other than the AV application will not write

CA 02528035 2001-02-22
21
over DUMMY1.DAT but will write into the other areas.
It is also possible to make control such that video data,
for example, is written on DUMMY1. DAT and audio data is written
on DUMMY2. DAT, by def ining write areas (corresponding to dummy
data) in accordance with the usage purposes of files.
In one word, it becomes possible to write a file of a
predetermined type into a predetermined area.
Referring next to the flowchart shown in Fig.6, the
procedures when a file is created inside the area secured
by the dummy file after the determination of the write area
will be described in detail.
When a file creation request occurs at Step S10, dummy
file information is obtained at Step S11. Specifically,
referring to a file entry corresponding to a file defined
as a dummy file based on its file name, the file size and
positional information as to the dummy file is obtained from
that information. At Step S12, it is determined whether the
file size of the dummy file, or the blank size in the secured
area is greater than the size of the file to be created. When
the size of the dummy file is smaller than that of the file
to be created, there is no space to create the file in the
secured area so that an error routine is performed at Step
S15 and the operation is ended. At Step S12, when the size
of the dummy file is greater than that of the file to be created,
the file can be created in the secured area, so that the file

CA 02528035 2001-02-22
22
is created in the blank portion which is managed by the dummy
file, at Step S13.
Specifically, the pointer information to the file entry
for managing the file, i.e., the file identifier descriptor
is added to the directory information of the directory to
which the file to be created belongs, and the file entry for
managing the positional information and attribute information
of the data of the file is recorded. At Step S14, the file
entry of the dummy file is updated to end the operation. For
this, updating is performed by deducting the part allotted
for the new file from the allocation descriptor information
in the file entry.
Next, referring to the flowchart shown in Fig.7, the
procedures to be effected when a file belonging to the area
secured by the dummy file is updated with change in size.
When a request for updating a file with change in file
size occurs at Step S20, it is determined whether the size
of the file becomes larger or smaller, at Step S21. When the
file is reduced in size, the allocation descriptor in the
file entry of the file to be reduced is updated so as to manage
the reduced data, at Step S28. At Step S29, updating is
performed by adding the amount by which the file is reduced
to the allocation descriptor of the file entry of the dummy
file. When the file is expanded in size, the information on
the dummy file is gained at Step S22 so that the blank part

CA 02528035 2001-02-22
23
within the secured area is grasped. At Step S23, the size
of the dummy file or the size of the unused space in the secured
area is compared with the data size of the newly expanded
file. When the dummy file is greater in size, or when the
blank part in the secured area is large enough, the enlarged
data is recorded into the unused space being managed by the
dummy file at Step S24. At Step S25, the allocation descriptor
of the file entry of the expanded file is updated. At Step
S26, the allocation descriptor of the file entry of the dummy
file is updated to end the operation. At Step S23, if the
enlarged data is larger in size than the dummy file or when
there is not a blank space large enough to allow for enlargement,
the error routine is performed at Step S27 to end the operation.
Referring to the flowchart shown in Fig. 8 is a case
where a file belonging to the area managed by the dummy
file is erased, is detailed. At Step S30, when a request
for erasing a file occurs, erasure of the file is
performed at Step S31. Specifically, from the directory
information of the directory including the file to be
erased, the corresponding file identifier descriptor is
erased. At Step S32, the file entry of the dummy file is
updated to end the operation. In effect, the allocation
descriptor of the dummy file is updated so that the dummy
file will manage the portion where the erased file was
recorded.
Referring to the flowchart shown in Fig. 9, detailed

CA 02528035 2001-02-22
24
description will be made on the procedures in the case where
the area size needs to be enlarged when the area secured by
the dummy file is insufficient.
When a request for area enlargement occurs at Step S40,
the blank space on the disk is grasped by the space bitmap
at Step S41. It is determined at Step S42 whether a continuous
area having a space equivalent to the needed expansion exists
adjacent to the are to be expanded. If there is, the file
entry of the dummy file is updated at Step S44 in such a manner
that the updated file will include the expanded area. If there
is no adjoining continuous area having a space equivalent
to the needed expansion exists, the continuous area securing
process shown in Fig.9 is carried out to end the operation.
In this case, the expanded area is not continuous to the existing
area. If the expanded area should be continuous, the operation
may be ended with an error routine without performing the
continuous area securing process at Step S43. Fig.10 shows
an example in that a certain area is expanded. In this example,
FILE1.DAT, FILE2.DAT and FILE3.DAT were recorded in area 1,
leaving no blank space and a separate continuous area on the
disk was secured after a vain attempt of expansion of the
area using the adjoining area because the adjacent area 2
was already occupied. The blank space in area 1 is managed
by the dummy file having a file name of DUMMY1. DAT while the
blank space in the expanded area of area 1 is managed by the

CA 02528035 2001-02-22
dummy file with a file name of DUMMY2.DAT. Here, since the
file name is defined, it is possible to grasp from the existence
of DUMMY2. DAT the fact that an expanded, continuous area exists
at a separated position on the disk. Further, when the
5 existing continuous area needs to be expanded but continuous
expansion is impossible because the adjacent area is being
occupied, the data adjacent may be displaced to another place
on the disk so as to make the area empty and perform continuous
expansion.
10 In this way, since the partitioning function
of the logical filesystem is not used, it is possible to change
the area size by updating the dummy file only, which is a
far simpler procedure compared to the case where the size,
etc. of partitions are altered.
15 To manage the blank space in the defined continuous area
with a dummy file, it is also possible to add a requirement
that the last logical block in the continuous area must be
managed by the dummy file as shown in Fig. 11. That is, one
logical block at the last end in the continuous area is always
20 reserved as the space to be managed by the dummy file.
Therefore, one logical block and one logical block for
recording the file entry managing the dummy file, or two more
logical blocks in total should be reserved other than the
size of a desired continuous area. Therefore, for the
25 allocation descriptor in the file entry managing the dummy

CA 02528035 2001-02-22
26
file DUMMY1.DAT, the greatest logical block number will
indicate the trailing end of the secured continuous area.
With this configuration, it is possible to prevent the boundary
of the continuous area from becoming unclear when a data file
is recorded to the last of the continuous area and makes it
easy to grasp the boundary of the continuous area.
When files to be recorded in the secured continuous area
have been determined, it is possible to grasp the range of
the continuous area from the allocation descriptors of the
file entries and the information of the dummy file. However,
if the names etc. of the files recorded in the continuous
area have been undetermined, it is impossible to judge to
which continuous area the recorded data belongs from the file
name. Therefore, in this case, it is possible to grasp the
blank space from the dummy file but it is impossible to grasp
the range of the secured continuous area. Therefore, to deal
with such a case, it is also possible to add a requirement
that the first and the last logical blocks in the continuous
area must be managed by the dummy file as shown in Fig.12.
That is, one logical block at the first and last end in the
continuous area is always reserved as the space to be managed
by the dummy file. Therefore, two logical blocks and one
logical block for recording the file entry managing the dummy
file, or three more logical blocks in total should be reserved
other than the size of a desired continuous area.

CA 02528035 2001-02-22
27
Alternatively, as shown in Fig. 13, it is also
possible to impose a requirement that the first logical
block of the continuous area to be secured should be the
file entry managing the dummy file and one logical block
at the trailing end should be the space to be managed by
the dummy file.
With this configuration, the smallest logical block
number in the allocation descriptor in the file entry
managing the dummy file DUMMY1.DAT, or the number of the
logical block where the file entry itself of the dummy
file is recorded will indicate the starting position of
the secured continuous area while the largest logical
block number will indicate the rear end of the
continuous area. Thus, this makes it easy to grasp the
range of the continuous area being managed.
Referring next to Fig. 14 a practical application
example of the present invention will be described.
This drawing shows an example of area management for AV
usage to record AV data. First, the whole area is
managed by dividing it into a filesystem management
information area, an application management information
area and a data area. Recorded in the filesystem
management information area are the basic management
information based on the UDF filesystem including the
space bitmap descriptor(SBD), file set descriptor (FSD)
and terminating descriptor (TD), the file entry (FE) of
the directory defined by the AV application, and file
identifier descriptors (FID), as the pointer information

CA 02528035 2001-02-22
28
to the file entries managing the files and directories
defined in the directory. In the example of this
drawing, configuration of the ROOT directory, AVMAN
directory for recording the management information of AV
data, the file entry for managing the AVDAT directory
for recording AV data, sets of file identifier
descriptors (FID) of the files defined in different
directories are recorded. A dummy file LOGI.DMY manages
the unused portion in the filesystem management
information area.
The application management information area is the
area in which the management information of the AV
application such as the management information for
reproducing AV data is recorded. In this area,
AVINF01.DAT and AVINF02.DAT as the management
information of AV data, are recorded. The file entry
and the data entry corresponding to each are recorded on
the disk. Similar to the file-system-management
information area, dummy file APPL.DMY manages the unused
portion in the application management information area.
When accessing the thus configured disk, the user will
see the directory hierarchy shown in Fig. 15.
In the data area, AV data, namely, AV1.DAT and
AV2.DAT are recorded. The file entry and the data entry
corresponding to each are recorded on the disk. In the
example of this drawing, though, as to the data area, no
area reservation in the data area using a dummy file is
made, it is possible to define a dummy file as necessary
to secure an area.

CA 02528035 2001-02-22
29
In this way, the unused portion in the filesystem
management information area is managed by the dummy file
LOGI.DMY. The unused portion in the application management
information area is managed by the dummy file APPL. DMY . For
the AV application using these areas, these dummy files are
handled by managing the blank portions in the associated areas.
For example, when the disk thus conditioned is accessed from
a disk drive connected to a PC, it looks as if files were
recorded in the filesystem management information area and
in the application. management information area leaving no
blank spaces. This is equivalent to the fact that these areas
are secured. Therefore, no data will be written into these
areas.
Since it causes a serious problem if the directories
used in the AV application, the management information as
to AV data and the like are erased from a PC application,
the attributes of these files and directories may be designated
as being write protected. That is, the PC application will
only be able to write into the blank spaces in the data area.
Not to mention, it is seriously inconvenient if the dummy
file itself is erased, so that it is possible to set up file
attributes that keep any data from being written in. The
dummy files may be set up with 'hidden' file attributes in
order to keep its file name from appearing on the PC application.
If a dummy file was erased accidentally, it is possible to

CA 02528035 2001-02-22
reconstruct the dummy file based on the logical filesystem
management information as to the currently defined files and
directories and the information as to the space bitmap
descriptor managing the blank space.
5
Industrial Applicability
As has been described heretofore, the file management
method according to the present invention, since it is possible
to write data other than the desired data into the predetermined
10 area without performing partitioning based on the logical
filesystem, the method can be applied to multipurpose disk
media used in common by different platforms such as for PC
usage and AV usage.

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

2024-08-01:As part of the Next Generation Patents (NGP) transition, the Canadian Patents Database (CPD) now contains a more detailed Event History, which replicates the Event Log of our new back-office solution.

Please note that "Inactive:" events refers to events no longer in use in our new back-office solution.

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Event History , Maintenance Fee  and Payment History  should be consulted.

Event History

Description Date
Time Limit for Reversal Expired 2014-02-24
Letter Sent 2013-02-22
Grant by Issuance 2011-12-13
Inactive: Cover page published 2011-12-12
Inactive: Final fee received 2011-09-22
Pre-grant 2011-09-22
Letter Sent 2011-06-17
Amendment After Allowance Requirements Determined Compliant 2011-06-17
Inactive: Amendment after Allowance Fee Processed 2011-05-18
Amendment After Allowance (AAA) Received 2011-05-18
Notice of Allowance is Issued 2011-03-25
Letter Sent 2011-03-25
Notice of Allowance is Issued 2011-03-25
Inactive: Approved for allowance (AFA) 2011-03-23
Amendment Received - Voluntary Amendment 2010-04-01
Amendment Received - Voluntary Amendment 2010-03-12
Inactive: S.30(2) Rules - Examiner requisition 2009-10-22
Amendment Received - Voluntary Amendment 2008-05-28
Amendment Received - Voluntary Amendment 2008-03-03
Inactive: Office letter 2006-03-09
Inactive: Office letter 2006-03-09
Inactive: Cover page published 2006-02-13
Inactive: IPC assigned 2006-02-02
Inactive: First IPC assigned 2006-02-02
Inactive: IPC assigned 2006-02-02
Letter sent 2006-01-13
Divisional Requirements Determined Compliant 2006-01-12
Letter Sent 2006-01-12
Application Received - Regular National 2006-01-12
Application Received - Divisional 2005-12-23
Request for Examination Requirements Determined Compliant 2005-12-23
All Requirements for Examination Determined Compliant 2005-12-23
Application Published (Open to Public Inspection) 2001-08-30

Abandonment History

There is no abandonment history.

Maintenance Fee

The last payment was received on 2011-01-11

Note : If the full payment has not been received on or before the date indicated, a further fee may be required which may be one of the following

  • the reinstatement fee;
  • the late payment fee; or
  • additional fee to reverse deemed expiry.

Patent fees are adjusted on the 1st of January every year. The amounts above are the current amounts if received by December 31 of the current year.
Please refer to the CIPO Patent Fees web page to see all current fee amounts.

Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
SHARP KABUSHIKI KAISHA
SHARP KABUSHIKI KAISHA
Past Owners on Record
HIROYUKI YAMAMURA
JIRO KIYAMA
MOTOHIDE NISHIMURA
NATSUKO IKEDA
TAKAYOSHI YAMAGUCHI
YURI IWANO
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column (Temporarily unavailable). To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.

({010=All Documents, 020=As Filed, 030=As Open to Public Inspection, 040=At Issuance, 050=Examination, 060=Incoming Correspondence, 070=Miscellaneous, 080=Outgoing Correspondence, 090=Payment})


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Description 2001-02-21 33 1,162
Abstract 2001-02-21 1 18
Drawings 2001-02-21 12 217
Claims 2001-02-21 4 95
Representative drawing 2006-02-09 1 9
Description 2010-03-11 33 1,190
Claims 2010-03-11 4 104
Description 2010-03-31 33 1,170
Claims 2010-03-31 4 102
Description 2011-05-17 33 1,170
Acknowledgement of Request for Examination 2006-01-11 1 177
Commissioner's Notice - Application Found Allowable 2011-03-24 1 163
Maintenance Fee Notice 2013-04-04 1 171
Correspondence 2006-01-11 1 38
Correspondence 2006-03-09 1 15
Fees 2007-01-10 1 35
Fees 2008-01-13 1 40
Fees 2009-01-15 1 36
Correspondence 2011-09-21 1 27