JP5089353B2 - Program, file management apparatus and file management method - Google Patents

Description

The present invention relates to a program , a file management apparatus, and a file management method suitable for managing processing between a plurality of files related to each other .

  As a method for managing image files, there has been proposed a method that adopts a format in which high-resolution real image data and low-resolution thumbnail image data are combined into one image file as in the DCF (Design Rule for Camera File system) standard. Yes. In this management method, high-resolution image data is referred to when detailed information of image data is desired, and low-resolution image data is referred to when an outline of the image data is known. Therefore, there is an advantage that information to be referred to can be selected depending on the purpose of using the image data.

  On the other hand, in the image data management method, the low resolution image data and the high resolution image data are always configured as one file. For this reason, it is only necessary to know the outline of the image data, and even when high-resolution image data is not referred to, there is a problem that it must be handled as a large file size including high-resolution image data. In particular, in data communication such as e-mail and facsimile, it is important to improve the data size of image files to be transmitted and received.

  Regarding the efficiency improvement of the data size of the image file, Patent Document 1 describes the following technique. First, low-resolution image data and high-resolution image data are separated, and only low-resolution image data is attached to an e-mail and transmitted. Then, the receiving party acquires the high-resolution image data by another communication means according to the instruction written in the e-mail only when the high-resolution image data is necessary.

  However, in the management method disclosed in Patent Document 1, when acquiring high-resolution image data, it is necessary to follow an instruction of an e-mail attached with low-resolution image data. That is, it is impossible to refer to an image file including high-resolution image data by using only an image file including low-resolution image data as a clue.

  Patent Document 2 describes the following technique. First, among the first original image files, a second image file having only a thumbnail having a resolution lower than that of the first image is cut out from the first image file. Usually, the second low-resolution image is handled, and the first high-resolution image data is used as necessary, so that the high-resolution data and the low-resolution data are managed separately.

  Patent Document 3 describes a procedure for acquiring high-resolution data from low-resolution data using an image file divided according to the division management method of Patent Document 2.

  As described above, the management method of Patent Document 2 is an invention of the format specification relating to the image division management method, and Patent Document 2 proposes a procedure for creating an image file in accordance with the division management method. The image data processing method of Patent Document 3 is an invention relating to an image acquisition method, and a procedure for acquiring an image file divided according to the division management method of Patent Document 2 has been proposed.

  However, neither Patent Document 2 nor Patent Document 3 describes a process for deleting the first original image file (high resolution data) and the second thumbnail image file (low resolution data). .

  Regarding the technology for deleting images that are related to each other, Patent Document 4 describes the creation of a relational file for managing the correspondence between a main image and one or more different sub-images, and deleting the image based on this information. The technique to be performed is described. There are three types of image deletion methods: erasing all main images and sub-images / erasing all sub-images / erasing only one sub-image selected.

  Patent Document 5 discloses a technique for creating a thumbnail image file name from the directory name of the original image and the file name of the original image when creating the thumbnail image from the original image, and associating the original image with the thumbnail image. Is described. When either one is deleted, the other is automatically deleted.

JP-A-10-233860 JP-A-2005-326908 JP 2006-139632 A Japanese Patent No. 3556265 JP 2003-208448 A

  However, if the technique described in Patent Document 4 or 5 is adopted, the operation and processing tend to be complicated. Also, the main image or the original image may disappear unexpectedly.

An object of the present invention is to provide a program , a file management apparatus, and a file management method that can smoothly perform processing when deleting a plurality of mutually related files.

  Here, how to use the first original image file (high resolution data) and the second thumbnail image file (low resolution data) described in Patent Document 2 or Patent Document 3 will be examined. It is assumed that the first original image file is stored in a server on the network or the user's personal computer, and the second thumbnail image file is stored in an electronic device such as the user's digital camera or PDA (Personal Digital Assistant). The Then, when the user browses the second thumbnail image file on the electronic device and wants to print a specific image or handle an image of a larger size, the first original image corresponding from the server etc. It is also assumed that a file is obtained. In addition, when the user wants to distribute the image file to another person, since the data size increases when the first original image file is distributed, it is assumed that the second thumbnail image file having a small data size is copied and distributed. Is done. Furthermore, in order for the user to view the second thumbnail image file with a plurality of electronic devices such as a digital camera, a PDA, and a mobile phone, the second thumbnail image file is copied and stored in another electronic device. Is also envisaged. For this reason, one first original image file is stored in the server or the like, whereas the second thumbnail image file is stored in a plurality of electronic devices of the user or distributed to others. To do. That is, it is assumed that there are a plurality of thumbnail image files.

  Next, image file deletion processing will be considered. When the first original image file and the second thumbnail image file are in a one-to-one relationship, if one of them is deleted, the other is deleted for the sake of simplifying the operation and processing. It is desirable that Since the image file browsed by the user is often the second thumbnail image file, when the second thumbnail image file is deleted, the corresponding first original image file is also deleted. It is desirable to be associated.

  However, as described above, the first original image file and the second thumbnail image file are not necessarily in a one-to-one relationship, and the second thumbnail associated with one first original image file. There may be multiple image files. In such a case, inconvenience may occur if the first original image file is deleted only by deleting one second thumbnail image file. For example, the degree of importance may differ between the second thumbnail image file stored in the user's electronic device and the second thumbnail image file distributed by the user to another person. That is, even if the first original image file is very important for the user, it may be sufficiently satisfied for the distributed person to view it once. In such a case, it is also assumed that the distributed person immediately deletes the received second thumbnail image file. In such a case, if the first original image file is deleted, the problem of the distributed user cannot be measured. For this reason, there is a problem of when the first original image file should be deleted.

  Therefore, when creating a plurality of files related to each other, it is desirable to appropriately define conditions related to these deletions, and to perform deletion processing according to these conditions.

  As a result of intensive studies in view of such a situation, the present inventor has come up with various aspects of the invention described below.

Engaged Help program to the invention, stored on a computer, a second file containing information indicating the storage location of the first file, the storage location indicated by the information when deleting the second file An acquisition step for acquiring a second file including deletion information for determining whether to delete the first file that has been deleted, and a first deletion for deleting the second file acquired in the acquisition step A determination step of determining whether or not to delete the first file according to the deletion information included in the second file when receiving an instruction, and determination of deleting the first file in the determination step; And deleting the first file based on the information indicating the storage location of the first file included in the second file. A deletion instruction step of performing a 2 deletion instruction, check that the or the first file by said second deletion instruction in deletion instruction step is deleted, before removal of the second file to the first deletion instruction And if the deletion of the first file is confirmed in the confirmation step, the second file is deleted, and if the deletion of the first file is not confirmed in the confirmation step, And a deletion control step for restricting deletion of the second file in response to the first deletion command.

