DETAILED ACTION
1. This Office Action is taken in response to Applicants’ Amendments and Remarks filed on 5/5/2026 regarding application 18/497,878 filed on 10/30/2023.
Claims 1-20 are pending for consideration.
2. Response to Amendments and Remarks
Applicants’ amendments and remarks have been fully and carefully considered, with the Examiner’s response set forth below.
(1) In response to the amendments and remarks, an updated claim analysis has been made, with additional, newly identified references. Refer to the corresponding sections of the following Office Action for details.
3. Examiner’s Note
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121(b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131(b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as “Applicants believe no new matter has been introduced” may be deemed insufficient.
(2) Examiner has cited particular columns/paragraph and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
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.
4. Claims 1, 4, 6-7, 9, 12, 14-15, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Oikarinen (US Patent Application Publication 2012/0290582), and in view of Milligan et al. (US Patent 6,996,682, hereinafter Milligan).
As to claim 1, Oikarinen teaches A method of database management [On the other hand, in order to improve manageability, performance and availability of the information, these distributed information spaces are built based on large-scale distributed data storages (e.g., databases) that can scale to petabytes or even larger with the capability of maintaining ordered access keys. However, the existing architectures for distributed database management, such as, for example, Google BigTable.RTM., Cassandra.RTM., HBase.RTM., etc. require centralized management of key ranges … (¶ 0002);
Milligan also teaches this limitation – figure 10, 1050, “metadata copy tracking database”], the method comprising:
generating a first metadata table, a second metadata table, and a third metadata table from a preliminary metadata table [as shown in figure 1, where the corresponding “metadata tables” are “nodes with key range” (115a-115z); as shown in figure 5A, where node 115i with key range (505) is the corresponding preliminary metadata table; as shown in figure 5B, where a new node 115-2 with key range (521) is generated; as shown in figure 5C, where a second new node 115-3 with key range (543) is generated; FIGS. 5A-5C are diagrams of node creation and balancing, according to various embodiments. FIG. 5A shows a key distribution curve 505, wherein the vertical axis 501 is the key density (e.g., number of keys) and the horizontal axis 503 shows the key space … In the example of FIG. 5A, the key space 503 is on a node 115i of a server 113j … In one embodiment, as the number of keys grows, the number of keys on node 115i reaches the threshold of node 115i (e.g., the number of keys the node 115i is capable of storing). In this case, the node 115i is split by the rebalance module 201 into two nodes 115i and 115i-2. The new node 115i-2 may be stored on the same server 113j as the server for node 115i or on another server 113t. FIG. 5B shows the node splitting process. In FIG. 5B, the vertical axis 511 is the key density (e.g., number of keys) and the horizontal axis 513 shows the key space. As the number of keys increases, the pick point of the key curve 515 grows higher. In such situations the rebalance module 201 splits the key curve 515 into two half curves 519 and 521 as shown by the vertical line 517 … FIG. 5C shows a situation, wherein the node 115i is split into more than two, because the total number of keys in the key space exceeds the threshold capacity of node 115i and the node 115i-2 which is the first node split from 115i. The node split process may continue multiple times until the number of keys on the original node and its split new nodes meet the limit of the number of keys for each node … (¶ 0060-0064);
Milligan specifically cites the term “metadata tables” – as shown in figure 5, where the metadata table before snapshot (510) is the corresponding preliminary metadata table, and the metadata tables (520, 530, 540) are the corresponding first, second, and third metadata tables, respectively; as shown in figure 6, where the original metadata table (610) is used to generated a plurality of metadata tables (620-640); FIG. 5 is an exemplary diagram illustrating an example instant copy and data change operation that may be used with the present invention. As shown in FIG. 5, during a first phase 510 of the instant copy operation, metadata entries A1 A3 in the metadata table point to data tracks A1 A3 … (c7 L9-62)], based on a size of the preliminary metadata table satisfying a threshold, the size of the preliminary metadata table corresponding to a number of keys in the preliminary metadata table [In one embodiment, as the number of keys grows, the number of keys on node 115i reaches the threshold of node 115i (e.g., the number of keys the node 115i is capable of storing). In this case, the node 115i is split by the rebalance module 201 into two nodes 115i and 115i-2. The new node 115i-2 may be stored on the same server 113j as the server for node 115i or on another server 113t. FIG. 5B shows the node splitting process. In FIG. 5B, the vertical axis 511 is the key density (e.g., number of keys) and the horizontal axis 513 shows the key space. As the number of keys increases, the pick point of the key curve 515 grows higher. In such situations the rebalance module 201 splits the key curve 515 into two half curves 519 and 521 as shown by the vertical line 517 … FIG. 5C shows a situation, wherein the node 115i is split into more than two, because the total number of keys in the key space exceeds the threshold capacity of node 115i and the node 115i-2 which is the first node split from 115i. The node split process may continue multiple times until the number of keys on the original node and its split new nodes meet the limit of the number of keys for each node … (¶ 0061-0064)];
changing the size of the preliminary metadata table based on the size of the preliminary metadata table satisfying the threshold [as shown in figures 5A, 5B, and 5C, where portions of the key range of the old/original /preliminary node 115i are moved to the newly generated nodes 115-2 and 115-3, respectively; ... Once a new node 115a-2 is generated in another server, half of the key range of node 115a (from the following key to the middle key N/2 to the end of the range) is moved to the new node 115a-2 so that nodes 115a and 115a-2 each store half of the initial key range of node 115a ... (¶ 0059-0064); FIG. 6B shows an embodiment wherein the read/write request triggers rebalance of the nodes ... Per arrow 629, the node generator 203 adds a new node, split from the old node on the server 113a, to server 113k and receives a message of successful generation of the new node from server 113k per arrow 631 ... Per arrow 635 the server 113a moves keys from the midpoint of the old node to the new node generated on server 113k and receives a message regarding the receipt of keys from server 113k per arrow 637. In step 639, the server 113a deletes the keys that were moved to server 113k from the old node and sets the endpoint of the old node to the value of the previous midpoint. For example, if the old node on server 113a has a limit of 10,000 keys and it is over the limit (has 10,001 keys) the keys will be divided into two ranges (1 to 5,000) and (5,001 to 10,001). The range (1 to 5,000) is kept on the old node and the range (5,001 to 10,001) is moved to the new node on server 113k. Additionally, the current upper limit of ranges on both old and new nodes is set to 5,000, since each include half the keys of the previous key range on the old node (¶ 0071)];
locating, with a recovery logic, the first metadata table using a beginning metadata table key [the corresponding “recovery logic” comprises “a linked-list structure” that connects all nodes sequentially -- FIGS. 6A-6C are diagrams of sequences for locating nodes, according to various embodiments. In one embodiment, the link between nodes 115a-115i or 115j-115z can be maintained by creating a linked list, in which node 115a points to node 115b, node 115b points to node 115c, etc. and vice versa (each node points to its next and previous node). In this embodiment, node requests originated from any server 113a-113k provide pointers towards other nodes. In another embodiment, each server 113a-113k maintains a list of nodes it has and whenever a node 115i is split into 115i and 115i-2, the newly generated node 115i-2 stores a reference (e.g., a link) to the remote server 113a-113k where it will be stored (¶ 0065-0066);
Milligan also teaches this limitation – as shown in figures 5 and 6; A system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies are provided. Virtual copies are created and managed through the use of an instant copy mechanism. Metadata subsets manage both the original data and the copies created by the instant copy mechanism. With an exemplary embodiment of the system and method, changes made to one copy of the data are cascaded to all child copies of the data. In this paradigm not only is the metadata entry for one particular copy changed, but also the corresponding metadata entries of any copies descended from that copy. In an exemplary method, a tree structure is used to maintain a record of all metadata table subsets created by use of an instant copy method. The tree structure can then be searched to find all child copies of a particular copy (abstract); The present invention provides a system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies. In an exemplary embodiment of the present invention, a data structure is maintained for keeping track of which copies of metadata are dependent from other copies of metadata, i.e. which copies are parent copies of metadata and which copies are child copies of metadata. This data structure is a tree data structure in which nodes of the tree are copies of metadata and arcs connect parent nodes to child nodes. The metadata may consist of offsets, pointers, bitmaps, timestamps, file sizes, and/or other information. The key feature for the purposes of the present invention is that the metadata can be used to derive the physical location on the storage device of its associated data. This may be a track, cylinder, or other unit of storage on a storage medium. The metadata may indicate the size or granularity of the physical unit of storage as well as the number of consecutive physical units of storage used to store the data (c2 L9-27); As an example of how to address this problem, the present invention provides a mechanism for keeping track of the hierarchy of virtual copies of data, i.e. metadata tables. In a preferred embodiment, this mechanism takes the form of a tree data structure. In an alternative embodiment, this mechanism may be using linked lists in which each metadata table subset created by an instant copy method may have a reference to a linked list of pointers to the start of any metadata table subsets created of a child copy … (c7 L63 to c8 L56); it is noted that the “tree data structure” and “linked lists” correspond to the “recovery logic”]; and
retrieving, with the recovery logic, a first link key of the first metadata table [the corresponding “recovery logic” comprises “a linked-list structure” that connects all nodes sequentially -- FIGS. 6A-6C are diagrams of sequences for locating nodes, according to various embodiments. In one embodiment, the link between nodes 115a-115i or 115j-115z can be maintained by creating a linked list, in which node 115a points to node 115b, node 115b points to node 115c, etc. and vice versa (each node points to its next and previous node). In this embodiment, node requests originated from any server 113a-113k provide pointers towards other nodes. In another embodiment, each server 113a-113k maintains a list of nodes it has and whenever a node 115i is split into 115i and 115i-2, the newly generated node 115i-2 stores a reference (e.g., a link) to the remote server 113a-113k where it will be stored (¶ 0065-0066);
Milligan also teaches this limitation – as shown in figures 5 and 6; A system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies are provided. Virtual copies are created and managed through the use of an instant copy mechanism. Metadata subsets manage both the original data and the copies created by the instant copy mechanism. With an exemplary embodiment of the system and method, changes made to one copy of the data are cascaded to all child copies of the data. In this paradigm not only is the metadata entry for one particular copy changed, but also the corresponding metadata entries of any copies descended from that copy. In an exemplary method, a tree structure is used to maintain a record of all metadata table subsets created by use of an instant copy method. The tree structure can then be searched to find all child copies of a particular copy (abstract); The present invention provides a system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies. In an exemplary embodiment of the present invention, a data structure is maintained for keeping track of which copies of metadata are dependent from other copies of metadata, i.e. which copies are parent copies of metadata and which copies are child copies of metadata. This data structure is a tree data structure in which nodes of the tree are copies of metadata and arcs connect parent nodes to child nodes. The metadata may consist of offsets, pointers, bitmaps, timestamps, file sizes, and/or other information. The key feature for the purposes of the present invention is that the metadata can be used to derive the physical location on the storage device of its associated data. This may be a track, cylinder, or other unit of storage on a storage medium. The metadata may indicate the size or granularity of the physical unit of storage as well as the number of consecutive physical units of storage used to store the data (c2 L9-27); As an example of how to address this problem, the present invention provides a mechanism for keeping track of the hierarchy of virtual copies of data, i.e. metadata tables. In a preferred embodiment, this mechanism takes the form of a tree data structure. In an alternative embodiment, this mechanism may be using linked lists in which each metadata table subset created by an instant copy method may have a reference to a linked list of pointers to the start of any metadata table subsets created of a child copy … (c7 L63 to c8 L56); it is noted that the “tree data structure” and “linked lists” correspond to the “recovery logic”].
Regarding claim 1, Oikarinen teaches a plurality of nodes, each with its own key range [as shown in figure 1, where the corresponding “metadata tables” are “nodes with key range” (115a-115z); as shown in figure 5A, where node 115i with key range (505) is the corresponding preliminary metadata table; as shown in figure 5B, where a new node 115-2 with key range (521) is generated; as shown in figure 5C, where a second new node 115-3 with key range (543) is generated; FIGS. 5A-5C are diagrams of node creation and balancing, according to various embodiments. FIG. 5A shows a key distribution curve 505, wherein the vertical axis 501 is the key density (e.g., number of keys) and the horizontal axis 503 shows the key space … In the example of FIG. 5A, the key space 503 is on a node 115i of a server 113j … In one embodiment, as the number of keys grows, the number of keys on node 115i reaches the threshold of node 115i (e.g., the number of keys the node 115i is capable of storing). In this case, the node 115i is split by the rebalance module 201 into two nodes 115i and 115i-2. The new node 115i-2 may be stored on the same server 113j as the server for node 115i or on another server 113t. FIG. 5B shows the node splitting process. In FIG. 5B, the vertical axis 511 is the key density (e.g., number of keys) and the horizontal axis 513 shows the key space. As the number of keys increases, the pick point of the key curve 515 grows higher. In such situations the rebalance module 201 splits the key curve 515 into two half curves 519 and 521 as shown by the vertical line 517 … FIG. 5C shows a situation, wherein the node 115i is split into more than two, because the total number of keys in the key space exceeds the threshold capacity of node 115i and the node 115i-2 which is the first node split from 115i. The node split process may continue multiple times until the number of keys on the original node and its split new nodes meet the limit of the number of keys for each node … (¶ 0060-0064)], but does not refer to these nosed as “metadata tables.”
However, claim 1 merely recites the term “metadata tables,” and is otherwise completely silent on the scope, definitions, and unique features of the metadata tables. In addition, figures 1-4 of the drawings of the current Application illustrate the claimed “metadata tables” merely comprise “range of keys,” and nothing further. Therefore, within the context of the claimed invention and as far as claim 1 is concerned, any entity comprises a range of keys would qualify as a metadata table.
Further, Milligan specifically uses and cites the term “metadata table” in a data processing system [as shown in figure 5, where the metadata table before snapshot (510) is the corresponding preliminary metadata table, and the metadata tables (520, 530, 540) are the corresponding first, second, and third metadata tables, respectively; as shown in figure 6, where the original metadata table (610) is used to generated a plurality of metadata tables (620-640); FIG. 5 is an exemplary diagram illustrating an example instant copy and data change operation that may be used with the present invention. As shown in FIG. 5, during a first phase 510 of the instant copy operation, metadata entries A1 A3 in the metadata table point to data tracks A1 A3 … (c7 L9-62)].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to recognize that the “nodes with ranges of keys” disclosed by Oikarinen are legitimate “metadata tables” as far as claim 1 is concerned, and the fact that Milligan specifically uses and cites the term “metadata tables” in a data processing system. Therefore, the term “metadata tables” alone lacks patentable significance in light of the teaches of both Oikarinen and Milligan, which render it obvious,
As to claim 4, Oikarinen in view of Milligan teaches The method of claim 2, wherein: the second metadata table comprises a second metadata table key range; the third metadata table comprises a third metadata table key range between a first metadata table key range and the second metadata table key range [Oikarinen – as shown in figure 5C, where the key range of node 115-3 is between the key ranges of nodes 115i and 115-2]; and the method further comprises updating, by the recovery logic, the first metadata table key range or the third metadata table key range to include the second metadata table key range [Oikarinen – FIG. 6B shows an embodiment wherein the read/write request triggers rebalance of the nodes ... Per arrow 629, the node generator 203 adds a new node, split from the old node on the server 113a, to server 113k and receives a message of successful generation of the new node from server 113k per arrow 631 ... Per arrow 635 the server 113a moves keys from the midpoint of the old node to the new node generated on server 113k and receives a message regarding the receipt of keys from server 113k per arrow 637. In step 639, the server 113a deletes the keys that were moved to server 113k from the old node and sets the endpoint of the old node to the value of the previous midpoint. For example, if the old node on server 113a has a limit of 10,000 keys and it is over the limit (has 10,001 keys) the keys will be divided into two ranges (1 to 5,000) and (5,001 to 10,001). The range (1 to 5,000) is kept on the old node and the range (5,001 to 10,001) is moved to the new node on server 113k. Additionally, the current upper limit of ranges on both old and new nodes is set to 5,000, since each include half the keys of the previous key range on the old node (¶ 0071)].
As to claim 6, Oikarinen in view of Milligan teaches The method of claim 1, further comprising allocating, by the recovery logic, the first link key [Oikarinen – the corresponding “recovery logic” comprises “a linked-list structure” that connects all nodes sequentially -- FIGS. 6A-6C are diagrams of sequences for locating nodes, according to various embodiments. In one embodiment, the link between nodes 115a-115i or 115j-115z can be maintained by creating a linked list, in which node 115a points to node 115b, node 115b points to node 115c, etc. and vice versa (each node points to its next and previous node). In this embodiment, node requests originated from any server 113a-113k provide pointers towards other nodes. In another embodiment, each server 113a-113k maintains a list of nodes it has and whenever a node 115i is split into 115i and 115i-2, the newly generated node 115i-2 stores a reference (e.g., a link) to the remote server 113a-113k where it will be stored (¶ 0065-0066);
Milligan also teaches this limitation – as shown in figures 5 and 6; A system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies are provided. Virtual copies are created and managed through the use of an instant copy mechanism. Metadata subsets manage both the original data and the copies created by the instant copy mechanism. With an exemplary embodiment of the system and method, changes made to one copy of the data are cascaded to all child copies of the data. In this paradigm not only is the metadata entry for one particular copy changed, but also the corresponding metadata entries of any copies descended from that copy. In an exemplary method, a tree structure is used to maintain a record of all metadata table subsets created by use of an instant copy method. The tree structure can then be searched to find all child copies of a particular copy (abstract); The present invention provides a system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies. In an exemplary embodiment of the present invention, a data structure is maintained for keeping track of which copies of metadata are dependent from other copies of metadata, i.e. which copies are parent copies of metadata and which copies are child copies of metadata. This data structure is a tree data structure in which nodes of the tree are copies of metadata and arcs connect parent nodes to child nodes. The metadata may consist of offsets, pointers, bitmaps, timestamps, file sizes, and/or other information. The key feature for the purposes of the present invention is that the metadata can be used to derive the physical location on the storage device of its associated data. This may be a track, cylinder, or other unit of storage on a storage medium. The metadata may indicate the size or granularity of the physical unit of storage as well as the number of consecutive physical units of storage used to store the data (c2 L9-27); As an example of how to address this problem, the present invention provides a mechanism for keeping track of the hierarchy of virtual copies of data, i.e. metadata tables. In a preferred embodiment, this mechanism takes the form of a tree data structure. In an alternative embodiment, this mechanism may be using linked lists in which each metadata table subset created by an instant copy method may have a reference to a linked list of pointers to the start of any metadata table subsets created of a child copy … (c7 L63 to c8 L56); it is noted that the “tree data structure” and “linked lists” correspond to the “recovery logic”].
As to claim 7, Oikarinen in view of Milligan teaches The method of claim 1, further comprising storing, by the recovery logic, a first allocated metadata table key of the first metadata table and the beginning metadata table key in a manifest [Oikarinen – the corresponding “recovery logic” comprises “a linked-list structure” that connects all nodes sequentially -- FIGS. 6A-6C are diagrams of sequences for locating nodes, according to various embodiments. In one embodiment, the link between nodes 115a-115i or 115j-115z can be maintained by creating a linked list, in which node 115a points to node 115b, node 115b points to node 115c, etc. and vice versa (each node points to its next and previous node). In this embodiment, node requests originated from any server 113a-113k provide pointers towards other nodes. In another embodiment, each server 113a-113k maintains a list of nodes it has and whenever a node 115i is split into 115i and 115i-2, the newly generated node 115i-2 stores a reference (e.g., a link) to the remote server 113a-113k where it will be stored (¶ 0065-0066);
Milligan also teaches this limitation – as shown in figures 5 and 6; A system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies are provided. Virtual copies are created and managed through the use of an instant copy mechanism. Metadata subsets manage both the original data and the copies created by the instant copy mechanism. With an exemplary embodiment of the system and method, changes made to one copy of the data are cascaded to all child copies of the data. In this paradigm not only is the metadata entry for one particular copy changed, but also the corresponding metadata entries of any copies descended from that copy. In an exemplary method, a tree structure is used to maintain a record of all metadata table subsets created by use of an instant copy method. The tree structure can then be searched to find all child copies of a particular copy (abstract); The present invention provides a system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies. In an exemplary embodiment of the present invention, a data structure is maintained for keeping track of which copies of metadata are dependent from other copies of metadata, i.e. which copies are parent copies of metadata and which copies are child copies of metadata. This data structure is a tree data structure in which nodes of the tree are copies of metadata and arcs connect parent nodes to child nodes. The metadata may consist of offsets, pointers, bitmaps, timestamps, file sizes, and/or other information. The key feature for the purposes of the present invention is that the metadata can be used to derive the physical location on the storage device of its associated data. This may be a track, cylinder, or other unit of storage on a storage medium. The metadata may indicate the size or granularity of the physical unit of storage as well as the number of consecutive physical units of storage used to store the data (c2 L9-27); As an example of how to address this problem, the present invention provides a mechanism for keeping track of the hierarchy of virtual copies of data, i.e. metadata tables. In a preferred embodiment, this mechanism takes the form of a tree data structure. In an alternative embodiment, this mechanism may be using linked lists in which each metadata table subset created by an instant copy method may have a reference to a linked list of pointers to the start of any metadata table subsets created of a child copy … (c7 L63 to c8 L56); it is noted that the “tree data structure” and “linked lists” correspond to the “recovery logic”].
As to claim 9, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to "As to claim 1" presented earlier in this Office Action for details.
As to claim 12, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to "As to claim 4" presented earlier in this Office Action for details.
As to claim 14, it recites substantially the same limitations as in claim 6, and is rejected for the same reasons set forth in the analysis of claim 6. Refer to "As to claim 6" presented earlier in this Office Action for details.
As to claim 15, it recites substantially the same limitations as in claim 7, and is rejected for the same reasons set forth in the analysis of claim 7. Refer to "As to claim 7" presented earlier in this Office Action for details.
As to claim 17, it recites substantially the same limitations as in claim 1, and is rejected for the same reasons set forth in the analysis of claim 1. Refer to "As to claim 1" presented earlier in this Office Action for details.
As to claim 20, it recites substantially the same limitations as in claim 4, and is rejected for the same reasons set forth in the analysis of claim 4. Refer to "As to claim 4" presented earlier in this Office Action for details.
5. Claims 8, and 16 are rejected under 103 as being unpatentable over Oikarinen in view of Milligan, and further in view of Milligan et al. (US Patent Application Publication 2004/0128269, hereinafter Milligan2004).
As to claim 8, Oikarinen in view of Milligan does not teach associating the first metadata table with a write lock.
However, using a lock to prevent data from being changed is well non and commonly adopted in the art to maintain data integrity.
For example, Milligan2004 specifically teaches associating the first metadata table with a write lock [metadata table, figure 4, 410; figure 5, 510, 520, 530, 540, 550, and 560; The present invention describes a method for managing data through the use of metadata. More specifically, the present invention is directed to a system and method of families of inter-related tables of metadata in which the tables are logically linked. When certain types of changes are made to any member of such a family these changes will be propagated to all members of that family. This mechanism is particularly suited to use in distributed systems, where diverse elements of the system would each contain logically linked metadata tables that are members of some such family of tables (¶ 0003); … When an application desires to change a metadata entry in a locally stored metadata table, the application must first request a lock of the physical storage location associated with the metadata entry. Once the lock is obtained, the data at the physical storage location and the corresponding metadata entry in the local copy of the metadata table may be modified (¶ 0014)].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to associate the first metadata table with a write lock as demonstrated by Milligan2004, and to incorporate it into the existing scheme disclosed by Oikarinen in view of Milligan, in order to maintain the control and integrity of the metadata data entries.
A s to claim 16, it recites substantially the same limitations as in claim 8, and is rejected for the same reasons set forth in the analysis of claim 8. Refer to "As to claim 8" presented earlier in this Office Action for details.
6. Claims 2-3, 5, 10-11, 13, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Oikarinen in view of Milligan, and further in view of Rousseau (US Patent Application Publication 2011/0072300).
As to claim 2, Oikarinen in view of Milligan teaches The method of claim 1, further comprising: locating, by the recovery logic, the second metadata table based on the first link key or based on a third link key of the third metadata table [Oikarinen – the corresponding “recovery logic” comprises “a linked-list structure” that connects all nodes sequentially -- FIGS. 6A-6C are diagrams of sequences for locating nodes, according to various embodiments. In one embodiment, the link between nodes 115a-115i or 115j-115z can be maintained by creating a linked list, in which node 115a points to node 115b, node 115b points to node 115c, etc. and vice versa (each node points to its next and previous node). In this embodiment, node requests originated from any server 113a-113k provide pointers towards other nodes. In another embodiment, each server 113a-113k maintains a list of nodes it has and whenever a node 115i is split into 115i and 115i-2, the newly generated node 115i-2 stores a reference (e.g., a link) to the remote server 113a-113k where it will be stored (¶ 0065-0066);
Milligan also teaches this limitation – as shown in figures 5 and 6; A system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies are provided. Virtual copies are created and managed through the use of an instant copy mechanism. Metadata subsets manage both the original data and the copies created by the instant copy mechanism. With an exemplary embodiment of the system and method, changes made to one copy of the data are cascaded to all child copies of the data. In this paradigm not only is the metadata entry for one particular copy changed, but also the corresponding metadata entries of any copies descended from that copy. In an exemplary method, a tree structure is used to maintain a record of all metadata table subsets created by use of an instant copy method. The tree structure can then be searched to find all child copies of a particular copy (abstract); The present invention provides a system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies. In an exemplary embodiment of the present invention, a data structure is maintained for keeping track of which copies of metadata are dependent from other copies of metadata, i.e. which copies are parent copies of metadata and which copies are child copies of metadata. This data structure is a tree data structure in which nodes of the tree are copies of metadata and arcs connect parent nodes to child nodes. The metadata may consist of offsets, pointers, bitmaps, timestamps, file sizes, and/or other information. The key feature for the purposes of the present invention is that the metadata can be used to derive the physical location on the storage device of its associated data. This may be a track, cylinder, or other unit of storage on a storage medium. The metadata may indicate the size or granularity of the physical unit of storage as well as the number of consecutive physical units of storage used to store the data (c2 L9-27); As an example of how to address this problem, the present invention provides a mechanism for keeping track of the hierarchy of virtual copies of data, i.e. metadata tables. In a preferred embodiment, this mechanism takes the form of a tree data structure. In an alternative embodiment, this mechanism may be using linked lists in which each metadata table subset created by an instant copy method may have a reference to a linked list of pointers to the start of any metadata table subsets created of a child copy … (c7 L63 to c8 L56); it is noted that the “tree data structure” and “linked lists” correspond to the “recovery logic”].
Regarding claim 2, Oikarinen in view of Milligan does not teach determining, by the recovery logic, that the second metadata table contains first erroneous keys in a second metadata table key range; and making available, by the recovery logic, first memory space associated with the second metadata table.
However, Rousseau teaches the cited limitations. Specifically, Rousseau teaches determining that the second metadata table contains first erroneous keys in a second metadata table key range; and making available first memory space associated with the second metadata table [According to one embodiment, the method comprises the steps consisting of: defining a virtual memory comprising logical pages having a logical address; defining, in the logical pages, logical blocks having a logical address; defining write commands and read commands of data in the logical blocks; defining, in the first memory zone, erasable physical pages having a physical address; defining, in the erasable physical pages, programmable physical blocks of the same size as the logical blocks and having a physical address; and defining, in the second memory zone, metadata structures associated with the physical blocks, comprising information about the status of each physical block from among the following statuses: block erased, block containing a valid data, or block containing an invalid data (¶ 0022); On the other hand, the program VPG implements the data write method with delayed erase both in the memory zone A1 and in the memory zone A2. Thus, maintenance tasks are equally provided in the memory zone A2 so as to free up memory space for the metadata by erasure of pages containing invalid metadata … The program VPG determines an optimum repartition between the memory space attributed to data and the memory space attributed to metadata, and thus determines the limits of each memory zone. The physical memory zone A1 is necessarily larger than the virtual memory zone due to the invalid data generated by the delayed-erase write method … (¶ 0069-0070)].
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to determine the second metadata table contains first erroneous data in a second metadata table address range; and making available first memory space associated with the second metadata table, as demonstrated by Rousseau, and to incorporate it into the existing scheme disclosed by Oikarinen in view of Milligan, because Rousseau teaches doing so prevent memory space from being exhausted by invalid data [Besides tasks of erasing invalid data, the program VPG may conduct maintenance tasks consisting of regrouping the valid data that are dispersed in the memory array in order to reveal groups of invalid data that will then be erased in order to free up memory space (¶ 0056)].
As to claim 3, Oikarinen in view of Milligan & Rousseau teaches The method of claim 2, further comprising updating, by the recovery logic, the first link key or the third link key to comprise a second link key of the second metadata table [Oikarinen – the corresponding “recovery logic” comprises “a linked-list structure” that connects all nodes sequentially -- FIGS. 6A-6C are diagrams of sequences for locating nodes, according to various embodiments. In one embodiment, the link between nodes 115a-115i or 115j-115z can be maintained by creating a linked list, in which node 115a points to node 115b, node 115b points to node 115c, etc. and vice versa (each node points to its next and previous node). In this embodiment, node requests originated from any server 113a-113k provide pointers towards other nodes. In another embodiment, each server 113a-113k maintains a list of nodes it has and whenever a node 115i is split into 115i and 115i-2, the newly generated node 115i-2 stores a reference (e.g., a link) to the remote server 113a-113k where it will be stored (¶ 0065-0066);
Milligan also teaches this limitation – as shown in figures 5 and 6; A system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies are provided. Virtual copies are created and managed through the use of an instant copy mechanism. Metadata subsets manage both the original data and the copies created by the instant copy mechanism. With an exemplary embodiment of the system and method, changes made to one copy of the data are cascaded to all child copies of the data. In this paradigm not only is the metadata entry for one particular copy changed, but also the corresponding metadata entries of any copies descended from that copy. In an exemplary method, a tree structure is used to maintain a record of all metadata table subsets created by use of an instant copy method. The tree structure can then be searched to find all child copies of a particular copy (abstract); The present invention provides a system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies. In an exemplary embodiment of the present invention, a data structure is maintained for keeping track of which copies of metadata are dependent from other copies of metadata, i.e. which copies are parent copies of metadata and which copies are child copies of metadata. This data structure is a tree data structure in which nodes of the tree are copies of metadata and arcs connect parent nodes to child nodes. The metadata may consist of offsets, pointers, bitmaps, timestamps, file sizes, and/or other information. The key feature for the purposes of the present invention is that the metadata can be used to derive the physical location on the storage device of its associated data. This may be a track, cylinder, or other unit of storage on a storage medium. The metadata may indicate the size or granularity of the physical unit of storage as well as the number of consecutive physical units of storage used to store the data (c2 L9-27); As an example of how to address this problem, the present invention provides a mechanism for keeping track of the hierarchy of virtual copies of data, i.e. metadata tables. In a preferred embodiment, this mechanism takes the form of a tree data structure. In an alternative embodiment, this mechanism may be using linked lists in which each metadata table subset created by an instant copy method may have a reference to a linked list of pointers to the start of any metadata table subsets created of a child copy … (c7 L63 to c8 L56); it is noted that the “tree data structure” and “linked lists” correspond to the “recovery logic”].
As to claim 5, Oikarinen in view of Milligan & Rousseau teaches The method of claim 2, further comprising making available, by the recovery logic, second memory space associated with a fourth metadata table containing second erroneous keys in a fourth metadata table key range thereof [Rousseau -- According to one embodiment, the method comprises the steps consisting of: defining a virtual memory comprising logical pages having a logical address; defining, in the logical pages, logical blocks having a logical address; defining write commands and read commands of data in the logical blocks; defining, in the first memory zone, erasable physical pages having a physical address; defining, in the erasable physical pages, programmable physical blocks of the same size as the logical blocks and having a physical address; and defining, in the second memory zone, metadata structures associated with the physical blocks, comprising information about the status of each physical block from among the following statuses: block erased, block containing a valid data, or block containing an invalid data (¶ 0022); On the other hand, the program VPG implements the data write method with delayed erase both in the memory zone A1 and in the memory zone A2. Thus, maintenance tasks are equally provided in the memory zone A2 so as to free up memory space for the metadata by erasure of pages containing invalid metadata … The program VPG determines an optimum repartition between the memory space attributed to data and the memory space attributed to metadata, and thus determines the limits of each memory zone. The physical memory zone A1 is necessarily larger than the virtual memory zone due to the invalid data generated by the delayed-erase write method … (¶ 0069-0070)], wherein a second linked key of the second metadata table points to the fourth metadata table [Oikarinen – the corresponding “recovery logic” comprises “a linked-list structure” that connects all nodes sequentially -- FIGS. 6A-6C are diagrams of sequences for locating nodes, according to various embodiments. In one embodiment, the link between nodes 115a-115i or 115j-115z can be maintained by creating a linked list, in which node 115a points to node 115b, node 115b points to node 115c, etc. and vice versa (each node points to its next and previous node). In this embodiment, node requests originated from any server 113a-113k provide pointers towards other nodes. In another embodiment, each server 113a-113k maintains a list of nodes it has and whenever a node 115i is split into 115i and 115i-2, the newly generated node 115i-2 stores a reference (e.g., a link) to the remote server 113a-113k where it will be stored (¶ 0065-0066);
Milligan also teaches this limitation – as shown in figures 5 and 6; A system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies are provided. Virtual copies are created and managed through the use of an instant copy mechanism. Metadata subsets manage both the original data and the copies created by the instant copy mechanism. With an exemplary embodiment of the system and method, changes made to one copy of the data are cascaded to all child copies of the data. In this paradigm not only is the metadata entry for one particular copy changed, but also the corresponding metadata entries of any copies descended from that copy. In an exemplary method, a tree structure is used to maintain a record of all metadata table subsets created by use of an instant copy method. The tree structure can then be searched to find all child copies of a particular copy (abstract); The present invention provides a system and method for managing data updates by cascading those updates through a virtual copy hierarchy from parent copies to child copies. In an exemplary embodiment of the present invention, a data structure is maintained for keeping track of which copies of metadata are dependent from other copies of metadata, i.e. which copies are parent copies of metadata and which copies are child copies of metadata. This data structure is a tree data structure in which nodes of the tree are copies of metadata and arcs connect parent nodes to child nodes. The metadata may consist of offsets, pointers, bitmaps, timestamps, file sizes, and/or other information. The key feature for the purposes of the present invention is that the metadata can be used to derive the physical location on the storage device of its associated data. This may be a track, cylinder, or other unit of storage on a storage medium. The metadata may indicate the size or granularity of the physical unit of storage as well as the number of consecutive physical units of storage used to store the data (c2 L9-27); As an example of how to address this problem, the present invention provides a mechanism for keeping track of the hierarchy of virtual copies of data, i.e. metadata tables. In a preferred embodiment, this mechanism takes the form of a tree data structure. In an alternative embodiment, this mechanism may be using linked lists in which each metadata table subset created by an instant copy method may have a reference to a linked list of pointers to the start of any metadata table subsets created of a child copy … (c7 L63 to c8 L56); it is noted that the “tree data structure” and “linked lists” correspond to the “recovery logic”].
As to claim 10, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to "As to claim 2" presented earlier in this Office Action for details.
As to claim 11, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to "As to claim 3" presented earlier in this Office Action for details.
As to claim 13, it recites substantially the same limitations as in claim 5, and is rejected for the same reasons set forth in the analysis of claim 5. Refer to "As to claim 5" presented earlier in this Office Action for details.
As to claim 18, it recites substantially the same limitations as in claim 2, and is rejected for the same reasons set forth in the analysis of claim 2. Refer to "As to claim 2" presented earlier in this Office Action for details.
As to claim 19, it recites substantially the same limitations as in claim 3, and is rejected for the same reasons set forth in the analysis of claim 3. Refer to "As to claim 3" presented earlier in this Office Action for details.
Conclusion
7. Claims 1-20 are rejected as explained above.
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHENG JEN TSAI whose telephone number is 571-272-4244. The examiner can normally be reached on Monday-Friday, 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Reginald Bragdon can be reached on 571-272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/SHENG JEN TSAI/Primary Examiner, Art Unit 2139
Prosecution Insights