DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to amendment
This office action is in response to an amendment filed on December 29, 2025 in response to PTO office action dated August 26, 2025. The amendment has been entered and considered.
Claims 2-6, 8, 10-13, 16-17, 20 have been cancelled. As a result, Claims 1, 7, 9, 14-15, 18-19, 21-33 are pending in this office action.
Applicant’s arguments with respect to the rejection of claims under 35 U.S.C. § 103(a) have been fully considered. However, Examiner respectfully disagrees with the applicant’s argument, for details please see response to argument section.
This action is FINAL.
Claims rejection 35 U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 7, 9, 14, 15, 18, 19, 21-23 and 28 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Kottomtharayil at el. (US 2013/0262386 A1) in view of Puga et al. (US 2011/0113205 A1) further in view of Chron et al. (US 20060288047 A1).
Regarding claims 1, 14 and 18 Kottomtharayil discloses a method, comprising:
storing, by a computer system, a plurality of base files in a memory (Kottomtharayil paragraph [0097], For each file, the synchronization server decides whether to store the file in its native format on the user device or whether to store the file in a preview format on the user device and move the corresponding native format version to a secondary or archive location in the network);
causing respective copies of the plurality of base files to be stored on an external storage device (Kottomtharayil paragraph [0097], For each file, the synchronization server decides whether to store the file in its native format on the user device or whether to store the file in a preview format on the user device and move the corresponding native format version to a secondary or archive location in the network; Kottomtharayil paragraph [0079], after converting a file from a native format to a preview format, the file in native format is moved to secondary storage and information about the location in the secondary storage is associated with the copy in the preview format. The location information is associated with the preview format file. One of several well known mechanisms such as the user resource locator (URL) indicator may be used for the association);
selecting, among the plurality of base files, one or more base files, wherein the one or more base files comprise a first base file (Kottomtharayil paragraph [0079], after converting a file from a native format to a preview format, the file in native format is moved to secondary storage and information about the location in the secondary storage is associated with the copy in the preview format. The location information is associated with the preview format file. One of several well known mechanisms such as the user resource locator (URL) indicator may be used for the association);
removing the one or more base files from the memory (Kottomtharayil paragraph [0097], For each file, the synchronization server decides whether to store the file in its native format on the user device or whether to store the file in a preview format on the user device and move the corresponding native format version to a secondary or archive location in the network; Kottomtharayil paragraph [0079], after converting a file from a native format to a preview format, the file in native format is moved to secondary storage and information about the location in the secondary storage is associated with the copy in the preview format);
retrieving a copy of the first base file from the external storage device (see Kottomtharayil paragraph [0084], the preview format comprises a picture encoding format such as a JPEG image, or a bitmap format or a GIF (graphics intermediate format) image or a PNG (portable network graphics) image, and so on. At 818, if the file requested is the native format file, then the system accesses the data structure to identify the location of the native format file in secondary storage, and retrieves it for display or to be provided to the user; see Kottomtharayil paragraph [0088], such a container file may allow both the preview and native format files to be moved from primary storage to secondary storage. The stub described herein may link or point to the preview file within the container file, and it is this preview file that is returned by accessing the stub. However, with further input by the user, the system can retrieve the native format file for the user).
Puga expressly discloses, responsive to receiving a command requesting the first base file, selecting, among the plurality of base files, a second base file which is a least recently accessed...(see Puga paragraph [0064], the following two rules, although other criteria or combinations of such, can be chosen within the scope of the invention: [0065] The least useful file in the local memory is considered the one which has not been requested for a longer time (that is, if a file stored in the local memory is read, then it becomes the "youngest" or "most useful" file). This is equivalent to checking the date of the last access and removing the file with the oldest date. [0066] The least useful file in the local memory is considered the one which has been requested fewer times in a given period);
removing the second base file from the memory (see Puga paragraph [0064], removing from the local memory 5 the least useful information according to said criterion when new information is to be stored and there is not enough free space. Different criteria can be used, for example, the following two rules, although other criteria or combinations of such, can be chosen within the scope of the invention); and
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Puga into the method of Kottomtharayil to have selecting, among the plurality of base files, a second base file which is a least recently accessed base file created on or before a specified date and removing the second base file from the local memory. Here, combining Puga with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing specific date of the last access of a file.
Chron expressly teaches selecting a second base file … created on or before a specified date (see Chron paragraph [0071], manages storage in a manner similar to a delete-optimized store, at least at a high level. As previously described, each object is evaluated according to its retention curve, its initial retention value, its creation time, and the current time; see Chron paragraph [0121], Objects may be deleted en masse in one of three ways. Deleting the container in which an object resides causes the object to be deleted. Short of deleting the container, objects may be deleted programmatically, i.e., under application control, by their creation date; see Chron paragraph [0122], objects older than an application-supplied time-stamp may be deleted en masse. Logically, the list of objects comprising the container is scanned from its tail forward for objects older than the time-stamp. If one is found, it is deleted and the next one is examined. The process will end when either an object is found with a time-stamp newer than that supplied by the application, or the end of the container is reached).
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Chron into the method of Kottomtharayil to have selecting, a file created on or before a specified date and removing the file. Here, combining Chron with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing a system and method for a mechanism that aggregates data in a way that permits data to be deleted efficiently (see Chron paragraph [0007].
Regarding claim 7 Kottomtharayil discloses, see Kottomtharayil paragraph [0097], for each file, the synchronization server decides whether to store the file in its native format on the user device or whether to store the file in a preview format on the user device and move the corresponding native format version to a secondary or archive location in the network.
Chron expressly discloses wherein the second base file comprises two or more files (see Chron paragraph [0122], objects older than an application-supplied time-stamp may be deleted en masse. Logically, the list of objects comprising the container is scanned from its tail forward for objects older than the time-stamp. If one is found, it is deleted and the next one is examined. The process will end when either an object is found with a time-stamp newer than that supplied by the application, or the end of the container is reached).
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Chron into the method of Kottomtharayil to have the second base file comprising two or more files. Here, combining Chron with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing a system and method for a mechanism that aggregates data in a way that permits data to be deleted efficiently, while minimizing the overhead necessary to support bulk deletion of data (see Chron paragraph [0007].
Regarding claim 9, Kottomtharayil discloses comprising receiving the plurality of base files via one of: a still image camera, a video camera, a microphone, or a network interface (see Kottomtharayil paragraph [0024], to convert large data files from their native format (e.g., an MPEG (Moving Pictures Expert Group) video file, or a PowerPoint file, etc.) to a preview format; see Kottomtharayil paragraph [0094], the converter 702 creates multiple resolution images of content pages of a native format file. When the user wishes to browse through such multi-resolution content, the system provides or offers a preview file suitable for the user's mobile device capabilities (e.g., high resolution, low resolution, 18 bit color depth, etc.), also called device resource profile).
Regarding claims 15 and 19 Kottomtharayil discloses wherein each base file is provided by one of: a still image file, a video file, an audio file, or a document file (see Kottomtharayil paragraph [0024], g., an MPEG (Moving Pictures Expert Group) video file, or a PowerPoint file, etc.)).
Regarding claim 21 Kottomtharayil discloses storing, in the memory, a respective preview file for each base file of at least a subset of the plurality of base files (see Kottomtharayil paragraph [0038], when an archive copy of a data object is made, a logical reference or stub may be used to replace the production copy of the data object in the production storage medium 218).
Regarding claim 22, Kottomtharayil discloses, wherein the first base file is a video file, and wherein a first preview file corresponding to the first base file comprises a subset of frames of the first base file (see Kottomtharayil paragraph [0080], the creation of a stub file (or a file in a preview format) from the original file (file in a native format). The system processes file 700 through a converter 702 that converts the file from its native format to a preview format (e.g., from PDF to JPEG or from PowerPoint to PNG, etc.) to generate preview content 706 representation of the file 700. In other words, the converter 702 converts the native file to another, lower resolution format file, where the lower resolution format file contains less data).
Regarding claim 23, Kottomtharayil discloses wherein the first base file is a text file, and wherein a first preview file corresponding to the first base file comprises a synopsis of the first base file (see Kottomtharayil paragraph [0069],The preview format may be customized to minimize storage requirement at the expense of added functionality such as being able to manipulate text and graphics in the file. In one aspect, a user is able to quickly view the content of a large file using the locally stored stub file and then make a decision about whether to recall the entire file from the secondary storage; which may take a significant amount of network and computing resources).
Regarding claim 28 Kottomtharayil discloses wherein selecting the one or more base files is performed among a subset of the base files having a file type of the first base file (see Kottomtharayil paragraph [0080], the creation of a stub file (or a file in a preview format) from the original file (file in a native format). The system processes file 700 through a converter 702 that converts the file from its native format to a preview format (e.g., from PDF to JPEG or from PowerPoint to PNG, etc.) to generate preview content 706 representation of the file 700. In other words, the converter 702 converts the native file to another, lower resolution format file, where the lower resolution format file contains less data).
Claims 24-26, 29, 30 and 32 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Kottomtharayil at el. (US 2013/0262386 A1) in view of Puga et al. (US 2011/0113205 A1) further in view of Chron et al. (US 20060288047 A1) further in view of Cabrera et al. (US 2005/0097126 A1).
Regarding claim 24, Kottomtharayil does not expressly allocating, in the memory, a quota for storing the plurality of base files; wherein selecting the one or more base files is performed responsive to failing, in view of the allocated quota, to store a new base file in the memory.
However, Cabrera expressly discloses allocating, in the memory, a quota for storing the plurality of base files; wherein selecting the one or more base files is performed responsive to failing, in view of the allocated quota, to store a new base file in the memory (see Cabrera paragraph [051], Once the quota of local allocation is exceeded, the HSM system of the present invention can migrate some of the file data to remote storage in order to reduce the amount of necessary on-disk memory allocation. The HSM system may select the range of bytes to migrate from the file, and the selection may adhere to a set of predetermined rules).
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Cabrera into the method of Kottomtharayil to have selecting the one or more base files is performed responsive to failing, in view of the allocated quota, to store a new base file in the memory. Here, combining Cabrera with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing pre-defined memory quota to manage memory allocation of files.
Regarding claims 25, 29 and 32 Cabrera expressly discloses wherein selecting the one or more base files is performed responsive to a failed attempt to store in the memory a new base file (see Cabrera paragraph [051], Once the quota of local allocation is exceeded, the HSM system of the present invention can migrate some of the file data to remote storage in order to reduce the amount of necessary on-disk memory allocation. The HSM system may select the range of bytes to migrate from the file, and the selection may adhere to a set of predetermined rules).
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Cabrera into the method of Kottomtharayil to have selecting the one or more base files is performed responsive to failing, in view of the allocated quota, to store a new base file in the memory. Here, combining Cabrera with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing pre-defined memory quota to manage memory allocation of files.
Regarding claims 26 and 30, Cabrera expressly discloses responsive to removing the one or mor base files from the memory, storing the new base file in the memory (see Cabrera paragraph [051], Once the quota of local allocation is exceeded, the HSM system of the present invention can migrate some of the file data to remote storage in order to reduce the amount of necessary on-disk memory allocation. The HSM system may select the range of bytes to migrate from the file, and the selection may adhere to a set of predetermined rules).
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Cabrera into the method of Kottomtharayil to have selecting the one or more base files is performed responsive to failing, in view of the allocated quota, to store a new base file in the memory. Here, combining Cabrera with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing pre-defined memory quota to manage memory allocation of files.
Claims 31 and 33 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Kottomtharayil at el. (US 2013/0262386 A1) in view of Puga et al. (US 2011/0113205 A1) further in view of Chron et al. (US 20060288047 A1) further in view of Chintala et al. (US 2006/0230170 A1).
Regarding claims 31 and 33 Kottomtharayil discloses store, in the memory, a data structure comprising a plurality of entries, each entry comprising at least one of; a file identifier of a base file of the plurality of base files…(see Kottomtharayil paragraph [0084], the preview format comprises a picture encoding format such as a JPEG image, or a bitmap format or a GIF (graphics intermediate format) image or a PNG (portable network graphics) image, and so on. At 818, if the file requested is the native format file, then the system accesses the data structure to identify the location of the native format file in secondary storage, and retrieves it for display or to be provided to the user; see Kottomtharayil paragraph [0088], such a container file may allow both the preview and native format files to be moved from primary storage to secondary storage. The stub described herein may link or point to the preview file within the container file, and it is this preview file that is returned by accessing the stub. However, with further input by the user, the system can retrieve the native format file for the user).
Chron expressly teaches …, a file creation stamp of the base file …(see Chron paragraph [0071], manages storage in a manner similar to a delete-optimized store, at least at a high level. As previously described, each object is evaluated according to its retention curve, its initial retention value, its creation time, and the current time; see Chron paragraph [0121], Objects may be deleted en masse in one of three ways. Deleting the container in which an object resides causes the object to be deleted. Short of deleting the container, objects may be deleted programmatically, i.e., under application control, by their creation date; see Chron paragraph [0122], objects older than an application-supplied time-stamp may be deleted en masse. Logically, the list of objects comprising the container is scanned from its tail forward for objects older than the time-stamp. If one is found, it is deleted and the next one is examined. The process will end when either an object is found with a time-stamp newer than that supplied by the application, or the end of the container is reached.).
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Chron into the method of Kottomtharayil to have selecting, a file created on or before a specified date and removing the file. Here, combining Chron with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing a system and method for a mechanism that aggregates data in a way that permits data to be deleted efficiently (see Chron paragraph [0007].
Chintala expressly teaches at least one of…, a file access timestamp of the base file, and a total number of files access operations performed with respect to the base file (see Chintala paragraph [0052], The files are sorted by the algorithm based on least Sample Timestamp, least hit count and least life start time stamp. In this way the oldest and least requested files are deleted from the cache).
It would have been obvious to a person of ordinary skill in art before the effective filing date of the claimed invention to incorporate the teaching of Chintala into the method of Kottomtharayil to have selecting, a file which is a least recently accessed base file created on or before a specified date and removing the file. Here, combining Chintala with Kottomtharayil, which are both related to performing smart archiving, improves Kottomtharayil by providing a streaming media delivery system that monitors the demand for streaming content and caches high-demand streaming content on one or more streaming servers (see Chintala paragraph [0009].
Remarks
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Johnson et al. (US 20100306283 A1) discloses, see Sahai paragraph [0159], a user of an endpoint device in communication with director device 14 requests to delete a particular file. Information object retrieval module 104 may receive the request and determine the file specified by the deletion request (180). Policy enforcement module 108 may then determine, for the specified file, whether a legal hold is set for the file (182) and whether the policy for the file permits the file to be deleted (184). For example, the policy may specify that a file may not be deleted until a period of time from the creation date or the last modification date as specified by the policy has passed.
Kosovan (US 20130110888 A1) discloses that a user may mark one or more controls 335 to remove folders of master media files and/or mark one or more controls 345 to remove folders of modified media files. In some implementations, a UI (not shown) may be provided for a user to request removing one or more groups or set of master and/or modified media files. For example, the user may enter a date range to request removing master or modified media files created within the date range.
Response to arguments
Applicant’s argument states that “…the cited references, taken individually or in combination, at least fail to reach or even suggest the claimed selecting, among the plurality of files, a second base file which is a least recently accessed base file created on or before a specified date. Examiner respectfully disagrees with the applicant’s argument because the combination of Kottomtharayil, Puga and Chron teaches all elements of the independent claims including limitations “selecting, among the plurality of files, a second base file which is a least recently accessed base file created on or before a specified date”.
Regarding selecting files for deletion applicant’s specification describes,
see applicant’s specification Paragraph [0017], the mobile computing device may select one or more previously acquired files for removal from the local file system, thus releasing the space necessary to store the newly acquired file.
see applicant’s specification Paragraph [0018], Responsive to removing one or more selected files, the mobile computing device may complete the attempted memory write operation (e.g., storing a newly acquired image file in the local file system).
see applicant’s specification Paragraph [0037], the mobile computing device 130 may select two or more files to be removed, having the total size not less than that of the newly acquired file.
Kottomtharayil discloses, see Kottomtharayil paragraph [0097], for each file, the synchronization server decides whether to store the file in its native format on the user device or whether to store the file in a preview format on the user device and move the corresponding native format version to a secondary or archive location in the network. Kottomtharayil further discloses, Kottomtharayil paragraph [0084], if the file requested is the native format file, then the system accesses the data structure to identify the location of the native format file in secondary storage, and retrieves it for display or to be provided to the user.
Puga discloses, see Puga paragraph [0064], to determine which information is more likely to be requested by the user, and thus, should be stored in the local memory 5, a criterion regarding requests for that information is used, removing from the local memory 5 the least useful information according to said criterion when new information is to be stored and there is not enough free space. Different criteria can be used…
see Puga paragraphs [0065]-[0066] the least useful file in the local memory is considered the one which has not been requested for a longer time (that is, if a file stored in the local memory is read, then it becomes the "youngest" or "most useful" file). This is equivalent to checking the date of the last access and removing the file with the oldest date.
[0066] The least useful file in the local memory is considered the one which has been requested fewer times in a given period.
The combination of Kottomtharayil of Puga discloses removing from the local memory 5 the least useful information according to said criterion when new information is to be stored and there is not enough free space based on checking the date of the last access and/or identifying file which has been requested fewer times in a given period.
Chron was relied upon to teach selecting a second base file … created on or before a specified date. Chron’s system, see Chron paragraph [0071], manages storage in a manner similar to a delete-optimized store. According to Chron, each object is evaluated according to its retention curve, its initial retention value, its creation time, and the current time. Chron further discloses, see Chron paragraph [0121], objects may be deleted en masse… objects may be deleted programmatically, i.e., under application control, by their creation date. see Chron paragraph [0122], objects older than an application-supplied time-stamp may be deleted en masse. Logically, the list of objects comprising the container is scanned from its tail forward for objects older than the time-stamp. If one is found, it is deleted and the next one is examined. The process will end when either an object is found with a time-stamp newer than that supplied by the application, or the end of the container is reached. The claim language dose not limit the possibility of two more files satisfying the criteria. Chron clearly teaches selecting one or more files created on or before a specified date, for deletion by disclosing “If one is found, it is deleted and the next one is examined”. Chron system works for Therefore, the combination of Kottomtharayil, Puga and Chron teaches all elements of the independent claims including limitations “selecting, among the plurality of files, a second base file which is a least recently accessed base file created on or before a specified date.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DINKU GEBRESENBET whose telephone number is 571-270-1636. The examiner can normally be reached between 8am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Amy Ng can be reached on 571- 270-1698. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the patent application information retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197(toll-free).
/DINKU W GEBRESENBET/Primary Examiner, Art Unit 2164