According to the present invention, the file, the deleted tag indicating information about the deletion of its derivatives Motofu Airu is attached, it can be associated with a deletion of the deletion and derived Motofu Airu the file. For this reason, the process at the time of deletion can be performed smoothly.

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

(First embodiment)
First, a first embodiment of the present invention will be described. FIG. 1 is a diagram showing an image file management system used for executing an image file management method according to the first embodiment of the present invention.

  As shown in FIG. 1, the image data processing system includes a server 1401 and a terminal (terminal device) 1406 connected to the server 1401 via a network 1405. The server 1401 includes a CPU 1402, a memory 1403, an HDD 1404, and the like. Also, the HDD 1404 stores a program related to the provision of an online photo album service, for example. The terminal 1406 is a personal computer, for example, and includes a CPU 1407, a memory 1408, an HDD 1409, and the like. In this embodiment, the server 1401 and the terminal 1406 function as an image file management apparatus. Note that a scanner, a digital camera, a PDA, or the like may be used as the terminal 1406. Note that a printer or the like may be used as the server 1401. As the network 1405, communication in a local environment such as USB may be used.

  The server 1401 and the terminal 1406 are provided with input interfaces, and an image recording apparatus 1410 storing image files can be connected to the server 1401 and the terminal 1406. The image recording device 1410 is a digital camera, for example.

  Here, the format of the image file processed in the present embodiment will be described. In the present embodiment, two types of image files, that is, an original image file (derived image file) and a shortcut image file (image file) are to be processed. The original image file is a file including image (original image) data obtained by photographing with a digital camera (imaging device), for example, and includes image data (original image data) having a high resolution. On the other hand, the shortcut image file is a file including image (shortcut image) data having a lower resolution than the original image data created based on the original image data. The shortcut image file includes at least the thumbnail image data of the original image data and information indicating the location of the original image file.

  In this embodiment, the DCF / Exif format is used as the basic format of the image file. Therefore, in the following description, as a term indicating a specific portion of an image file, a term indicating a corresponding portion in the DCF / Exif (Exchangeable Image File) standard (or JPEG standard) is used as necessary.

  FIG. 2 is a schematic diagram showing the format of the original image file (derived image file) and the shortcut image file.

  First, the original image file 100 will be described. The format of the DCF basic file of the original image file 100 includes “SOI (Start of Image)” 102, “APP1” 103, DCF basic main image data 104, and “EOI (End of Image)” 105. “SOI” 102 is a marker code (usually 0xFFD8) indicating the head of the compressed image data. “EOI” 105 is a marker code (usually 0xFFD9) that forms a pair with “SOI” 102 and indicates the end of the compressed image data. The DCF standard stipulates that data starts with SOI and ends with EOI. “APP1” 103 is an application marker segment, and additional information of the main image and thumbnail image data 106 which is low-resolution image data are stored in the data area of “APP1” 103. The file format of the thumbnail image data 106 includes “SOI” 102, “APP1” 107, DCF basic thumbnail image data 108, and “EOI” 105. Then, like the DCF basic file, it is defined that data starts with SOI and ends with EOI. Note that “APP1” 107 of the thumbnail image data 106 may have data having the same contents as “APP1” 103 of the DCF basic file. In contrast to the DCF basic thumbnail image data 108, the DCF basic main image data 104 is high-resolution image data.

  As described above, the original image file 100 compliant with the DCF standard in this embodiment includes the low-resolution DCF basic thumbnail image data 108 and the high-resolution DCF basic main image data 104 (first image data). ing. Therefore, the user can refer to the DCF basic thumbnail image data 108 to know the outline of the image, and can refer to the DCF basic main image data 104 to know the details of the image.

  Next, the shortcut image file 101 will be described. The file format of the DCF basic file of the shortcut image file 101 includes “SOI” 102, “APP1” 113, null data 114 and “EOI” 105. Thumbnail image data 116 is stored in the data area of “APP1” 113. Furthermore, an address tag 121 indicating the storage location of the original image file 100 and a deletion tag 122 indicating information related to deletion of the original image file 100 corresponding to the shortcut image file 101 are also stored in the data area of “APP1” 113. . When the deletion tag 122 indicates “OK”, when the shortcut image file 101 is deleted, the corresponding original image file 100 is also deleted. That is, when the deletion tag 122 affirms deletion of the original image file 100, the original image file 100 is also deleted. On the other hand, when the deletion tag 122 indicates “No”, even if the shortcut image file 101 is deleted, the corresponding original image file 100 is not deleted. Thus, unlike the original image file 100, the DCF basic main image data is not required, and NULL data 114 is stored instead. The file format of the thumbnail image data 116 (second image data) includes “SOI” 102, “APP1” 117, DCF basic thumbnail image data 118, and “EOI” 105. Then, like the DCF basic file, it is defined that data starts with SOI and ends with EOI. Note that “APP1” 117 of the thumbnail image data 116 may have data having the same content as “APP1” 113 of the DCF basic file.

  As described above, the shortcut image file 101 according to the present embodiment is provided with the address tag 121 and the deletion tag 122 in the data area of “APP1” 113 while conforming to the DCF standard. Also, main image data is not necessary.

  Note that the shortcut image file 101 may include main image data. A plurality of shortcut image files 101 may exist for one original image file 100. If the address tag 121 is included, it can be recognized that the file is the shortcut image file 101. In addition, a label such as a tag for identifying the file from the original image data may be attached. Good.

  Next, the data structure of the address tag 121 will be described. FIG. 3 is a diagram illustrating a data configuration of the address tag 121.

  The address tag 200 corresponding to the address tag 121 is recorded in the “Exif IFD” based on the Exif (DCF) protocol. As the tag number of the address tag 200, Tiff's private tag number (for example, 43000) is used.

  The tag value indicating the contents of the address tag 200 is recorded in the “Value of Exif IFD”. The storage location of the value is written in “Value Offset” of the address tag 200. “Tag”, “Type”, “Count”, and “Value Offset” of the address tag 200 are not particularly defined. For example, “Type” is set to “ANY”, and “Count” is also set to “Any”.

  The content 201 of the address tag 200 (value of the address tag) is configured as follows, for example. That is, as shown in FIG. 3, the character code type information 202 for identifying the subsequent character code is recorded at the head of “Value of address tag”. As this character code type information 202, for example, ASCII code, JIS code, Unicode, or other character code is designated.

  Following the character code type information 202, an address character string 203 indicating the storage location of the original image file 100 is recorded in “Value of address tag”. The address character string 203 includes a path name indicating the storage location of the original image file 100 and the file name of the original image file. The offset to “Value of the address tag” is written in “Value Offset” of the address tag 200 in accordance with the TIFF rules.

  Note that the character code type information 202 may not be recorded in “Value of the address tag”, but only the character string 203 indicating the address of the original image file 100 may be recorded. For example, when a fixed code (for example, UTF-8) is used as a character code, the character code type information 202 is not necessary. On the other hand, when encoding with UTF-16, it must begin with the byte order mark (“ZERO WIDTH NO-BREAK SPACE character”, 0xFEFF or 0xFFFE) as defined in Annex E of ISO / IEC 10646 and Appendix B of Unicode. Don't be. In addition, in order to explicitly identify the UTF-8, an identification code (0xEF 0xBB 0xBF) may be inserted in the first 3 bytes.

  Further, “Value of address tag” may be recorded in accordance with UDF. At this time, the character code type is recorded in the first 1 byte of the value, the character string length is recorded in the next 1 byte, and then an address character string indicating the storage location of the original image is recorded.

  In the present embodiment, such an address tag 121 is assigned to each shortcut image file 101. Therefore, an application or an image control apparatus that can access the shortcut image file 101 can obtain the storage location of the original image file 100 corresponding to the shortcut image file 101. Therefore, for example, even when the original image file 100 has a large file size, if the file is stored in the server 1401 or the like, the original image file 100 can be easily used via the shortcut image file 101 having a small file size. it can. That is, even when the storage capacity of the terminal 1406 is small, the original image file 100 can be accessed easily and accurately.

  If only the outline of the image data needs to be known, the shortcut image file 101 having a small file size that does not compress the memory area for storing the image may be used. If it is desired to obtain detailed information about the image, the original image file 100 may be used.

  Next, the data configuration of the deletion tag 122 will be described. FIG. 4 is a diagram illustrating a data configuration of the deletion tag 122.

  A deletion tag 700 corresponding to the deletion tag 122 is recorded in the “Exif IFD” based on the Exif (DCF) convention. As the tag number of the deletion tag 700, the private tag number of Tiff (for example, 43001) is used.

  The tag value indicating the contents of the deletion tag 700 is recorded in “Value of EXIF IFD”. The storage location of the value is written in “Value Offset” of the deletion tag 700. Although “Tag”, “Type”, “Count”, and “Value Offset” of the deletion tag 700 are not particularly defined, for example, “Type” is set to “ANY”, and “Count” is also set to “Any”.

  The contents 701 of the deletion tag 700 (Value of the deletion tag) are configured as follows, for example. That is, as shown in FIG. 4, the character code type information 702 for identifying the subsequent character code is recorded at the head of “Value of the deletion tag”. As this character code type information 702, for example, ASCII code, JIS code, Unicode, or other character code is designated.

  Following the character code type information 702, a character string 703 indicating whether or not the original image file 100 can be deleted is recorded in “Value of Delete Tag”. The offset to “Value of Delete Tag” is described in “Value Offset” of Delete Tag 700 in accordance with the TIFF rules.

  Note that the character code type information 702 may not be recorded in “Value of the deletion tag”, but only a character string 703 indicating information regarding deletion of the original image file 100 may be recorded. For example, when a fixed code (for example, UTF-8) is used as a character code, the character code type information 702 is not necessary. On the other hand, when encoding with UTF-16, it must begin with the byte order mark (“ZERO WIDTH NO-BREAK SPACE character”, 0xFEFF or 0xFFFE) as defined in Annex E of ISO / IEC 10646 and Appendix B of Unicode. Don't be. In addition, in order to explicitly identify the UTF-8, an identification code (0xEF 0xBB 0xBF) may be inserted in the first 3 bytes.

  In addition, “Value of deletion tag” may be recorded in accordance with UDF. At this time, the character code type is recorded in the first 1 byte of the value, the character string length is recorded in the next 1 byte, and then an address character string indicating the storage location of the original image is recorded.

  In the present embodiment, such a deletion tag 122 is attached to each shortcut image file 101. Therefore, an application or an image control apparatus that can access the shortcut image file 101 can acquire information related to deletion of the original image file 100 corresponding to the shortcut image file 101. Therefore, when the shortcut image file 101 is to be deleted, it can be easily determined whether or not the corresponding original image file 100 can be deleted.

  Next, a method for creating the shortcut image file 101 from the original image file 100 will be described. FIG. 5 is a flowchart showing a method for creating the shortcut image file 101. Although the shortcut image file 101 can be created in any of the server 1401, the terminal 1406, and the image recording device 1410, it is assumed that the shortcut image file 101 is created in the server 1401 in the following description. Note that the same processing is also executed when created in the terminal 1406 or the image recording device 1410.

  First, the CPU 1402 refers to the original image file 100 for which a shortcut image file is to be created (step S500). In the following description, it is assumed that the file name of the original image file 100 is “IMG — 0011.JPG”. Note that the storage location of the original image file 100 is not particularly limited as long as it is within a range accessible by the CPU 1402. For example, it may be stored in the server 1401 or may be stored in the terminal 1406 or the image recording device 1410.

  Next, the CPU 1402 determines whether or not the thumbnail image data 106 corresponding to the original image file 100 exists (step S501).

  If the thumbnail image data 106 exists in the original image file 100 as a result of step S501, the CPU 1402 extracts the thumbnail image data 106 (step S504). Next, the CPU 1402 determines that the thumbnail image data 106 is the thumbnail image data 116 (step S505).

  On the other hand, as a result of step S501, if the thumbnail image data 106 does not exist in the original image file 100, the CPU 1402 performs arbitrary thinning from the main image data 104 of the original image file 100. That is, the CPU 1402 creates reduced image data from the main image data 104 (step S502). Next, the CPU 1402 determines that the reduced image data is the thumbnail image data 116 (step S503).

  In this way, thumbnail image data 106 of the original image file 100 or image data obtained by reducing the main image data 104 of the original image file 100 is acquired as thumbnail image data 116.

  After step S503 or S505, the CPU 1402 generates an address tag 121 indicating a storage location of the original image file 100. Then, the CPU 1402 gives this to the thumbnail image data 116 (step S503 or S505) (step S506). Details of this processing will be described later.

  Thereafter, the CPU 1402 generates a deletion tag 122 indicating information related to deletion of the original image file 100. Then, the CPU 1402 adds this to the thumbnail image data 116 (step S503 or S505) (step S507). Details of the deletion tag creation processing will be described later.

  In this way, the shortcut image file 101 is created. The file name of the shortcut image file 101 created for the original image file 100 with the file name “IMG — 0011.JPG” is, for example, “img — 0011.JPG”.

  The shortcut image file 101 may include the same main image data 104 as the original image file 100.

  Further, the shortcut image file 101 may be created according to the flow shown in FIG. 5 following the creation of the original image file 100 associated with the photographing by the digital camera (image recording device 1410). That is, the creation process of the shortcut image file 101 may be a series of the creation process of the original image file 100.

  Next, a method for creating the address tag 121 in step S506 will be described. FIG. 6 is a flowchart showing a method for creating the address tag 121.

  The address tag 121 includes a path name (character string B) 602 indicating the storage location of the original image file 100, a file name (character string C) 603 of the original image file 100, and characters indicating the character codes of the character strings B and C. Code type information (character string A) 601 is included. As described above, the character code type information (character string A) 601 may not be included.

  First, the CPU 1402 determines how to determine the address of the original image file 100 (step S604). Here, it is determined whether the current storage location of the original image file 100 is set as the planned storage location of the original image file 100 or any other location is set as the planned storage location of the original image file 100.

  If the current storage location is determined as the storage location of the original image file 100 as a result of step S604, the CPU 1402 obtains the current storage location (address) of the original image file 100 as a path name (character string B) 602. (Step S605).

  On the other hand, if, as a result of step S604, an arbitrary storage location is set as the planned storage location of the original image file 100, a character string indicating the arbitrary storage location is acquired as a path name (character string B) 602 (step S606). ). The arbitrary storage location is set by the user using, for example, an application running on the server 1401. For example, it is set that the original image file 100 is always stored in “http://www.canon.co.jp/original-image/” of the server 1401.

  Here, it is assumed that “http://www.canon.co.jp/original-image/” is set in advance as the planned storage location of the original image file 100. Therefore, “http://www.canon.co.jp/original-image/” is acquired as the path name (character string B) 602.

  After step S605 or S606, the CPU 1402 acquires the file name (character string C) 603 of the original image file 100 (step S607). Here, “IMG — 0011.JPG” is acquired as the file name (character string C) 603.

  Next, the CPU 1402 combines the character code type information (character string A) 601, the path name (character string B) 602, and the file name (character string C) 603 to generate a character string indicating the address of the original image file 100. Create (step S608). At this time, the character code type information (character string A) 601 may not be included. For example, when the character string B and the character string C are encoded and described by UTF-8, the character string A is not necessary.

  Thereafter, the CPU 1402 creates an address tag 121 whose value is the character string created in step S607 and assigns it to the thumbnail image data 116 (step S503 or S505) (step S609). Here, an address tag 121 whose value is “http://www.canon.co.jp/original-image/IMG_0011.JPG” is attached to the shortcut image file 101 whose file name is “img_0011.JPG”. The

  Next, a method for creating the deletion tag 122 in step S507 will be described. FIG. 7 is a flowchart showing a method for creating the deletion tag 122.

  The deletion tag 122 includes deletion information (character string B) 802 indicating information related to deletion of the original image file 100 and character code type information (character string A) 801 indicating the character code of the character string B. As described above, the character code type information (character string A) 801 may not be included.

  First, the CPU 1402 determines whether or not the shortcut image file 101 to which the deletion tag 122 is to be attached is the shortcut image file 101 created first for the original image file 100 (step S803). In other words, the CPU 1402 determines whether or not the shortcut image file 101 is being created for the first time from the original image file 100.

  If the result of step S803 is the first shortcut image file 101, the CPU 1402 determines that the deletion information (character string B) 802 is “permitted” (step S805).

  On the other hand, if the result of step S803 is not the first shortcut image file 101, the CPU 1402 determines that the deletion information (character string B) 802 is “No” (step S804). This is to prevent a situation in which a plurality of shortcut image files 101 from which the original image file 100 can be deleted exist.

  Here, it is assumed that the first shortcut image file 101 is created in the original image file 100 whose file name is “IMG — 0011.JPG”. Therefore, “OK” is determined as the deletion information (character string B) 802.

  After step S804 or S805, the CPU 1402 combines the character code type information (character string A) 801 and the deletion information (character string B) 802 to create a character string regarding whether deletion is possible (step S806). At this time, the character code type information (character string A) 801 may not be included.

  Thereafter, the CPU 1402 creates a deletion tag 122 having the value of the character string created in step S806 as Value and attaches it to the thumbnail image data 116 (step S503 or S505) (step S807). Here, a deletion tag 122 with “OK” as Value is assigned.

  Thus, the shortcut image file 101 is created from the original image file 100 (FIGS. 5 to 7). For example, the shortcut image file 101 with the file name “img_0011.JPG” corresponding to the original image file 100 with the file name “IMG — 0011.JPG” stored in the server 1401 is created. The address tag 121 of the shortcut image file 101 is an address indicating the location (“http://www.canon.co.jp/original-image/IMG_0011.JPG”) where the original image file 100 is stored. A tag 121 is recorded. Therefore, an application or an image control apparatus that can access the shortcut image file 101 can access the storage location of the original image file 100 as necessary.

  Next, an example of a management method in the image data processing system shown in FIG. 1 for the original image file 100 created as described above and the shortcut image file 101 corresponding thereto will be described. FIG. 8 is a diagram illustrating an example of a relationship between an original image file and a shortcut image file.

  When the shortcut image file 101 is created in the server 1401 as described above, the shortcut image file 101 is transmitted to the terminal 1406 using e-mail or the like, for example. As a result, as shown in FIG. 8, the original image file 100 is stored in the server 1401, and the shortcut image file 101 is stored in the terminal 1406. Here, four types of original image files 100 (A, B, C, D) are stored in predetermined storage locations (“http://www.canon.co.jp/original-image/”) of the server 1401. Suppose that Further, shortcut image files 101 (a, b, c, d) corresponding to the four kinds of original image files 100 are represented by storage locations of the terminal 1406, for example, “C: \ My Pictures \ shortcut-image \”. Suppose that it is stored in a location.

  In the case of this example, as shown in FIG. 8, the storage location of the original image file 301 of “D” whose file name is “IMG — 0011.JPG” is “http://www.canon.co.jp/original-image/”. Is. Therefore, “http://www.canon.co.jp/original-image/IMG_0011.JPG” 303 is recorded in the address tag 121 of the shortcut image file 302 of “d”. Address tags 121 corresponding to the shortcut image files “a”, “b”, and “c” are also recorded.

  Further, it is assumed that the shortcut image file 302 of “d” is a shortcut image file created first from the original image file 301 of “D”. Accordingly, “OK” 304 is recorded in the deletion tag 122 of the shortcut image file 302 of “d”. As for the shortcut image files “a” to “c”, depending on whether or not the shortcut image files are first created from the original image files “A” to “C” corresponding to these shortcut image files. “Yes” or “No” is recorded.

  When such a state is formed, the user acquires an outline of the original image file 301 stored in the server 1401 only by referring to the thumbnail image of the shortcut image file 302 stored in the HDD 1409 or the like of the terminal 1406. be able to. That is, the user can acquire desired information without connecting the terminal 1406 to the server 1401. For example, it is assumed that the user acquires the original image file 100 by taking a picture with a digital camera (image recording device 1410) and stores it in the server 1401 that provides an online photo album service or the like. Further, it is assumed that the shortcut image file 101 is created from the original image file 100 on the server 1401. In such a case, the user can obtain desired information regarding the original image file 100 only by referring to the thumbnail image of the shortcut image file 101 stored in the HDD 1409 of the terminal 1406 or the like.

  Further, although a memory area is limited in a portable terminal such as a PDA, an outline of an image can be known even in such an environment if only the shortcut image file 101 is saved. If the user desires to acquire detailed image information, the original image file 100 may be acquired from the server 1401.

  The storage location of the original image file 100 is not limited. However, particularly when the original image file 100 is stored in the server 1401, the details of the original image file 100 can be acquired from the terminal 1406 that can be connected to the server 1401 if the shortcut image file 101 exists. It is. Therefore, in this case, the shortcut image file 101 may be used when image data is exchanged between users. For example, when sending a photographic image data using an e-mail, if a shortcut image file 101 that does not include main image data is attached, the e-mail file is compared with the case where the original image file 100 itself is attached. The size can be reduced. Then, if desired, the user who has received the shortcut image file 101 can access the server 1401 from the shortcut image file 101 to acquire the original image file 100 or acquire its detailed information.

  In addition, as a method for exchanging images with other users with a small file size, there is a method of acquiring an original image according to an instruction of an e-mail as described in Patent Document 1 described above. However, in this conventional method, it is necessary to refer to the instruction of the e-mail each time. On the other hand, according to the present embodiment, since the storage location of the original image file 100 is recorded in the shortcut image file 101, such complicated work is not necessary.

  In addition, according to the present embodiment, it is possible to exchange image data with other users by means other than e-mail while reducing the file size limit. For example, if only the shortcut image file 101 is stored in a memory card and the memory card is handed over to the other party, the other party can obtain an arbitrary original image file 100 from the memory card. For this reason, the electronic mail itself like patent document 1 becomes unnecessary.

  Although the details will be described later, since the value of the deletion tag 122 of the shortcut image file 101 of “d” is “Yes” 304, when the shortcut image file 101 is deleted, the value of “D” is appended. The original image file 100 is also deleted.

  Next, another example of a management method for the original image file 100 and the shortcut image file 101 corresponding to the original image file 100 will be described. FIG. 9 is a diagram illustrating another example of the relationship between the original image file and the shortcut image file. In the example shown in FIG. 8, the original image file 100 and the shortcut image file 101 are stored in different hosts (server 1401, terminal 1406). On the other hand, in the example shown in FIG. 9, the original image file 100 and the shortcut image file 101 are stored in different folders (directories) in one host (terminal 1406). Note that the original image file 100 and the shortcut image file 101 may be stored in different folders in one server 1401.

  For example, it is assumed that the original image file 100 is input to the terminal 1406 by the user, the shortcut image file 101 is created at the terminal 1406, and stored in a folder different from the original image file 100. Here, original image files 100 (A, B, C, D) are stored in folder A, and shortcut image files 101 (a, b, c, d) for these original image files 100 are stored in the same terminal 1406. Assume that it is stored in another folder. For example, the shortcut image files 101 of “a” to “d” are stored in the folder B, the shortcut image files 101 of “a” and “b” are stored in the folder C, and “a”, “c”, and “d” are stored. Is stored in the folder B. The folder A is represented by “C: \ My Pictures \ original-image \”, and the folder B is represented by “C: \ My Pictures \ shortcut-image \”. Further, it is assumed that the folder C is represented by “C: \ My Pictures \ children's photo \” and the folder D is represented by “C: \ My Pictures \ photographed in January 2003 \”.

  In the case of this example, as shown in FIG. 9, the storage location of the original image file 401 of “D” whose file name is “IMG — 0011.JPG” is “C: \ My Pictures \ original-image \”. Therefore, “C: \ My Pictures \ original-image \ IMG_0011.JPG” 403 is recorded in the address tag 121 of the shortcut image file 402 of “d”. Address tags 121 corresponding to the shortcut image files “a”, “b”, and “c” are also recorded.

  Further, it is assumed that the shortcut image file 402 of “d” in the folder B is a shortcut image file created second and later from the original image file 401 of “D”. Therefore, “No” 404 is recorded in the deletion tag 122 of the shortcut image file 402 of “d”. As for the shortcut image files “a” to “c”, depending on whether or not the shortcut image files are first created from the original image files “A” to “C” corresponding to these shortcut image files. “Yes” or “No” is recorded.

  When such a state is formed, the user simply refers to the thumbnail image of the shortcut image file 402 stored in the HDD 1409 or the like of the terminal 1406, and the user can view the outline of the original image file 401 stored in the other folder A. Can be acquired. That is, the user can obtain desired information without searching for the original image file 401. For example, it is assumed that the user acquires the original image file 100 by taking a picture with a digital camera (image recording device 1410) and stores it in the folder A. Further, it corresponds to the original image file 100. Assume that the shortcut image file 101 is saved in another folder. In such a case, the user can always save the original image files 100 collectively in a specific folder, and use the shortcut image file 101 when organizing the folders by shooting time and / or theme. it can.

  A plurality of shortcut image files 101 may be created for one original image file 100. For example, it is assumed that the original image file 100 of “A” includes image data created in January 2003, and the subject includes a child. In this case, the user includes the same shortcut image file “a” in two folders, folder C indicating that a child is shown in the image and folder D indicating that the shooting time is January 2003. Can do. If such a classification is performed, “a” corresponding to the original image file 100 of “A” will be searched both when searching for a photograph taken in January 2003 and when searching for a photograph showing a child. To the shortcut image file 101. The file size of the shortcut image file 101 can be reduced if main image data is not included. For this reason, even if the shortcut image file 101 associated with the plurality of categories from the same original image file 100 overlaps, an increase in the file size can be suppressed.

  Although details will be described later, since the value of the deletion tag 122 of the shortcut image file 101 of “d” in the folder B is “No” 404, the original “D” is deleted even if the shortcut image file 101 is deleted. The image file 100 is not deleted.

  Next, a method for deleting the original image file 100 and the shortcut image file 101 in the first embodiment will be described. FIG. 10 is a flowchart showing a method for deleting the original image file 100 and the shortcut image file 101. Here, as shown in FIG. 11, it is assumed that applications A and B operate on the terminal 1406 and application C operates on the server 1401. The application A is an application used for controlling an image such that a user views or deletes an image or issues a print instruction. The application B is an application that manages shortcut image files stored in the terminal 1406, for example. The application C is, for example, an application that manages original image files stored in the server 1401.

  First, a deletion request for the shortcut image file 101 is generated in accordance with a user instruction (step S1201). For example, based on a user instruction, the application A issues a shortcut image deletion request to the application B that manages the shortcut image.

  Next, the CPU 1407 confirms the deletion tag 122 of the shortcut image file 101 based on the application B as a tag determination unit (step S1202).

  As a result of step S1202, when the deletion tag 122 is “permitted”, the CPU 1407 determines that the original image file 100 needs to be deleted based on the application B. Then, the CPU 1407 acquires information on the address tag 121 of the shortcut image file 101 based on the application B (step S1203). As a result, a deletion request for the original image file 100 corresponding to the shortcut image file 101 can be issued.

  Thereafter, the CPU 1407 issues a deletion request for deleting the original image file 100 with reference to the address information acquired in step S1203 based on the application B as a deletion instruction means (step S1204). For example, the application B managing the shortcut image file 101 makes an original image deletion request to the application C managing the original image file.

  Subsequently, the CPU 1402 determines whether or not the original image file 100 that is the target of the original image deletion request can be deleted based on the application C (step S1205). For example, when the original image file 100 is used from another terminal using the application C, it is determined that it cannot be deleted.

  If the result of step S1205 is that deletion is possible, the CPU 1402 deletes the original image file 100 based on the application C (step S1206).

  Thereafter, the CPU 1402 returns a response to the original image deletion request to the application B based on the application C (step S1207). This response includes information on whether or not the deletion of the original image file 100 has been executed and the reason why the original image file 100 has not been deleted. If not deleted, for example, information indicating that “the deletion of the original image file failed” is included.

  On the other hand, if the result of step S1202 is that the deletion tag 122 is “NO”, the CPU 1407 determines that the original image file 100 need not be deleted based on the application B. Then, the CPU 1407 determines whether or not the shortcut image file 101 can be deleted based on the application B (step S1208). The process of step S1208 is also performed after step S1207. For example, when the shortcut image file 101 is used by another application in the terminal 1406, it is determined that it cannot be deleted.

  If the result of step S1205 is that deletion is possible, the CPU 1407 deletes the shortcut image file 101 based on the application B (step S1209).

  Thereafter, the CPU 1407 returns a response to the shortcut image deletion request to the application A based on the application B (step S1210). This response includes information as to whether or not the deletion of the shortcut image file 101 has been executed and the reason why the shortcut image file 101 has not been deleted.

  As described above, in this embodiment, it is possible to determine the necessity of deleting the original image file 100 from the deletion tag 122, and if necessary, obtain the storage location of the original image file 100 from the address tag 121. And can be deleted.

  If the result of the original image deletion response is “failure”, the processing in steps S1208 and S1209 may be omitted. In this case, at the time of the shortcut image deletion response in step S1210, it is preferable that information indicating that the deletion of the shortcut image file is omitted due to the deletion failure of the original image file 100 is included in the response. This is because it is possible to notify the user later by including such information in the response.

  As a cause of the failure in deleting the original image file 100, there is a communication failure between the application B and the application C in addition to the above-described usage state. Another reason is that the original image file 100 does not exist in a predetermined storage location. Another reason is that the area indicated by the address cannot be accessed for some reason.

  The original image file 100 may include an address tag indicating the storage location. Such a configuration is effective when the original image file exists in both the server and the terminal (client). For example, when printing from a client, the client is allowed to print by accessing the server from the address tag information held by the client and checking whether the original image has been changed on the server side It is effective when adopting. Here, instead of checking whether the original image has been changed, authentication as an official client may be performed. In such a configuration, when the shortcut image file is stored in the client, it is necessary to read the original image file after confirmation or authentication. However, if the original image file is stored in the client, the download for reading is required. Is no longer necessary. That is, after confirmation or authentication, printing can be performed using the original image file stored in the client without downloading the original image file. For this reason, the time required for downloading is omitted, and the time required for printing is shortened.

  Here, a specific deletion process when the shortcut image file 101 of “d” is stored in the terminal 1406 and the original image file 100 of “D” is stored in the server 1401 will be described.

  First, a process when the deletion tag 122 of the shortcut image file 101 of “d” is “No” will be described. FIG. 12 is a diagram illustrating processing when the deletion tag 122 is “NO”. In particular, FIG. 12A is a schematic diagram showing a request between applications, and FIG. 12B is a response diagram showing a deletion procedure interface.

  As shown in FIGS. 12A and 12B, in step S1201, the application A requests the application B to delete the shortcut image file 101 of “d” under the management 1003.

  Upon receiving this request, the application B confirms the deletion tag 122 of the shortcut image file 101 of “d” in step S1202. In this example, since the deletion tag 122 is “No”, the application B performs the process of step S1208 following step S1202. That is, the application B determines 1004 whether or not the shortcut image file 101 of “d” may be deleted. For example, when the shortcut image file 101 of “d” is being used by another application in the terminal 1406, it is determined that it cannot be deleted.

  If the determination result shows that the application B can be deleted, the application B deletes the shortcut image file 101 of “d”. Thereafter, the application B notifies the application A of whether or not the “d” shortcut image file 101 can be deleted and the reason for the deletion in a shortcut image deletion response 1005.

  In this example, since the processing of steps S1203 to S1207 is not performed, the processing in the server 1401 does not occur and the original image file 100 is not affected.

  Next, a process when the deletion tag 122 of the shortcut image file 101 of “d” is “OK” will be described. FIG. 13 is a diagram illustrating processing when the deletion tag 122 is “permitted”. In particular, FIG. 13A is a schematic diagram showing a request between applications, and FIG. 13B is a response diagram showing a deletion procedure interface.

  As shown in FIGS. 13A and 13B, in step S1201, the application A makes a request 1103 to the application B for deleting the shortcut image file 101 of “d” under the management of the application B.

  Upon receiving this request, the application B confirms the deletion tag 122 of the shortcut image file 101 of “d” in step S1202. In this example, since the deletion tag 122 is “permitted”, the application B performs the process of step S1203 following step S1202. That is, the application B acquires the information of the address tag 121 of the shortcut image file 101 of “d”, and thereafter issues an original image deletion request 1104 to the application C using this (step S1204).

  Next, the application C determines 1105 whether or not the original image file 100 of “d” may be deleted (step S1205). For example, when the original image file 100 of “D” is used from another terminal using the application C, it is determined that it cannot be deleted.

  If the result of determination 1105 is that deletion is possible, the application C deletes the original image file 100 of “D”. Thereafter, the application C notifies the application B of whether or not the original image file 100 of “D” can be deleted and the reason why the original image file 100 cannot be deleted through an original image deletion response 1106.

  Next, the application B determines 1107 whether or not the shortcut image file 101 of “d” may be deleted.

  If the determination result shows that the application B can be deleted, the application B deletes the shortcut image file 101 of “d”. Thereafter, the application B notifies the application A of whether or not the shortcut image file 101 of “d” can be deleted and the reason why the shortcut image file 101 cannot be deleted in a shortcut image deletion response 1108.

  If the deletion tag is not attached to the shortcut image file that has received the deletion command, the original image file may be deleted as it is.

(Second Embodiment)
Next, a second embodiment of the present invention will be described. In the first embodiment, the “permitted” deletion tag 122 is assigned to only one shortcut image file 101 for one original image file 100. On the other hand, in the second embodiment, a “permitted” deletion tag 122 can be assigned to a plurality of shortcut image files 101 for one original image file 100. In the following, description will be made centering on differences from the first embodiment. First, a method for creating the deletion tag 122 in the second embodiment will be described. FIG. 14 is a flowchart showing a method for creating the deletion tag 122.

  First, the CPU 1402 determines whether or not the shortcut image file 101 to which the deletion tag 122 is to be assigned should be “permitted” for the value of the deletion tag 122 (step S1303). In this determination, the CPU 1402 may request an input from the user, and may use a criterion as to whether the first shortcut image file 101 is the same as in the first embodiment.

  If the result of step S1303 is “Yes”, the CPU 1402 determines the deletion information (character string B) 802 as “Yes” (step S1305).

  Next, the CPU 1402 records the number of deletion information (character string B) 802 determined as “permitted” among the shortcut image files 101 created in the original image file 100 (step S1306).

  On the other hand, if the result of step S1303 is not “Yes”, the CPU 1402 determines that the deletion information (character string B) 802 is “No” (step S1304).

  After step S804 or S805, the CPU 1402 performs the same processing as in the first embodiment.

  Next, a method for deleting the original image file 100 and the shortcut image file 101 in the second embodiment will be described. Here, the content of step S1202 is different from that of the first embodiment.

  In step S <b> 1202 of the present embodiment, the CPU 1407 determines that the number of shortcut image files 101 whose deletion tag 122 is “permitted” and which has the “permitted” deletion tag 122 attached to the original image file 100 at that time. Is determined to be one. That is, the CPU 1407 analyzes the information indicated by the deletion tag 122 as a tag analysis step, and determines whether the number of shortcut image files 101 satisfying a predetermined condition is one. Only when these conditions are satisfied, the CPU 1407 determines that the original image file 100 needs to be deleted based on the application B.

  On the other hand, if the deletion tag 122 is “NO”, the CPU 1407 performs the processing of steps S1208 to S1210 as it is, as in the first embodiment. If the deletion tag 122 is “OK” and the number of the shortcut image files 101 to which the “Yes” deletion tag 122 is added is two or more, the CPU 1407 sets the deletion tag 122 to “No”. Change to As a result, the number of shortcut image files 101 to which the “permitted” deletion tag 122 is attached is reduced by one. Then, the CPU 1407 performs the processes of steps S1208 to S1210 without issuing the original image deletion request 1104. That is, the CPU 1407 determines whether to delete the shortcut image file 101 and issues a shortcut image deletion response 1108.

  Other configurations are the same as those of the first embodiment.

  In such a second embodiment, the authority to delete the original image file 100 is given to a plurality of shortcut image files 101, but only when there is a deletion request via all the shortcut image files 101. The file 100 is deleted. Therefore, it is possible to avoid the inconvenience that the original image file 100 has been deleted without knowing that the shortcut image file 101 to which the “permitted” deletion tag 122 is assigned is held.

  Note that the number of shortcut image files 101 to which the “permitted” deletion tag 122 is assigned is managed by the application B, for example, but may be managed by the application C. If the application C is managing, the CPU 1407 may access the server 1401 and acquire the number when determining in step S1202. In such a case, even when a plurality of users use the application B, processing can be easily performed.

  For example, it is assumed that the application B is individually installed in five terminals, and all of them store shortcut image files created from the same original image file. Assume that an original image deletion request is generated in one of the five terminals. In such a case, the number of shortcut image files to which the “permitted” deletion tag is assigned is reduced from five to four in the server 1401 regardless of the activation state of other terminals. This is because the number of shortcut image files 101 to which the “permitted” deletion tag 122 is assigned is managed by the server 1401. Therefore, easy processing is possible. After that, when an original image deletion request is generated in another terminal, the number of shortcut image files to which the “permitted” deletion tag is assigned is reduced from four to three in the server 1401.

(Third embodiment)
Next, a third embodiment of the present invention will be described. The third embodiment is different from the second embodiment in the method for deleting the original image file 100 and the shortcut image file 101. Here, the content of step S1202 is the same as that of the first embodiment, but the content of step S105 is different from that of the first embodiment.

  That is, in step S1205 of the present embodiment, the CPU 1402 determines whether the number of shortcut image files 101 to which the “permitted” deletion tag 122 is attached at that point in time for the original image file 100 is one. Only when the number of such shortcut image files 101 is one, the CPU 1402 determines that the original image file 100 needs to be deleted based on the application C.

  On the other hand, if the number of shortcut image files 101 to which the “permitted” deletion tag 122 is attached is two or more, the CPU 1402 counts the number of shortcut image files 101 to which the “permitted” deletion tag 122 is attached. Is reduced by 1, and the process of step S1207 is performed. That is, the CPU 1402 issues an original image deletion response 1106.

  Other configurations are the same as those of the first embodiment.

  Even in the third embodiment, the authority to delete the original image file 100 is given to a plurality of shortcut image files 101, but only when there is a deletion request via all the shortcut image files 101. The file 100 is deleted. Therefore, it is possible to avoid the inconvenience that the original image file 100 has been deleted without knowing that the shortcut image file 101 to which the “permitted” deletion tag 122 is assigned is held.

  The number of shortcut image files 101 to which the “permitted” deletion tag 122 is assigned is managed by the application C, for example.

  In any of the embodiments, it is preferable to confirm the deletion with the user prior to deleting the original image file 100. For example, when the application B issues an original image deletion request 1104, a dialog such as “Are you sure you want to delete the original image file?” Is displayed, and “Yes” or “No” is displayed to the external user. To select. The original image deletion request 1104 is issued only when the user permits it. Further, the following processing may be performed. That is, in the application C, when determining whether or not the original image file 100 can be deleted 1105, a dialog such as “Are you sure to delete the original image file?” Is displayed via the application B. . Then, the user is allowed to select “Yes” or “No”, and the result is acquired via the application B. Only when the user agrees, the original image file 100 is deleted.

  By performing such processing, it is possible to suppress deletion of the original image file 100 due to an erroneous operation.

  However, when such a process is performed, when the user refuses to delete the original image file 100, the original image file 100 is not deleted, and the shortcut image file 101 to which the “permitted” deletion tag 122 is added is displayed. May be deleted. That is, there is a possibility that the correspondence between the original image file 100 and the shortcut image file 101 cannot be taken. Therefore, the application A or B may be provided with a function of deleting the original image file independently from the shortcut image file. If the user refuses to delete the original image file 100, the deletion of the shortcut image file 101 created from the original image file 100 may be omitted.

  When the original image file 100 is deleted, the shortcut image file 101 to which the deletion tag 122 of “No” is attached may remain as it is even though the original image file 100 related thereto does not exist. possible. In such a case, even if the original image file 100 is used from the shortcut image file 101, it is impossible. Therefore, it is preferable to check the consistency between the shortcut image file 101 managed using the application B and the original image file 100 managed using the application C when the terminal 1406 and the server 1401 are connected. . As a result of the confirmation, if there is any shortcut image file 101 to which the original image file 100 corresponding to the shortcut image file 101 to which the deletion tag 122 of “NO” is assigned does not exist, the shortcut image file 101 is deleted. Also good. Further, without deleting, the user may be notified that the original image file 100 does not exist via the application B, and processing such as subsequent deletion may be left to the user.

  The embodiment of the present invention can be realized by, for example, a computer executing a program. Also, means for supplying a program to a computer, for example, a computer-readable recording medium such as a CD-ROM recording such a program, or a transmission medium such as the Internet for transmitting such a program is also applied as an embodiment of the present invention. Can do. The above-described print processing program can also be applied as an embodiment of the present invention. The above program, recording medium, transmission medium, and program product are included in the scope of the present invention.

It is a figure which shows the image file management system used for execution of the image file management method which concerns on the 1st Embodiment of this invention. It is a schematic diagram which shows the format of an original image file (derivation original image file) and a shortcut image file. It is a figure which shows the data structure of the address tag 121. FIG. It is a figure which shows the data structure of the deletion tag 122. FIG. 4 is a flowchart illustrating a method for creating a shortcut image file 101. 3 is a flowchart illustrating a method for creating an address tag 121. It is a flowchart which shows the method of producing the deletion tag 122 in 1st Embodiment. It is a figure which shows an example of the relationship between an original image file and a shortcut image file. It is a figure which shows another example of the relationship between an original image file and a shortcut image file. 4 is a flowchart illustrating a method for deleting an original image file 100 and a shortcut image file 101. It is a figure which shows the relationship between the server 1401 and the terminal 1406, and applications AC. It is a figure which shows a process in case the deletion tag 122 is "no". It is a figure which shows a process in case the deletion tag 122 is "possible." It is a flowchart which shows the method of producing the deletion tag 122 in 2nd Embodiment.

Explanation of symbols

100: Original image file 101: Shortcut image file 102: SOI
103: APP1
104: DCF basic main image data 105: EOI
106: Thumbnail image data 107: APP1
108: DCF basic thumbnail image data 113: APP1
114: Null data 116: Thumbnail image data 117: APP1
118: DCF basic thumbnail image data 121: Address tag 122: Delete tag

Claims (13)

On the computer,
Whether to delete the first file stored in the storage location indicated by the information when the second file is deleted, the second file including information indicating the storage location of the first file An acquisition step of acquiring a second file including deletion information for determination;
When receiving a first deletion command for deleting the second file acquired in the acquisition step, it is determined whether to delete the first file according to the deletion information included in the second file. A decision step;
When it is determined in the determining step that the first file is deleted, the first file is stored on the basis of information indicating a storage location of the first file included in the second file. A delete command step for performing a second delete command for deleting;
A confirmation step of confirming whether or not the first file has been deleted by the second deletion command in the deletion command step before the deletion of the second file in response to the first deletion command ;
When the deletion of the first file is confirmed in the confirmation step, the second file is deleted. When the deletion of the first file is not confirmed in the confirmation step, the first file is deleted. A deletion control step for restricting deletion of the second file in response to a deletion command;
A program characterized by having executed.   2. The deletion control step, wherein the second file is deleted according to the first deletion command even if it is determined in the determination step that the first file is not deleted. The program described in.   Where the device storing the first file is different from the device storing the second file, the second file stores the device storing the first file. In the delete command step, the second delete command for causing the device storing the first file to delete the first file is performed based on the information. The program according to claim 1 or 2.   In the confirmation step, information indicating whether or not the first file has been deleted is acquired from the device storing the first file, and whether or not the first file has been deleted based on the acquired information The program according to claim 3, wherein the program is confirmed.   When the plurality of second files are acquired in the acquisition step and the first deletion instruction for deleting any of the plurality of second files is received, the determination step includes the plurality of second files. Of the two files, the first information is deleted according to the deletion information included in the second file that has received the first deletion command and the deletion information included in another file of the plurality of second files. The program according to any one of claims 1 to 4, wherein it is determined whether to delete the file. Each of the first file and the second file includes image data;
6. The program according to claim 1, wherein the number of pixels of the image data included in the first file is larger than the number of pixels of the image data included in the second file. . An acquisition step of acquiring information indicating a storage location of the first file;
Creating the second file including the information obtained in the obtaining step;
The program according to any one of claims 1 to 6, wherein the program is executed. The first file includes first image data;
8. The creation step includes obtaining second image data having a smaller number of pixels than the first image data, and creating a second file including the second image data. The program described in.   The program according to claim 7 or 8, wherein the first file and the second file are stored in different devices. Whether to delete the first file stored in the storage location indicated by the information when the second file is deleted, the second file including information indicating the storage location of the first file Obtaining means for obtaining a second file including deletion information for determination;
When receiving a first deletion command for deleting the second file acquired by the acquisition means, it is determined whether to delete the first file according to the deletion information included in the second file. Judgment means,
When the determination means determines that the first file is to be deleted, the first file is stored on the basis of information indicating the storage location of the first file included in the second file. A delete command means for performing a second delete command for deleting;
Confirmation means for confirming whether the first file has been deleted by the second deletion instruction by the deletion instruction means before deleting the second file in response to the first deletion instruction ;
When the confirmation unit confirms the deletion of the first file, the second file is deleted. When the confirmation unit does not confirm the deletion of the first file, the first file is deleted. Delete control means for restricting deletion of the second file in response to a delete command;
A file management apparatus comprising: Obtaining means for obtaining information indicating a storage location of the first file;
Creating means for creating the second file including the information obtained by the obtaining means;
The file management apparatus according to claim 10, further comprising: Whether to delete the first file stored in the storage location indicated by the information when the second file is deleted, the second file including information indicating the storage location of the first file An acquisition step of acquiring a second file including deletion information for determination;
When receiving a first deletion command for deleting the second file acquired in the acquisition step, it is determined whether to delete the first file according to the deletion information included in the second file. A decision step;
When it is determined in the determining step that the first file is deleted, the first file is stored on the basis of information indicating a storage location of the first file included in the second file. A delete command step for performing a second delete command for deleting;
A confirmation step of confirming whether or not the first file has been deleted by the second deletion command in the deletion command step before the deletion of the second file in response to the first deletion command ;
When the deletion of the first file is confirmed in the confirmation step, the second file is deleted. When the deletion of the first file is not confirmed in the confirmation step, the first file is deleted. A deletion control step for restricting deletion of the second file in response to a deletion command;
A file management method characterized by comprising: An acquisition step of acquiring information indicating a storage location of the first file;
Creating the second file including the information obtained in the obtaining step;
The file management method according to claim 12, further comprising:

Images