DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 03/03/2026.
Claims 42, 44-51, 53-60, and 62-64 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/03/2026 has been entered.
Claim Rejections - 35 USC § 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, 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 42, 44, 47-48, 51, 53, 56-57, 60, and 62 are rejected under 35 U.S.C. 103 as being unpatentable over Chung (US 9,195,503 B2) in view of Yueh (US 2012/0221817 A1) in view of Deng (US 2018/0373544 A1).
With regard to claim 42, Chung teaches:
A method for reusing a shared library, wherein a plurality of applications (APPs) are installed in an electronic device, and wherein each of the plurality of APPs comprises at least one shared library, the method comprising: “It should be noted that a typical computing system might include more than two (2) applications and a typical application might include more than two libraries, each of which might include more than one type definition but for the sake of simplicity only two applications, two libraries and one type definition are shown. Application_B 120 also includes library_1 124 and TD_1 126. In other words, both applications 118 and 120 include identical instantiations, or copies, of library_1 124 and TD_1 126” [Chung Col. 4 Lines 7-16, fig. 3].
determining, by the electronic device, whether a second shared library having file data the same as file data of a first shared library of a first APP exists in the electronic device; “During processing associated with a "Duplicate (Dup.) Hash?" block 214, a determination is made as to whether or not the hash code generated during processing associated with block 212 matches any hash code stored in hash library 160, indicating that the library to be loaded has already been loaded into VSR 152 (FIGS. 2 and3)” [Chung Col. 7 Lines 2-8].
and when the electronic device runs “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2].
the first APP to invoke the first shared library: searching for the first inode corresponding to the file name of the first shared library; “For example, if ACL 122 loads application_A 118, a hash value for library 124 is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160 … If ACL 122 subsequently receives a request to load library_1 124 (file name of the first library) within application_B (first APP) 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41].
and reading the file data of the second shared library “If ACL 122 subsequently receives a request 35 to load library_1 124 within application_B 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 (second shared library) stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41]. “… and otherwise, if the first resource is determined to be identical to the second resource, direct references to the first resource in the application to the particular resource stored in the VSR” [Chung Col. 1 Lines 50-53]. “During processing associated with a "Point App to Lib. In VSR" block 220, the application being loaded is provided a pointer or reference to the library stored in VSR 152” [Chung Col. 7 Lines 34-36].
wherein determining whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the electronic device comprises: “Provided are techniques for receiving a request to load a first resource corresponding to an application onto a computing system for execution; determining whether or not the first resource is identical to a resource loaded in a virtual scope library (VSR)…” [Chung Col. 1 Lines 43-47].
and determining, by the reusing component, whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the electronic device. “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (reusing component) (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2, fig. 1]. “Library detector 144 determines whether not an application being loaded by ACL 122 includes any libraries. If so, hash generator 146 generates and stores in hash library 160, as hash value, or code, for each library encountered during the loading of an application. In this manner, ACL 122 can detect 25 a library that is identical to a library that has previously been loaded by another application” [Chung Col. 5 Lines 21-27].
Chung fails to teach when the second shared library exists in the electronic device: storing a correspondence between a first index node (inode) and a file name of the first shared library; deleting the file data of the first shared library from the electronic device; and allocating the first inode to the second shared library, wherein the first inode indicates a first storage area used to store file data of the second shared library; searching for the first inode corresponding to the file name of the first shared library; and reading the file data of the second shared library stored in the first storage area indicated by the first inode.
However, Yueh teaches:
when the second shared (file) library exists in the electronic device: storing a correspondence between a first index node (inode) and a file name of the first shared (file) library; “If the hash value 406 of File A is already in the local hash table, this indicates that File A is already stored in the storage system 110 and a redundant instance of the file need not be stored on the storage system 110. Thus, the file's hash value is added 410 to a hash recipe or directory list and used to point to the single instance of File A already stored on the storage system 110 …The use of a hash recipe or directory list is used in one embodiment in storage systems that generate snapshots using copy-on-write and lack a WAFL or other inode-based file system. In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132. However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode (first index node) of File A (file name of the first shared file) to point to the single instance of File A, wherever it may be.” [Yueh ¶ 48, 50].
deleting the file data of the first shared library from the electronic device; “… determining that the at least one block of data is a duplicate of a block of data stored on one of the one or more additional storage systems … deleting the at least one block of data from the first storage system” [Yueh Claim 9].
and allocating the first inode to the second shared library, “storing, on the first storage system, a pointer or reference that points to the block of data stored on the one of the one or more additional storage systems, wherein a single instance of the at least one block of data is used for the original data and the snapshot in the first storage system” [Yueh Claim 9]. “However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be” [Yueh ¶ 50].
wherein the first inode indicates a first storage area used to store file data of the second shared library; “wherein storing a pointer or reference that points to the block of data stored on the one of the one or more additional storage systems comprises modifying one or more of the root inode, a snapshot inode, and a file inode to point to the block of data stored on the one of the one or more additional storage systems” [Yueh Claim 11].
searching for the first inode corresponding to the file name of the first shared library; “The de-duplication client 112 additionally modifies one or more inodes to point to the corresponding data. Consequently, read requests into the storage system 110 for any of the released out blocks 906, 912 can be redirected, as shown by the dotted lines 916, 918, and 920, to the corresponding data, wherever it is stored in the system 100” [Yueh ¶ 66, Fig 9A and 9B]. “However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be” [Yueh ¶ 50].
and reading the file data of the second shared library stored in the first storage area indicated by the first inode, “The de-duplication client 112 additionally modifies hash recipes or directory lists for the original data 802 and snapshot 804 to point to the corresponding data. Consequently, read requests into the storage system for any of the released out blocks 810, 812, 824 can be redirected to the corresponding data, wherever it is stored in the system 100, as illustrated by the lines 832, 834, and 836” [Yueh ¶ 62, Fig. 8B]. “Upon receiving a subsequent read request for a different virtual machine, the storage system can use hash recipes or inodes (already in memory) to identify data previously loaded into memory that is also used by the second virtual machine. Consequently, the storage system only needs to load data into memory that is not already there” [Yueh ¶ 70].
Yueh is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung to incorporate the teachings of Yueh and include when the second shared library exists in the electronic device: storing a correspondence between a first index node (inode) and a file name of the first shared library; deleting the file data of the first shared library from the electronic device; and allocating the first inode to the second shared library, wherein the first inode indicates a first storage area used to store file data of the second shared library; searching for the first inode corresponding to the file name of the first shared library; and reading the file data of the second shared library stored in the first storage area indicated by the first inode. Doing so would allow for increasing the available storage space. “In particular, the de-duplication client 112 identified blocks 810, 812, and 824 as being redundant data blocks and released these data blocks out of the storage system 110, which results in free space on the storage system 110” [Yueh ¶ 62].
Chung in view of Yueh fails to explicitly teach monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running.
However, Deng teaches:
monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running, “As shown in FIG. 5, the APP is installed on a device. The system (APP monitoring component) sends out the PACKAGE_REPLACED broadcast” [Deng ¶ 72]. “In one embodiment, after the target application is covered and installed, the system may broadcast a broadcast package PACKAGE_REPLACED used to notify that the target application is completely installed” [Deng ¶ 71].
Deng is considered to be analogous to the claimed invention because it is in the same field of program loading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh to incorporate the teachings of Deng and include monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running. Doing so would allow for the system to track when the installation of an application is complete such that further application processes like activation and loading can take place. “All dexes may be sequentially loaded when an application is activated for the first time after the application is installed” [Deng ¶ 3].
With regard to claim 44, Chung in view of Yueh in view of Deng teaches the method according to claim 42, as referenced above. Chung further teaches:
further comprising: when the second shared library does not exist in the electronic device: “If a determination is made, during processing associated with block 214, that the hash code generated during processing associated with block 212 does not match the hash of a previously loaded library, control proceeds to a "Load Lib. To VSR" block 216” [Chung Col. 7 Lines 13-17].
and when the electronic device runs “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2].
the first APP to invoke the first shared library: searching for the second inode corresponding to the file name of the first shared library; “For example, if ACL 122 loads application_A 118, a hash value for library 124 (first shared library) is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160 If the generated hash code is not found, the hash code is stored in hash library 160 and the corresponding library, which in this example is library_1 124, is loaded into virtual libraries 162 as a virtually stored library, or LIB_1 VS (see 192, FIG. 3)” [Chung Col. 5 Lines 28-35].
and reading the file data of the first shared library “If ACL 122 subsequently receives a request 35 to load library_1 124 within application_B 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41]. “During processing associated with a "Point App to Lib. In VSR" block 220, the application being loaded is provided a pointer or reference to the library stored in VSR 152” [Chung Col. 7 Lines 34-36].
Chung fails to teach allocating a second inode to the first shared library, wherein the second inode indicates a second storage area used to store the file data of the first shared library; storing a correspondence between the second inode and the file name of the first shared library; the second inode corresponding to the file name of the first shared library; and reading the file data of the first shared library stored in the storage area indicated by the second inode.
However, Yueh teaches:
allocating a second inode to the first shared library, wherein the second inode indicates a second storage area used to store the file data of the first shared (file) library; “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data (file data of the first shared file), whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56, Fig. 6].
storing a correspondence between the second inode and the file name of the first shared (file) library; “Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data, whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 56, Fig. 8A and 8B Examiner notes the inode modified/created to point to an entirely new piece of data is considered to have a correspondence with the file name of the first shared file in view of the implementation of the WAFL file system in method 400 which includes an inode corresponding to a filename]. “In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132. However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be.” [Yueh ¶ 50].
the second inode corresponding to the file name of the first shared library; “The root inode describes an inode file that contains the inodes that describe the rest of the files in the storage 114, 124 of the storage system 110, 120, including a block-map file and inode-map file. The inode files ultimately point to data blocks that make up the inode files” [Yueh ¶ 38]. “For instance the de-duplication client can perform a hash function on each of the blocks of data 906, 908, 910, 912, and 914. The de-duplication client can then compare the hash for each block to its local table of hash values to de-duplicate data locally and/or can query the de-duplication server to compare the hashes to the master hash table to de-duplicate data globally. The results of performing these steps and methods are depicted in FIG. 9B. In particular, the de-duplication client 112 identified blocks 906 and 912 as being redundant data blocks and released these data blocks out of the storage system 110, which results in free space on the storage system 110” [Yueh ¶ 65-66, Fig 9A and 9B Examiner notes the unchanged blocks 908, 910, and 914 in figure 9B for which no duplicate files were found in the deduplication process].
and reading the file data of the first shared (file) library stored in the storage area indicated by the second inode. “Upon receiving a subsequent read request for a different virtual machine, the storage system can use hash recipes or inodes (already in memory) to identify data previously loaded into memory that is also used by the second virtual machine. Consequently, the storage system only needs to load data into memory that is not already there” [Yueh ¶ 70]. “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data (file data of the first shared file), whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56, Fig. 6].
With regard to claim 47, Chung in view of Yueh in view of Deng teaches the method according to claim 44, as referenced above. Chung further teaches:
wherein determining whether the second shared library having same file data as the first shared library of the first APP exists in the electronic device comprises: generating a first identification of the first shared library based on the file data of the first shared library by using a preset algorithm; “Library detector 144 determines whether not an application being loaded by ACL 122 includes any libraries. If so, hash generator 146 generates and stores in hash library 160, as hash value (identification), or code, for each library encountered during the loading of an application. In this manner, ACL 122 can detect a library that is identical to a library that has previously been loaded by another application” [Chung Col. 5 Lines 21-27]. “During processing associated with block 212, a hash code is generated based upon the requesting library. The generated hash code is also stored in hash library 160 (FIG. 2)” [Chung Col. 6-7 Lines 66-67, 1-2].
determining whether the first identification is the same as a second identification, “For example, if ACL 122 loads application_A 118, a hash value for library 124 is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160. If the generated hash code is not found, the hash code is stored in hash library 160 and the corresponding library, which in this example is library 1124, is loaded into virtual libraries 162 as a virtually stored library, or LIB_1 VS (see 192, FIG. 3). If ACL 122 subsequently receives a request to load library_1 124 within application_B 120, a hash code for library_1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library 1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-41].
wherein the second identification is generated by the electronic device based on file data of a shared library in the electronic device by using the preset algorithm; “Hash library 160 stores hash values, or "codes," (see 144), each hash code corresponding to a particular virtual library stored in virtual libraries 162. In conjunction with each stored hash code, are indications of the particular applications associated with the libraries that correspond to the hash codes” [Chung Col. 5 Lines 3-7].
and when the first identification is the same as the second identification, determining that the second shared library having the same file data as the first shared library exists in the electronic device; “During processing associated with a "Duplicate (Dup.) Hash?" block 214, a determination is made as to whether or not the hash code generated during processing associated with block 212 matches any hash code stored in hash library 160, indicating that the library to be loaded has already been loaded into VSR 152 (FIGS. 2 and3)” [Chung Col. 7 Lines 2-8].
or when the first identification is different from the second identification, determining that the second shared library having the same file data as the first shared library does not exist in the electronic device. “If a determination is made, during processing associated with block 214, that the hash code generated during processing associated with block 212 does not match the hash of a previously loaded library, control proceeds to a "Load Lib. To VSR" block 216. During processing associated with block 216, the library for which a load request has been received is loaded into VSR 152” [Chung Col. 7 Lines 13-19].
With regard to claim 48, Chung in view of Yueh in view of Deng teaches the method according to claim 47, as referenced above. Chung further teaches further comprising when the first identification is different from the second identification, storing a correspondence between the first identification and (the first application) the second inode. “For example, if ACL 122 loads application_A 118, a hash value for library 124 is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160. If the generated hash code is not found, the hash code is stored in hash library 160 and the corresponding library, which in this example is library 1124, is loaded into virtual libraries 162 as a virtually stored library, or LIB_1 VS (see 192, FIG. 3)” [Chung Col. 5 Lines 28-35]. “Also stored in VSR 152 and associated with the stored library is the corresponding hash code generated during processing associated with block 212 (see 160, FIG. 2) and an indication of the particular application that initiated the request that the library be loaded. In this manner, a matching hash code can be associated with a particular library and one or more applications” [Chung Col. 7 Lines 19-25].
Chung fails to teach when the first identification is different from the second identification, storing a correspondence between the first identification and the second inode.
However, Yueh teaches when the first identification is different from the second identification, storing a correspondence between the first identification and the second inode. “The use of a hash recipe or directory list is used in one embodiment in storage systems that generate snapshots using copy-on-write and lack a WAFL or other inode-based file system. In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132” [Yueh ¶ 50]. “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes to point (correspondence) to the piece of data, whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56].
With regard to claim 51, Chung teaches:
An electronic device having a plurality of applications (APPs) installed, wherein each of the plurality of APPs comprises at least one shared library, “It should be noted that a typical computing system might include more than two (2) applications and a typical application might include more than two libraries, each of which might include more than one type definition but for the sake of simplicity only two applications, two libraries and one type definition are shown. Application_B 120 also includes library_1 124 and TD_1 126. In other words, both applications 118 and 120 include identical instantiations, or copies, of library_1 124 and TD_1 126” [Chung Col. 4 Lines 7-16, fig. 3].
the electronic device comprising: a memory storing a computer program and the at least one shared library; and at least one processor configured to execute the computer program, the computer program including instructions for: “These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/ acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.” [Chung Col. 3 Lines 21-37, Fig. 1 Examiner notes CRSM 112 and CPU 104].
determining whether a second shared library having file data the same as file data of a first shared library of a first APP exists in the memory; “During processing associated with a "Duplicate (Dup.) Hash?" block 214, a determination is made as to whether or not the hash code generated during processing associated with block 212 matches any hash code stored in hash library 160, indicating that the library to be loaded has already been loaded into VSR 152 (FIGS. 2 and3)” [Chung Col. 7 Lines 2-8].
and when running “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2].
the first APP to invoke the first shared library from the memory: searching for the first inode corresponding to the file name of the first shared library; “For example, if ACL 122 loads application_A 118, a hash value for library 124 is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160 … If ACL 122 subsequently receives a request to load library_1 124 (file name of the first library) within application_B (first APP) 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41].
and reading the file data of the second shared library “If ACL 122 subsequently receives a request 35 to load library_1 124 within application_B 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 (second shared library) stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41]. “… and otherwise, if the first resource is determined to be identical to the second resource, direct references to the first resource in the application to the particular resource stored in the VSR” [Chung Col. 1 Lines 50-53]. “During processing associated with a "Point App to Lib. In VSR" block 220, the application being loaded is provided a pointer or reference to the library stored in VSR 152” [Chung Col. 7 Lines 34-36].
wherein determining whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the memory comprises: “Provided are techniques for receiving a request to load a first resource corresponding to an application onto a computing system for execution; determining whether or not the first resource is identical to a resource loaded in a virtual scope library (VSR)…” [Chung Col. 1 Lines 43-47].
and determining, by the reusing component, whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the electronic device. “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (reusing component) (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2, fig. 1]. “Library detector 144 determines whether not an application being loaded by ACL 122 includes any libraries. If so, hash generator 146 generates and stores in hash library 160, as hash value, or code, for each library encountered during the loading of an application. In this manner, ACL 122 can detect 25 a library that is identical to a library that has previously been loaded by another application” [Chung Col. 5 Lines 21-27].
Chung fails to teach when the second shared library exists in the memory: storing a correspondence between a first index node (inode) and a file name of the first shared library; deleting the file data of the first shared library from the memory; wherein the first inode is allocated by the processor to the second shared library, and wherein the first inode indicates a first storage area that is in the memory and that is used to store file data of the second shared library; searching for the first inode corresponding to the file name of the first shared library; and reading the file data of the second shared library stored in the first storage area indicated by the first inode.
However, Yueh teaches:
when the second shared (file) library exists in the memory: storing a correspondence between a first index node (inode) and a file name of the first shared (file) library; “If the hash value 406 of File A is already in the local hash table, this indicates that File A is already stored in the storage system 110 and a redundant instance of the file need not be stored on the storage system 110. Thus, the file's hash value is added 410 to a hash recipe or directory list and used to point to the single instance of File A already stored on the storage system 110 …The use of a hash recipe or directory list is used in one embodiment in storage systems that generate snapshots using copy-on-write and lack a WAFL or other inode-based file system. In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132. However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode (first index node) of File A (file name of the first shared file) to point to the single instance of File A, wherever it may be.” [Yueh ¶ 48, 50].
deleting the file data of the first shared library from the memory; “… determining that the at least one block of data is a duplicate of a block of data stored on one of the one or more additional storage systems … deleting the at least one block of data from the first storage system” [Yueh Claim 9].
wherein the first inode is allocated by the processor to the second shared library, “storing, on the first storage system, a pointer or reference that points to the block of data stored on the one of the one or more additional storage systems, wherein a single instance of the at least one block of data is used for the original data and the snapshot in the first storage system” [Yueh Claim 9]. “However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be” [Yueh ¶ 50].
and wherein the first inode indicates a first storage area that is in the memory and that is used to store file data of the second shared library; “wherein storing a pointer or reference that points to the block of data stored on the one of the one or more additional storage systems comprises modifying one or more of the root inode, a snapshot inode, and a file inode to point to the block of data stored on the one of the one or more additional storage systems” [Yueh Claim 11].
searching for the first inode corresponding to the file name of the first shared library; “The de-duplication client 112 additionally modifies one or more inodes to point to the corresponding data. Consequently, read requests into the storage system 110 for any of the released out blocks 906, 912 can be redirected, as shown by the dotted lines 916, 918, and 920, to the corresponding data, wherever it is stored in the system 100” [Yueh ¶ 66, Fig 9A and 9B]. “However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be” [Yueh ¶ 50].
and reading the file data of the second shared library stored in the first storage area indicated by the first inode, “The de-duplication client 112 additionally modifies hash recipes or directory lists for the original data 802 and snapshot 804 to point to the corresponding data. Consequently, read requests into the storage system for any of the released out blocks 810, 812, 824 can be redirected to the corresponding data, wherever it is stored in the system 100, as illustrated by the lines 832, 834, and 836” [Yueh ¶ 62, Fig. 8B]. “Upon receiving a subsequent read request for a different virtual machine, the storage system can use hash recipes or inodes (already in memory) to identify data previously loaded into memory that is also used by the second virtual machine. Consequently, the storage system only needs to load data into memory that is not already there” [Yueh ¶ 70].
Yueh is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung to incorporate the teachings of Yueh and include when the second shared library exists in memory: storing a correspondence between a first index node (inode) and a file name of the first shared library; deleting the file data of the first shared library from the memory; wherein the first inode is allocated by the processor to the second shared library, and wherein the first inode indicates a first storage area that is in the memory and that is used to store file data of the second shared library; searching for the first inode corresponding to the file name of the first shared library; and reading the file data of the second shared library stored in the first storage area indicated by the first inode. Doing so would allow for increasing the available storage space. “In particular, the de-duplication client 112 identified blocks 810, 812, and 824 as being redundant data blocks and released these data blocks out of the storage system 110, which results in free space on the storage system 110” [Yueh ¶ 62].
Chung in view of Yueh fails to explicitly teach monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running.
However, Deng teaches:
monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running, “As shown in FIG. 5, the APP is installed on a device. The system (APP monitoring component) sends out the PACKAGE_REPLACED broadcast” [Deng ¶ 72]. “In one embodiment, after the target application is covered and installed, the system may broadcast a broadcast package PACKAGE_REPLACED used to notify that the target application is completely installed” [Deng ¶ 71].
Deng is considered to be analogous to the claimed invention because it is in the same field of program loading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh to incorporate the teachings of Deng and include monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running. Doing so would allow for the system to track when the installation of an application is complete such that further application processes like activation and loading can take place. “All dexes may be sequentially loaded when an application is activated for the first time after the application is installed.” [Deng ¶ 3].
With regard to claim 53, Chung in view of Yueh in view of Deng teaches the method according to claim 51, as referenced above. Chung further teaches:
further comprising instructions for: when the second shared library does not exist in the memory: “If a determination is made, during processing associated with block 214, that the hash code generated during processing associated with block 212 does not match the hash of a previously loaded library, control proceeds to a "Load Lib. To VSR" block 216” [Chung Col. 7 Lines 13-17].
and when running “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2].
the first APP to invoke the first shared library: searching for the second inode corresponding to the file name of the first shared library; “For example, if ACL 122 loads application_A 118, a hash value for library 124 (first shared library) is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160 If the generated hash code is not found, the hash code is stored in hash library 160 and the corresponding library, which in this example is library_1 124, is loaded into virtual libraries 162 as a virtually stored library, or LIB_1 VS (see 192, FIG. 3)” [Chung Col. 5 Lines 28-35].
and reading the file data of the first shared library “If ACL 122 subsequently receives a request 35 to load library_1 124 within application_B 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41]. “During processing associated with a "Point App to Lib. In VSR" block 220, the application being loaded is provided a pointer or reference to the library stored in VSR 152” [Chung Col. 7 Lines 34-36].
Chung fails to teach allocating a second inode to the first shared library, wherein the second inode indicates a second storage area used to store the file data of the first shared library; storing a correspondence between the second inode and the file name of the first shared library; the second inode corresponding to the file name of the first shared library; and reading the file data of the first shared library stored in the storage area indicated by the second inode.
However, Yueh teaches:
allocating a second inode to the first shared library, wherein the second inode indicates a second storage area used to store the file data of the first shared (file) library; “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data (file data of the first shared file), whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56, Fig. 6].
storing a correspondence between the second inode and the file name of the first shared (file) library; “Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data, whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 56, Fig. 8A and 8B Examiner notes the inode modified/created to point to an entirely new piece of data is considered to have a correspondence with the file name of the first shared file in view of the implementation of the WAFL file system in method 400 which includes an inode corresponding to a filename]. “In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132. However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be.” [Yueh ¶ 50].
the second inode corresponding to the file name of the first shared (file) library; “The root inode describes an inode file that contains the inodes that describe the rest of the files in the storage 114, 124 of the storage system 110, 120, including a block-map file and inode-map file. The inode files ultimately point to data blocks that make up the inode files” [Yueh ¶ 38]. “For instance the de-duplication client can perform a hash function on each of the blocks of data 906, 908, 910, 912, and 914. The de-duplication client can then compare the hash for each block to its local table of hash values to de-duplicate data locally and/or can query the de-duplication server to compare the hashes to the master hash table to de-duplicate data globally. The results of performing these steps and methods are depicted in FIG. 9B. In particular, the de-duplication client 112 identified blocks 906 and 912 as being redundant data blocks and released these data blocks out of the storage system 110, which results in free space on the storage system 110” [Yueh ¶ 65-66, Fig 9A and 9B Examiner notes the unchanged blocks 908, 910, and 914 in figure 9B for which no duplicate files were found in the deduplication process].
and reading the file data of the first shared (file) library stored in the storage area indicated by the second inode. “Upon receiving a subsequent read request for a different virtual machine, the storage system can use hash recipes or inodes (already in memory) to identify data previously loaded into memory that is also used by the second virtual machine. Consequently, the storage system only needs to load data into memory that is not already there” [Yueh ¶ 70]. “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data (file data of the first shared file), whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56, Fig. 6].
With regard to claim 56, Chung in view of Yueh in view of Deng teaches the method according to claim 53, as referenced above. Chung further teaches:
further comprising instructions: generating a first identification of the first shared library based on the file data of the first shared library by using a preset algorithm; “Library detector 144 determines whether not an application being loaded by ACL 122 includes any libraries. If so, hash generator 146 generates and stores in hash library 160, as hash value (identification), or code, for each library encountered during the loading of an application. In this manner, ACL 122 can detect a library that is identical to a library that has previously been loaded by another application” [Chung Col. 5 Lines 21-27]. “During processing associated with block 212, a hash code is generated based upon the requesting library. The generated hash code is also stored in hash library 160 (FIG. 2)” [Chung Col. 6-7 Lines 66-67, 1-2].
determining whether the first identification is the same as a second identification, “For example, if ACL 122 loads application_A 118, a hash value for library 124 is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160. If the generated hash code is not found, the hash code is stored in hash library 160 and the corresponding library, which in this example is library 1124, is loaded into virtual libraries 162 as a virtually stored library, or LIB_1 VS (see 192, FIG. 3). If ACL 122 subsequently receives a request to load library_1 124 within application_B 120, a hash code for library_1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library 1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-41].
wherein the second identification is generated by the processor based on file data of any shared library in the memory by using the preset algorithm; “Hash library 160 stores hash values, or "codes," (see 144), each hash code corresponding to a particular virtual library stored in virtual libraries 162. In conjunction with each stored hash code, are indications of the particular applications associated with the libraries that correspond to the hash codes” [Chung Col. 5 Lines 3-7].
and when the first identification is the same as the second identification, determining that the second shared library having the same file data as the first shared library exists in the memory; “During processing associated with a "Duplicate (Dup.) Hash?" block 214, a determination is made as to whether or not the hash code generated during processing associated with block 212 matches any hash code stored in hash library 160, indicating that the library to be loaded has already been loaded into VSR 152 (FIGS. 2 and3)” [Chung Col. 7 Lines 2-8].
or when the first identification is different from the second identification, determining that the second shared library having the same file data as the first shared library does not exist in the memory. “If a determination is made, during processing associated with block 214, that the hash code generated during processing associated with block 212 does not match the hash of a previously loaded library, control proceeds to a "Load Lib. To VSR" block 216. During processing associated with block 216, the library for which a load request has been received is loaded into VSR 152” [Chung Col. 7 Lines 13-19].
With regard to claim 57, Chung in view of Yueh in view of Deng teaches the method according to claim 56, as referenced above. Chung further teaches further comprising instructions for storing a correspondence between the first identification and (the first application) the second inode when the first identification is different from the second identification. “For example, if ACL 122 loads application_A 118, a hash value for library 124 is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160. If the generated hash code is not found, the hash code is stored in hash library 160 and the corresponding library, which in this example is library 1124, is loaded into virtual libraries 162 as a virtually stored library, or LIB_1 VS (see 192, FIG. 3)” [Chung Col. 5 Lines 28-35]. “Also stored in VSR 152 and associated with the stored library is the corresponding hash code generated during processing associated with block 212 (see 160, FIG. 2) and an indication of the particular application that initiated the request that the library be loaded. In this manner, a matching hash code can be associated with a particular library and one or more applications” [Chung Col. 7 Lines 19-25].
Chung fails to teach storing a correspondence between the first identification and the second inode when the first identification is different from the second identification.
However, Yueh teaches storing a correspondence between the first identification and the second inode when the first identification is different from the second identification. “The use of a hash recipe or directory list is used in one embodiment in storage systems that generate snapshots using copy-on-write and lack a WAFL or other inode-based file system. In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132” [Yueh ¶ 50]. “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes to point (correspondence) to the piece of data, whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56].
With regard to claim 60, Chung teaches:
A chip system comprising: an electronic device having a plurality of APPs installed in the electronic device, wherein each of the plurality of APPs comprises at least one shared library; “It should be noted that a typical computing system might include more than two (2) applications and a typical application might include more than two libraries, each of which might include more than one type definition but for the sake of simplicity only two applications, two libraries and one type definition are shown. Application_B 120 also includes library_1 124 and TD_1 126. In other words, both applications 118 and 120 include identical instantiations, or copies, of library_1 124 and TD_1 126” [Chung Col. 4 Lines 7-16, fig. 3].
one or more interface circuits; and one or more processors, wherein the one or more interface circuits and the one or more processors are interconnected with each other; “Also included in computing system 102 and attached to CPU 104 is a computer-readable storage medium (CRSM) 112, which may either be incorporated into computing system 102 i.e. an internal device, or attached externally to CPU 104 by means of various, commonly available connection devices such as but not limited to, a universal serial bus (USB) port (not shown) or wirelessly” [Chung Col. 3 Lines 53-60].
wherein the one or more interface circuits are configured to: receive a signal from a memory of the electronic device; and send the signal to the one or more processors, wherein the signal comprises instructions stored in the memory, and wherein the signal comprises instructions for: “These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/ acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.” [Chung Col. 3 Lines 21-37, Fig. 1 Examiner notes CRSM 112 and CPU 104].
determining whether a second shared library having file data the same as file data of a first shared library of a first APP exists in the memory; “During processing associated with a "Duplicate (Dup.) Hash?" block 214, a determination is made as to whether or not the hash code generated during processing associated with block 212 matches any hash code stored in hash library 160, indicating that the library to be loaded has already been loaded into VSR 152 (FIGS. 2 and3)” [Chung Col. 7 Lines 2-8].
and when running “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2].
the first APP to invoke the first shared library from the memory: searching for the first inode corresponding to the file name of the first shared library; “For example, if ACL 122 loads application_A 118, a hash value for library 124 is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160 … If ACL 122 subsequently receives a request to load library_1 124 (file name of the first library) within application_B (first APP) 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41].
and reading the file data of the second shared library “If ACL 122 subsequently receives a request 35 to load library_1 124 within application_B 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 (second shared library) stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41]. “… and otherwise, if the first resource is determined to be identical to the second resource, direct references to the first resource in the application to the particular resource stored in the VSR” [Chung Col. 1 Lines 50-53]. “During processing associated with a "Point App to Lib. In VSR" block 220, the application being loaded is provided a pointer or reference to the library stored in VSR 152” [Chung Col. 7 Lines 34-36].
wherein determining whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the memory comprises: “Provided are techniques for receiving a request to load a first resource corresponding to an application onto a computing system for execution; determining whether or not the first resource is identical to a resource loaded in a virtual scope library (VSR)…” [Chung Col. 1 Lines 43-47].
and determining, by the reusing component, whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the electronic device. “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (reusing component) (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2, fig. 1]. “Library detector 144 determines whether not an application being loaded by ACL 122 includes any libraries. If so, hash generator 146 generates and stores in hash library 160, as hash value, or code, for each library encountered during the loading of an application. In this manner, ACL 122 can detect 25 a library that is identical to a library that has previously been loaded by another application” [Chung Col. 5 Lines 21-27].
Chung fails to teach when the second shared library exists in the memory: storing a correspondence between a first index node (inode) and a file name of the first shared library; deleting the file data of the first shared library from the memory; wherein the first inode is allocated by the one or more processors to the second shared library, and wherein the first inode indicates a first storage area that is in the memory and that is used to store file data of the second shared library; searching for the first inode corresponding to the file name of the first shared library; and reading the file data of the second shared library stored in the first storage area indicated by the first inode.
However, Yueh teaches:
when the second shared (file) library exists in the memory: storing a correspondence between a first index node (inode) and a file name of the first shared (file) library; “If the hash value 406 of File A is already in the local hash table, this indicates that File A is already stored in the storage system 110 and a redundant instance of the file need not be stored on the storage system 110. Thus, the file's hash value is added 410 to a hash recipe or directory list and used to point to the single instance of File A already stored on the storage system 110 …The use of a hash recipe or directory list is used in one embodiment in storage systems that generate snapshots using copy-on-write and lack a WAFL or other inode-based file system. In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132. However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode (first index node) of File A (file name of the first shared file) to point to the single instance of File A, wherever it may be.” [Yueh ¶ 48, 50].
deleting the file data of the first shared library from the memory; “… determining that the at least one block of data is a duplicate of a block of data stored on one of the one or more additional storage systems … deleting the at least one block of data from the first storage system” [Yueh Claim 9].
wherein the first inode is allocated by the one or more processors to the second shared library, “storing, on the first storage system, a pointer or reference that points to the block of data stored on the one of the one or more additional storage systems, wherein a single instance of the at least one block of data is used for the original data and the snapshot in the first storage system” [Yueh Claim 9]. “However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be” [Yueh ¶ 50].
and wherein the first inode indicates a first storage area that is in the memory and that is used to store file data of the second shared library; “wherein storing a pointer or reference that points to the block of data stored on the one of the one or more additional storage systems comprises modifying one or more of the root inode, a snapshot inode, and a file inode to point to the block of data stored on the one of the one or more additional storage systems” [Yueh Claim 11].
searching for the first inode corresponding to the file name of the first shared library; “The de-duplication client 112 additionally modifies one or more inodes to point to the corresponding data. Consequently, read requests into the storage system 110 for any of the released out blocks 906, 912 can be redirected, as shown by the dotted lines 916, 918, and 920, to the corresponding data, wherever it is stored in the system 100” [Yueh ¶ 66, Fig 9A and 9B]. “However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be” [Yueh ¶ 50].
and reading the file data of the second shared library stored in the first storage area indicated by the first inode, “The de-duplication client 112 additionally modifies hash recipes or directory lists for the original data 802 and snapshot 804 to point to the corresponding data. Consequently, read requests into the storage system for any of the released out blocks 810, 812, 824 can be redirected to the corresponding data, wherever it is stored in the system 100, as illustrated by the lines 832, 834, and 836” [Yueh ¶ 62, Fig. 8B]. “Upon receiving a subsequent read request for a different virtual machine, the storage system can use hash recipes or inodes (already in memory) to identify data previously loaded into memory that is also used by the second virtual machine. Consequently, the storage system only needs to load data into memory that is not already there” [Yueh ¶ 70].
Yueh is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung to incorporate the teachings of Yueh and include when the second shared library exists in memory: storing a correspondence between a first index node (inode) and a file name of the first shared library; deleting the file data of the first shared library from the memory; wherein the first inode is allocated by the one or more processors to the second shared library, and wherein the first inode indicates a first storage area that is in the memory and that is used to store file data of the second shared library; searching for the first inode corresponding to the file name of the first shared library; and reading the file data of the second shared library stored in the first storage area indicated by the first inode. Doing so would allow for increasing the available storage space. “In particular, the de-duplication client 112 identified blocks 810, 812, and 824 as being redundant data blocks and released these data blocks out of the storage system 110, which results in free space on the storage system 110” [Yueh ¶ 62].
Chung in view of Yueh fails to explicitly teach monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running.
However, Deng teaches:
monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running, “As shown in FIG. 5, the APP is installed on a device. The system (APP monitoring component) sends out the PACKAGE_REPLACED broadcast” [Deng ¶ 72]. “In one embodiment, after the target application is covered and installed, the system may broadcast a broadcast package PACKAGE_REPLACED used to notify that the target application is completely installed” [Deng ¶ 71].
Deng is considered to be analogous to the claimed invention because it is in the same field of program loading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh to incorporate the teachings of Deng and include monitoring, by an APP monitoring component, the APP for either completion of installation or completion of running, sending, by the APP monitoring component, a notification message to a reusing component following completion of installation or completion of running. Doing so would allow for the system to track when the installation of an application is complete such that further application processes like activation and loading can take place. “All dexes may be sequentially loaded when an application is activated for the first time after the application is installed.” [Deng ¶ 3].
With regard to claim 62, Chung in view of Yueh in view of Deng teaches the chip system according to claim 60, as referenced above. Chung further teaches:
wherein the signal further comprises instructions for: when the second shared library does not exist in the memory: “If a determination is made, during processing associated with block 214, that the hash code generated during processing associated with block 212 does not match the hash of a previously loaded library, control proceeds to a "Load Lib. To VSR" block 216” [Chung Col. 7 Lines 13-17].
and when running “CRSM 112 is illustrated storing logic associated with an operating system (OS) 114, a runtime execution server (RES) 116 and two (2) computer software applications, i.e., an application_A 118 and an application_B 120. RES 116 incorporates an augmented class loader (ACL) 122, which in this example implements functionality associated with the claimed subject matter in addition to functionality associated with a typical class loader. The functionality of ACL 122 is described in more detail below in conjunction with FIGS. 2-5” [Chung Col. 3-4 Lines 61-67, 1-2].
the first APP to invoke the first shared library: searching for the second inode corresponding to the file name of the first shared library; “For example, if ACL 122 loads application_A 118, a hash value for library 124 (first shared library) is generated. Comparison module 148 compares the generated hash code to those stored in bash library 160 If the generated hash code is not found, the hash code is stored in hash library 160 and the corresponding library, which in this example is library_1 124, is loaded into virtual libraries 162 as a virtually stored library, or LIB_1 VS (see 192, FIG. 3)” [Chung Col. 5 Lines 28-35].
and reading the file data of the first shared library “If ACL 122 subsequently receives a request 35 to load library_1 124 within application_B 120, a hash code for library 1 124 is generated and compared to the values stored in hash library 160. This time, comparison module 148 detects a match and rather than loading library_1 124 a second time, application_B 120 is provided a reference to LIB_1 VS 192 stored in virtual libraries 162” [Chung Col. 5 Lines 28-31, 38-41]. “During processing associated with a "Point App to Lib. In VSR" block 220, the application being loaded is provided a pointer or reference to the library stored in VSR 152” [Chung Col. 7 Lines 34-36].
Chung fails to teach allocating a second inode to the first shared library, wherein the second inode indicates a second storage area used to store the file data of the first shared library; storing a correspondence between the second inode and the file name of the first shared library; the second inode corresponding to the file name of the first shared library; and reading the file data of the first shared library stored in the storage area indicated by the second inode.
However, Yueh teaches:
allocating a second inode to the first shared library, wherein the second inode indicates a second storage area used to store the file data of the first shared (file) library; “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data (file data of the first shared file), whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56, Fig. 6].
storing a correspondence between the second inode and the file name of the first shared (file) library; “Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data, whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 56, Fig. 8A and 8B Examiner notes the inode modified/created to point to an entirely new piece of data is considered to have a correspondence with the file name of the first shared file in view of the implementation of the WAFL file system in method 400 which includes an inode corresponding to a filename]. “In a WAFL file system, however, the use of hash recipes and directory lists may be unnecessary and the process 400 can be modified accordingly. Much of the process 400 would be the same, including hashing 404 a file and comparing it 408, 416 to existing hashes in the local hash table 412 and/or master hash table 132. However, when it is determined that a file is already stored in the system 100 on the same or a different storage system, step 410 may comprise modifying the inode of File A to point to the single instance of File A, wherever it may be.” [Yueh ¶ 50].
the second inode corresponding to the file name of the first shared (file) library; “The root inode describes an inode file that contains the inodes that describe the rest of the files in the storage 114, 124 of the storage system 110, 120, including a block-map file and inode-map file. The inode files ultimately point to data blocks that make up the inode files” [Yueh ¶ 38]. “For instance the de-duplication client can perform a hash function on each of the blocks of data 906, 908, 910, 912, and 914. The de-duplication client can then compare the hash for each block to its local table of hash values to de-duplicate data locally and/or can query the de-duplication server to compare the hashes to the master hash table to de-duplicate data globally. The results of performing these steps and methods are depicted in FIG. 9B. In particular, the de-duplication client 112 identified blocks 906 and 912 as being redundant data blocks and released these data blocks out of the storage system 110, which results in free space on the storage system 110” [Yueh ¶ 65-66, Fig 9A and 9B Examiner notes the unchanged blocks 908, 910, and 914 in figure 9B for which no duplicate files were found in the deduplication process].
and reading the file data of the first shared (file) library stored in the storage area indicated by the second inode. “Upon receiving a subsequent read request for a different virtual machine, the storage system can use hash recipes or inodes (already in memory) to identify data previously loaded into memory that is also used by the second virtual machine. Consequently, the storage system only needs to load data into memory that is not already there” [Yueh ¶ 70]. “If the hash value of the piece of data is not in the master hash table or the local hash table, the de-duplication client is informed by the de-duplication server that the piece of data is new and the de-duplication client 112 permits the piece of data to be stored 608 on the storage system 110. The de-duplication client 112 may additionally add 610 the hash value of the new piece of data to a hash recipe. Just as with the method 400 of FIG. 4, the method 600 can be adapted if the storage system 110 implements a WAFL file system. In this case, step 610 may instead comprise modifying/creating inodes (second inode) to point to the piece of data (file data of the first shared file), whether the piece of data was previously stored on the storage system 110, previously stored on a different storage system in the system 100, or is an entirely new piece of data” [Yueh ¶ 55-56, Fig. 6].
Claims 45, 50, 54, 58-59, and 63 are rejected under 35 U.S.C. 103 as being unpatentable over Chung (US 9,195,503 B2) in view of Yueh (US 2012/0221817 A1) in view of Deng (US 2018/0373544 A1) in view of Saika (US 2013/0333042 A1).
With regard to claim 45, Chung in view of Yueh in view of Deng teaches the method according to claim 44, as referenced above. Chung further teaches:
further comprising: when the second shared library exists in the electronic device adding 1 to a quantity of links of the first (library) inode, “During processing associated with an "Increment Lib Reference (Ref.) Count" block 218, the count (see 158, FIG. 2) of applications referencing a particular library in VSR 152 is incremented. If block 218 has been reached from block 216, i.e., the library pointed to has already been stored in conjunction with another application; if reached directly via block 214, the library has typically been loaded into VSR 152 by a previous application.” [Chung Col. 7 Lines 26-33, Fig. 4 Examiner notes “increment lib ref count” block 218 is reached from block 214 when a duplicate hash value is found, meaning that a second shared library having the same file data exists].
wherein the quantity of links of the first (library) inode is a quantity of shared libraries corresponding to the first (library) inode; “VSR 152 includes library reference counts 158, a hash library 160 and virtual libraries 162. Library reference counts 158 stores information on particular virtual libraries in virtual libraries 162 (see 192, 194, FIG. 3), specifically the number of applications current sharing a particular virtual library” [Chung Col. 4 Lines 58-63].
or when the second shared library does not exist in the electronic device, adding 1 to a quantity of links of the second (library) inode, “During processing associated with an "Increment Lib Reference (Ref.) Count" block 218, the count (see 158, FIG. 2) of applications referencing a particular library in VSR 152 is incremented. If block 218 has been reached from block 216, i.e., the library pointed to has already been stored in conjunction with another application; if reached directly via block 214, the library has typically been loaded into VSR 152 by a previous application.” [Chung Col. 7 Lines 26-33, Fig. 4 Examiner notes “increment lib ref count” block 218 is reached from block 214 when a duplicate hash value is not found meaning that a second shared library having the same file data does not exist].
wherein the quantity of links of the second (library) inode is a quantity of shared libraries corresponding to the second (library) inode, “VSR 152 includes library reference counts 158, a hash library 160 and virtual libraries 162. Library reference counts 158 stores information on particular virtual libraries in virtual libraries 162 (see 192, 194, FIG. 3), specifically the number of applications current sharing a particular virtual library” [Chung Col. 4 Lines 58-63].
Chung fails to teach inode.
However, Yueh teaches inode “The root inode describes an inode file that contains the inodes that describe the rest of the files in the storage 114, 124 of the storage system 110, 120, including a block-map file and inode-map file. The inode files ultimately point to data blocks that make up the inode files” [Yueh ¶ 38].
Chung in view of Yueh in view of Deng fails to explicitly teach and wherein an initial value of the quantity of links of each inode is O (zero).
However, Saika teaches and wherein an initial value of the quantity of links of each inode is O (zero). “In a case where a clone-source file matching the clone-target file does not exist (S112: NO), the file storage 10 adds a clone-source file comprising the same data as the data of the clone-target file to the index directory (S113). Then, the file storage 10 configures the reference count C106C of the added clone-source file to 0 (S114). The file storage 10, either in a case where a clone-source file matching the clone-target file exists (S112: YES), or subsequent to the end of Step S114, configures the inode number of the clone-source file in the reference-destination inode number C106A of the clone-target file inode information T10 (S115)” [Saika ¶ 212-213].
Saika is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Chung includes library reference counts to keep track of how many applications share a library. This can be combined with the reference count of Saika which is associated with an inode of a source file. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng to incorporate the teachings of Saika and include that an initial value of the quantity of links of each inode is O (zero). Doing so would allow for the reference count to directly correspond to the number of libraries referencing the data of a source library. “The reference count C106C is information for managing the life of a clone-source file. The value of the reference count C106C is incremented by 1 each time a clone file, which references the clone-source file, is created. Therefore, for example, "5" is configured in the reference count C106C for a clone-source file, which is referenced by five clone files” [Saika ¶ 118].
With regard to claim 50, Chung in view of Yueh in view of Deng teaches the method according to claim 42, as referenced above. Chung further teaches and determining whether the second shared library having the same file data as the first shared library exists in the electronic device. “During processing associated with a "Duplicate (Dup.) Hash?" block 214, a determination is made as to whether or not the hash code generated during processing associated with block 212 matches any hash code stored in hash library 160, indicating that the library to be loaded has already been loaded into VSR 152 (FIGS. 2 and3)” [Chung Col. 7 Lines 2-8].
Chung in view of Yueh in view of Deng fails to explicitly teach comparing the file data of the first shared library with file data of each shared library in the electronic device.
However, Saika teaches:
wherein determining whether the second shared library having same file data as the first shared library of the first APP exists in the electronic device comprises: comparing the file data of the first shared library with file data of each shared library in the electronic device; “The file storage 10 compares all the clone-source files stored inside this subdirectory to the clone-target file (S111). The file storage 10 determines whether there is a clone-source file, which matches the data of the clone-target file (S112)” [Saika ¶211]. “The file storage 10 determines whether there is a clone-source file, which matches the data of the clone-target file (S112)” [Saika ¶211].
With regard to claim 54, Chung in view of Yueh in view of Deng teaches the method according to claim 53, as referenced above. Chung further teaches:
further comprising instructions: when the second shared library exists in the memory, adding 1 to a quantity of links of the first (library) inode, “During processing associated with an "Increment Lib Reference (Ref.) Count" block 218, the count (see 158, FIG. 2) of applications referencing a particular library in VSR 152 is incremented. If block 218 has been reached from block 216, i.e., the library pointed to has already been stored in conjunction with another application; if reached directly via block 214, the library has typically been loaded into VSR 152 by a previous application.” [Chung Col. 7 Lines 26-33, Fig. 4 Examiner notes “increment lib ref count” block 218 is reached from block 214 when a duplicate hash value is found, meaning that a second shared library having the same file data exists].
wherein the quantity of links of the first (library) inode is a quantity of shared libraries corresponding to the first (library) inode; “VSR 152 includes library reference counts 158, a hash library 160 and virtual libraries 162. Library reference counts 158 stores information on particular virtual libraries in virtual libraries 162 (see 192, 194, FIG. 3), specifically the number of applications current sharing a particular virtual library” [Chung Col. 4 Lines 58-63].
or when the second shared library does not exist in the memory, adding 1 to a quantity of links of the second (library) inode, “During processing associated with an "Increment Lib Reference (Ref.) Count" block 218, the count (see 158, FIG. 2) of applications referencing a particular library in VSR 152 is incremented. If block 218 has been reached from block 216, i.e., the library pointed to has already been stored in conjunction with another application; if reached directly via block 214, the library has typically been loaded into VSR 152 by a previous application.” [Chung Col. 7 Lines 26-33, Fig. 4 Examiner notes “increment lib ref count” block 218 is reached from block 214 when a duplicate hash value is not found meaning that a second shared library having the same file data does not exist].
wherein the quantity of links of the second (library) inode is a quantity of shared libraries corresponding to the second (library) inode, “VSR 152 includes library reference counts 158, a hash library 160 and virtual libraries 162. Library reference counts 158 stores information on particular virtual libraries in virtual libraries 162 (see 192, 194, FIG. 3), specifically the number of applications current sharing a particular virtual library” [Chung Col. 4 Lines 58-63].
Chung fails to teach inode.
However, Yueh teaches inode “The root inode describes an inode file that contains the inodes that describe the rest of the files in the storage 114, 124 of the storage system 110, 120, including a block-map file and inode-map file. The inode files ultimately point to data blocks that make up the inode files” [Yueh ¶ 38].
Chung in view of Yueh in view of Deng fails to explicitly teach and wherein an initial value of the quantity of links of each inode is O (zero).
However, Saika teaches and wherein an initial value of the quantity of links of each inode is O (zero). “In a case where a clone-source file matching the clone-target file does not exist (S112: NO), the file storage 10 adds a clone-source file comprising the same data as the data of the clone-target file to the index directory (S113). Then, the file storage 10 configures the reference count C106C of the added clone-source file to 0 (S114). The file storage 10, either in a case where a clone-source file matching the clone-target file exists (S112: YES), or subsequent to the end of Step S114, configures the inode number of the clone-source file in the reference-destination inode number C106A of the clone-target file inode information T10 (S115)” [Saika ¶ 212-213].
Saika is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Chung includes library reference counts to keep track of how many applications share a library. This can be combined with the reference count of Saika which is associated with an inode of a source file. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng to incorporate the teachings of Saika and include that an initial value of the quantity of links of each inode is O (zero). Doing so would allow for the reference count to directly correspond to the number of libraries referencing the data of a source library. “The reference count C106C is information for managing the life of a clone-source file. The value of the reference count C106C is incremented by 1 each time a clone file, which references the clone-source file, is created. Therefore, for example, "5" is configured in the reference count C106C for a clone-source file, which is referenced by five clone files” [Saika ¶ 118].
With regard to claim 58, Chung in view of Yueh in view of Deng teaches the method according to claim 57, as referenced above. Chung further teaches:
further comprising instructions for deleting a correspondence between a third inode and a third identification from the memory when a quantity of links of the third inode is equal to 1, “During processing associated with a "Zero Count?" block 262, a determination is made as to whether or not the count associated the library currently being processed has reached zero, i.e. indicating that there are no currently loaded applications that reference the library. If so, during processing associated with a "Delete Lib From VSR" block 264, the library currently being processed is deleted from VSR 152” [Chung Col. 8 Lines 5-11].
wherein the third identification is generated by the processor based on the file data of a third shared library by using a preset algorithm. “Hash library 160 stores hash values, or "codes," (see 144), each hash code corresponding to a particular virtual library stored in virtual libraries 162. In conjunction with each stored hash code, are indications of the particular applications associated with the libraries that correspond to the hash codes” [Chung Col. 5 Lines 3-7].
Chung in view of Yueh in view of Deng fails to teach deleting a correspondence between a third inode and a third identification from the memory when a quantity of links of the third inode is equal to 1.
However, Saika teaches deleting a correspondence between a third inode and a third identification from the memory when a quantity of links of the third inode is equal to 1, “Thus, the value of the clone-source file reference count C106C is reduced by 1 each time a clone file is deleted, and when the value of the reference count C106C reaches 0, the clone-source file is deleted” [Saika ¶ 219]. “FIG. 31 is a flowchart showing a clone file deletion process. The file storage 10, upon receiving a file deletion request from the client 40 or a higher-level program, determines whether the delete-target file is a non-clone file (S120). In a case where the delete-target file is a non-clone file (S120: YES), that is, a case in which the delete target is a normal file, the file storage 10 deletes the inode information T10 of the delete-target file entity (S121) … In a case where the delete-target file is a clone file (S122: YES), the file storage 10 deletes the inode information T10 of the delete-target file entity, and, in addition, decrements the value of the reference count C106C of the clone-source file by 1 (S123).” [Saika ¶ 215-217].
With regard to claim 59, Chung in view of Yueh in view of Deng in view of Saika teaches the method according to claim 58, as referenced above. Chung further teaches and determining whether the second shared library having the same file data as the first shared library exists in the memory. “During processing associated with a "Duplicate (Dup.) Hash?" block 214, a determination is made as to whether or not the hash code generated during processing associated with block 212 matches any hash code stored in hash library 160, indicating that the library to be loaded has already been loaded into VSR 152 (FIGS. 2 and3)” [Chung Col. 7 Lines 2-8].
Chung in view of Yueh in view of Deng fails to explicitly teach comparing the file data of the first shared library with file data of each shared library in the memory.
However, Saika teaches:
further comprising instructions for: comparing the file data of the first shared library with file data of each shared library in the memory; “The file storage 10 compares all the clone-source files stored inside this subdirectory to the clone-target file (S111). The file storage 10 determines whether there is a clone-source file, which matches the data of the clone-target file (S112)” [Saika ¶211]. “The file storage 10 determines whether there is a clone-source file, which matches the data of the clone-target file (S112)” [Saika ¶211].
With regard to claim 63, Chung in view of Yueh in view of Deng teaches the chip system according to claim 62, as referenced above. Chung further teaches:
wherein the signal further comprises instructions for: when the second shared library exists in the memory, adding 1 to a quantity of links of the first (library) inode, “During processing associated with an "Increment Lib Reference (Ref.) Count" block 218, the count (see 158, FIG. 2) of applications referencing a particular library in VSR 152 is incremented. If block 218 has been reached from block 216, i.e., the library pointed to has already been stored in conjunction with another application; if reached directly via block 214, the library has typically been loaded into VSR 152 by a previous application.” [Chung Col. 7 Lines 26-33, Fig. 4 Examiner notes “increment lib ref count” block 218 is reached from block 214 when a duplicate hash value is found, meaning that a second shared library having the same file data exists].
wherein the quantity of links of the first (library) inode is a quantity of shared libraries corresponding to the first (library) inode; “VSR 152 includes library reference counts 158, a hash library 160 and virtual libraries 162. Library reference counts 158 stores information on particular virtual libraries in virtual libraries 162 (see 192, 194, FIG. 3), specifically the number of applications current sharing a particular virtual library” [Chung Col. 4 Lines 58-63].
or when the second shared library does not exist in the memory, adding 1 to a quantity of links of the second (library) inode, “During processing associated with an "Increment Lib Reference (Ref.) Count" block 218, the count (see 158, FIG. 2) of applications referencing a particular library in VSR 152 is incremented. If block 218 has been reached from block 216, i.e., the library pointed to has already been stored in conjunction with another application; if reached directly via block 214, the library has typically been loaded into VSR 152 by a previous application.” [Chung Col. 7 Lines 26-33, Fig. 4 Examiner notes “increment lib ref count” block 218 is reached from block 214 when a duplicate hash value is not found meaning that a second shared library having the same file data does not exist].
wherein the quantity of links of the second (library) inode is a quantity of shared libraries corresponding to the second (library) inode, “VSR 152 includes library reference counts 158, a hash library 160 and virtual libraries 162. Library reference counts 158 stores information on particular virtual libraries in virtual libraries 162 (see 192, 194, FIG. 3), specifically the number of applications current sharing a particular virtual library” [Chung Col. 4 Lines 58-63].
Chung fails to teach inode.
However, Yueh teaches inode “The root inode describes an inode file that contains the inodes that describe the rest of the files in the storage 114, 124 of the storage system 110, 120, including a block-map file and inode-map file. The inode files ultimately point to data blocks that make up the inode files” [Yueh ¶ 38].
Chung in view of Yueh in view of Deng fails to explicitly teach and wherein an initial value of the quantity of links of each inode is O (zero).
However, Saika teaches and wherein an initial value of the quantity of links of each inode is O (zero). “In a case where a clone-source file matching the clone-target file does not exist (S112: NO), the file storage 10 adds a clone-source file comprising the same data as the data of the clone-target file to the index directory (S113). Then, the file storage 10 configures the reference count C106C of the added clone-source file to 0 (S114). The file storage 10, either in a case where a clone-source file matching the clone-target file exists (S112: YES), or subsequent to the end of Step S114, configures the inode number of the clone-source file in the reference-destination inode number C106A of the clone-target file inode information T10 (S115)” [Saika ¶ 212-213].
Saika is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Chung includes library reference counts to keep track of how many applications share a library. This can be combined with the reference count of Saika which is associated with an inode of a source file. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng to incorporate the teachings of Saika and include that an initial value of the quantity of links of each inode is O (zero). Doing so would allow for the reference count to directly correspond to the number of libraries referencing the data of a source library. “The reference count C106C is information for managing the life of a clone-source file. The value of the reference count C106C is incremented by 1 each time a clone file, which references the clone-source file, is created. Therefore, for example, "5" is configured in the reference count C106C for a clone-source file, which is referenced by five clone files” [Saika ¶ 118].
Claims 46, 49, 55, and 64 are rejected under 35 U.S.C. 103 as being unpatentable over Chung (US 9,195,503 B2) in view of Yueh (US 2012/0221817 A1) in view of Deng (US 2018/0373544 A1) in view of Saika (US 2013/0333042 A1) in view of Kennedy (US 2018/0267796 A1).
With regard to claim 46, Chung in view of Yueh in view of Deng teaches the method according to claim 44, as referenced above. Chung further teaches:
further comprising: when the electronic device (stops) deletes a second APP, “Process 250 starts in a "Begin Stop Application" block 252 and proceeds immediately to a "Receive Stop Event" block 254. During processing associate with block 254, a request is received by RES 116 (FIG. 1) to halt execution of an application such as applications 118, 120 and 164 (FIGS. 1 and 3). During processing associated with a "Scan for VSR" block 256, VSR 152 (FIGS. 1 and 2) is scanned for indications of any libraries that have been loaded in association with the application being halted” [Chung Col. 7 Lines 50-57].
searching for a third inode corresponding to a file name of a third shared library; “During processing associated with a "Libraries (Libs) Detected?" block 258, a determination is made as to whether or not the application being halted includes any libraries stored in VSR 152. If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 61-67].
and when a quantity of links of the third inode is equal to 1, deleting file data of the third shared library, “If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 64-67]. “During processing associated with a "Zero Count?" block 262, a determination is made as to whether or not the count associated the library currently being processed has reached zero, i.e. indicating that there are no currently loaded applications that reference the library. If so, during processing associated with a "Delete Lib From VSR" block 264, the library currently being processed is deleted from VSR 152” [Chung Col. 8 Lines 5-11 Examiner notes at block 260 a count of 1 is decremented to 0 at which point the shared library is deleted].
or when a quantity of links of the third inode is greater than 1, subtracting 1 from the quantity of links of the third inode. “If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 64-67, Fig. 5].
Chung in view of Yueh in view of Deng fails to teach deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the electronic device.
However, Saika teaches deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the electronic device; “In a case where the delete-target file is a clone file (S122: YES), the file storage 10 deletes the inode information T10 of the delete-target file entity, and, in addition, decrements the value of the reference count C106C of the clone-source file by 1 (S123)” [Saika ¶217].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng to incorporate the teachings of Saika and include deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the electronic device. Doing so would allow for the reference count to directly correspond to the number of libraries referencing the data of a source library. “The reference count C106C is information for managing the life of a clone-source file. The value of the reference count C106C is incremented by 1 each time a clone file, which references the clone-source file, is created. Therefore, for example, "5" is configured in the reference count C106C for a clone-source file, which is referenced by five clone files” [Saika ¶ 118].
Chung in view of Yueh in view of Deng in view of Saika fails to explicitly teach when the electronic device deletes a second APP.
However, Kennedy teaches when the electronic device deletes a second APP, “The number of applications that refer to a particular shared library SL1, also termed a "reference count" for shared library SL1, can be initialized to zero, incremented when a software application is installed that refers to SL1, and decremented when a software application that refers to SL1 is uninstalled” [Kennedy ¶ 37].
Kennedy is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng in view of Saika to incorporate the teachings of Kennedy and include when the electronic device deletes a second APP. Doing so would allow for shared libraries to be closed in the dependency-aware method of Chung when an application is deleted. “In other examples, uninstallation/removal of an application does not cause removal of shared libraries utilized by the now-uninstalled application; rather, some or all of these shared libraries can be considered for removal only if no installed applications refer to the shared libraries” [Kennedy ¶ 61].
With regard to claim 49, Chung in view of Yueh in view of Deng in view of Saika in view of Kennedy teaches the method according to claim 46, as referenced above. Chung further teaches:
further comprising, when the quantity of links of the third inode is equal to 1, deleting a correspondence between the third inode and a third identification from the electronic device, “During processing associated with a "Zero Count?" block 262, a determination is made as to whether or not the count associated the library currently being processed has reached zero, i.e. indicating that there are no currently loaded applications that reference the library. If so, during processing associated with a "Delete Lib From VSR" block 264, the library currently being processed is deleted from VSR 152” [Chung Col. 8 Lines 5-11].
wherein the third identification is generated by the electronic device based on the file data of the third shared library by using a preset algorithm. “Hash library 160 stores hash values, or "codes," (see 144), each hash code corresponding to a particular virtual library stored in virtual libraries 162. In conjunction with each stored hash code, are indications of the particular applications associated with the libraries that correspond to the hash codes” [Chung Col. 5 Lines 3-7].
Chung in view of Yueh in view of Deng fails to teach when the quantity of links of the third inode is equal to 1, deleting a correspondence between the third inode and a third identification from the electronic device.
However, Saika teaches when the quantity of links of the third inode is equal to 1, deleting a correspondence between the third inode and a third identification from the electronic device, “Thus, the value of the clone-source file reference count C106C is reduced by 1 each time a clone file is deleted, and when the value of the reference count C106C reaches 0, the clone-source file is deleted” [Saika ¶ 219]. “FIG. 31 is a flowchart showing a clone file deletion process. The file storage 10, upon receiving a file deletion request from the client 40 or a higher-level program, determines whether the delete-target file is a non-clone file (S120). In a case where the delete-target file is a non-clone file (S120: YES), that is, a case in which the delete target is a normal file, the file storage 10 deletes the inode information T10 of the delete-target file entity (S121) … In a case where the delete-target file is a clone file (S122: YES), the file storage 10 deletes the inode information T10 of the delete-target file entity, and, in addition, decrements the value of the reference count C106C of the clone-source file by 1 (S123).” [Saika ¶ 215-217].
With regard to claim 55, Chung in view of Yueh in view of Deng teaches the method according to claim 53, as referenced above. Chung further teaches:
further comprising instructions for: when (stopping) deleting a second APP, “Process 250 starts in a "Begin Stop Application" block 252 and proceeds immediately to a "Receive Stop Event" block 254. During processing associate with block 254, a request is received by RES 116 (FIG. 1) to halt execution of an application such as applications 118, 120 and 164 (FIGS. 1 and 3). During processing associated with a "Scan for VSR" block 256, VSR 152 (FIGS. 1 and 2) is scanned for indications of any libraries that have been loaded in association with the application being halted” [Chung Col. 7 Lines 50-57].
searching for a third inode corresponding to a file name of a third shared library; “During processing associated with a "Libraries (Libs) Detected?" block 258, a determination is made as to whether or not the application being halted includes any libraries stored in VSR 152. If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 61-67].
and when a quantity of links of the third inode is equal to 1, deleting file data of the third shared library, “If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 64-67]. “During processing associated with a "Zero Count?" block 262, a determination is made as to whether or not the count associated the library currently being processed has reached zero, i.e. indicating that there are no currently loaded applications that reference the library. If so, during processing associated with a "Delete Lib From VSR" block 264, the library currently being processed is deleted from VSR 152” [Chung Col. 8 Lines 5-11 Examiner notes at block 260 a count of 1 is decremented to 0 at which point the shared library is deleted].
or when a quantity of links of the third inode is greater than 1, subtracting 1 from the quantity of links of the third inode. “If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 64-67, Fig. 5].
Chung in view of Yueh in view of Deng fails to teach deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the memory.
However, Saika teaches deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the memory; “In a case where the delete-target file is a clone file (S122: YES), the file storage 10 deletes the inode information T10 of the delete-target file entity, and, in addition, decrements the value of the reference count C106C of the clone-source file by 1 (S123)” [Saika ¶217].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng to incorporate the teachings of Saika and include deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the memory. Doing so would allow for the reference count to directly correspond to the number of libraries referencing the data of a source library. “The reference count C106C is information for managing the life of a clone-source file. The value of the reference count C106C is incremented by 1 each time a clone file, which references the clone-source file, is created. Therefore, for example, "5" is configured in the reference count C106C for a clone-source file, which is referenced by five clone files” [Saika ¶ 118].
Chung in view of Yueh in view of Deng in view of Saika fails to explicitly teach when deleting a second APP.
However, Kennedy teaches when deleting a second APP, “The number of applications that refer to a particular shared library SL1, also termed a "reference count" for shared library SL1, can be initialized to zero, incremented when a software application is installed that refers to SL1, and decremented when a software application that refers to SL1 is uninstalled” [Kennedy ¶ 37].
Kennedy is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng in view of Saika to incorporate the teachings of Kennedy and include when deleting a second APP. Doing so would allow for shared libraries to be closed in the dependency-aware method of Chung when an application is deleted. “In other examples, uninstallation/removal of an application does not cause removal of shared libraries utilized by the now-uninstalled application; rather, some or all of these shared libraries can be considered for removal only if no installed applications refer to the shared libraries” [Kennedy ¶ 61].
With regard to claim 64, Chung in view of Yueh in view of Deng teaches the chip system according to claim 62, as referenced above. Chung further teaches:
wherein the signal further comprises instructions for: when (stopping) deleting a second APP, “Process 250 starts in a "Begin Stop Application" block 252 and proceeds immediately to a "Receive Stop Event" block 254. During processing associate with block 254, a request is received by RES 116 (FIG. 1) to halt execution of an application such as applications 118, 120 and 164 (FIGS. 1 and 3). During processing associated with a "Scan for VSR" block 256, VSR 152 (FIGS. 1 and 2) is scanned for indications of any libraries that have been loaded in association with the application being halted” [Chung Col. 7 Lines 50-57].
searching for a third inode corresponding to a file name of a third shared library; “During processing associated with a "Libraries (Libs) Detected?" block 258, a determination is made as to whether or not the application being halted includes any libraries stored in VSR 152. If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 61-67].
and when a quantity of links of the third inode is equal to 1, deleting file data of the third shared library, “If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 64-67]. “During processing associated with a "Zero Count?" block 262, a determination is made as to whether or not the count associated the library currently being processed has reached zero, i.e. indicating that there are no currently loaded applications that reference the library. If so, during processing associated with a "Delete Lib From VSR" block 264, the library currently being processed is deleted from VSR 152” [Chung Col. 8 Lines 5-11 Examiner notes at block 260 a count of 1 is decremented to 0 at which point the shared library is deleted].
or when a quantity of links of the third inode is greater than 1, subtracting 1 from the quantity of links of the third inode. “If so, during processing associated with a "Decrement Count" block 260, the count (see 158, FIG. 2) associated with the first library detected during processing associated with block 256 is decremented [Chung Col. 7 Lines 64-67, Fig. 5].
Chung in view of Yueh in view of Deng fails to teach deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the memory.
However, Saika teaches deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the memory; “In a case where the delete-target file is a clone file (S122: YES), the file storage 10 deletes the inode information T10 of the delete-target file entity, and, in addition, decrements the value of the reference count C106C of the clone-source file by 1 (S123)” [Saika ¶217].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng to incorporate the teachings of Saika and include deleting … the third inode, and a correspondence between the file name of the third shared library and the third inode from the memory. Doing so would allow for the reference count to directly correspond to the number of libraries referencing the data of a source library. “The reference count C106C is information for managing the life of a clone-source file. The value of the reference count C106C is incremented by 1 each time a clone file, which references the clone-source file, is created. Therefore, for example, "5" is configured in the reference count C106C for a clone-source file, which is referenced by five clone files” [Saika ¶ 118].
Chung in view of Yueh in view of Deng in view of Saika fails to explicitly teach when deleting a second APP.
However, Kennedy teaches when deleting a second APP, “The number of applications that refer to a particular shared library SL1, also termed a "reference count" for shared library SL1, can be initialized to zero, incremented when a software application is installed that refers to SL1, and decremented when a software application that refers to SL1 is uninstalled” [Kennedy ¶ 37].
Kennedy is considered to be analogous to the claimed invention because it is in the same field of support for shared access to files. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Chung in view of Yueh in view of Deng in view of Saika to incorporate the teachings of Kennedy and include when deleting a second APP. Doing so would allow for shared libraries to be closed in the dependency-aware method of Chung when an application is deleted. “In other examples, uninstallation/removal of an application does not cause removal of shared libraries utilized by the now-uninstalled application; rather, some or all of these shared libraries can be considered for removal only if no installed applications refer to the shared libraries” [Kennedy ¶ 61].
Response to Arguments
Applicant's arguments filed 03/03/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
I. These limitations are not taught by either Chung or Yueh. As discussed in the previous response filed on 17 October 2025, Chung, as may be understood, is directed to automatic detection of shared libraries and creation of a virtual scope repository from the detected shared libraries. Chung discloses a Runtime Execution Server (RES). The RES itself implements loading of classes and, as the name suggests, supports an application while it is loading or running. Put differently, Chung teaches detecting the presence of a resource, e.g. a library, that is to be loaded within a virtual scope repository. If the resource is found within the virtual scope repository, the library is not loaded in favor of using the virtual scope repository. This functionality is disclosed as carried out by an augmented class loader. Thus, when a user launches an application, the application may attempt to load a shared library, which may in turn be intercepted and redirected to the virtual scope repository.
In contrast, each independent claim 42, 51, and 60 recites an APP monitoring component that monitors an APP for either completion of installation or completion of running, then sends a notification message to a reusing component following completion of installation or completion of running. The reusing component then determines whether the second shared library has file data the same as the file data of the first shared library. Chung fails to disclose either monitoring or a notification, let alone an APP monitoring component or a reusing component.
Accordingly, independent claims 42, 51, and 60 are allowable over the combination of Chung in view of Yueh.
a) Examiner respectfully disagrees. Chung teaches wherein determining whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the memory comprises: [Chung Col. 1 Lines 43-47] and determining, by the reusing component, whether the second shared library having file data the same as the file data of the first shared library of the first APP exists in the electronic device [Chung Col. 5 Lines 21-27]. The augmented class loader (ACL) of Chung is considered a reusing component because it fulfills the functionality of determining duplicate libraries: “ACL 122 can detect a library that is identical to a library that has previously been loaded by another application” [Chung Col. 5 Lines 25-27].
Further, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “The reusing component then determines whether the second shared library has file data the same as the file data of the first shared library”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). “… the court held that it was improper to read a specific order of steps into method claims where, as a matter of logic or grammar, the language of the method claims did not impose a specific order on the performance of the method steps, and the specification did not directly or implicitly require a particular order” [MPEP § 2111.01 (II)]. The independent claims as written do not impose the order of the statements that Applicant argues of: an APP monitoring component that monitors an APP for either completion of installation or completion of running, then sends a notification message to a reusing component following completion of installation or completion of running. The reusing component then determines whether the second shared library has file data the same as the file data of the first shared library.
Applicant’s further arguments with respect to claim(s) 42, 51, and 60 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. The arguments have been considered but were not found to be persuasive.
Conclusion
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bradley Teets can be reached at (571) 272-3338. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197