DETAILED ACTION
This action is in response to the application filed on 06/20/2026. Claims 1 has been amended. Claims 1-7, 9,10 are pending examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-7,9,10 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.
A new reference Moser et al. (US 20050034014 A1) has been introduced to disclose integrating checkpointing and recovery code into existing source code, recompiling the modified program, and executing the resulting software on networked computers to provide fault-tolerant replication and recovery.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 1,6,7, 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Yucel et al. (US 20130238554 A1), hereinafter referred to as Yucel, in view of Moser et al. (US 20050034014 A1), hereinafter referred to as Moser.
As per claim 1, Yucel discloses an endogenous security protection method for configuration data in an operating system of a network node, performed by a white-box switch equipped with the network node operating system, comprising:
receiving a configuration command input by a user, and encapsulating the configuration command into a network message flow; (Restoring a cluster network environment and/or nodes therein, Yucel, para [0030]. For example, services may be shut down, nodes may be isolated, restoration may be performed, etc., Yucel, para [0004]. Here, an administrator or management component initiates action such as shutting down services, isolating nodes, restoring configurations, which are control/configuration operations often issued as commands over a management network or cluster control channel. Those management operations correspond broadly to configuration commands entered by a user and sent as messages within the cluster i.e., encapsulated into a network message flow).
backing up and parsing the network message flow to obtain target configuration data, and backing up the target configuration data; (It may be advantageous to improve disaster recovery and reliability by creating backups that may be used to restore the cluster network environment and/or nodes therein. In particular, cluster configuration data, which may be stored in a healthy node or at a remote source, may be used to restore a node affected by an integrity loss, Yucel, Abstract. Here, backups are created of cluster configuration data which are then used to restore nodes. Parsing message flow, for example, management protocols or replication messages to derive configuration is standard. Configuration data may be stored on a healthy node or remote source implies that it is extracted/stored from operational traffic or admin actions and then backed up as configuration data. This is analogous to backing up network message flow and backing up the target configuration)
storing the target configuration data in each of dynamic heterogeneous redundant executers of the network node operating system; (A cluster network environment comprising a plurality of nodes (e.g., one or more storage servers, one or more computing devices, etc.) may be used to facilitate the storage, retrieval, and/or processing of data. The nodes may cooperate together as a single coherent storage system (e.g., clustered storage environment and/or cluster of storage appliances), Yucel, para [0002]. The cluster configuration data may be restored using cluster backup data from a healthy node within the cluster network environment, Yucel, para [0005]. Here, a plurality of nodes in a cluster each with local configuration is described and also a cluster configuration that can be backed up on a healthy node. These nodes run their own OS and services and can be viewed as dynamic heterogenous redundant executers, heterogenous hardware or roles redundant via cluster. Storing cluster configuration data in a healthy node and in the affected node after restore corresponds to storing the same target configuration data in multiple executers of the network node OS).
However, Yucel does not explicitly disclose the limitations:
reading the target configuration data stored in the each of the dynamic heterogeneous redundant executers, and performing consistency judgment on the target configuration data stored in the each of the dynamic heterogeneous redundant executers to determine a judgment result;
determining the [[a]] target executer from the dynamic heterogeneous redundant executers according to the judgment result, taking offline the target executer and cleaning the target executer, and bringing online a candidate executer;
reading, by the brought-online candidate executer, the backed-up network message flow, to store the target configuration data parsed from the network message flow in the brought-online candidate executer; and
after the brought-online candidate executer stores the target configuration data, synchronizing the target configuration data stored in dynamic heterogeneous redundant executers in an online-state to the network node operating system, to cause the target configuration data take effect
wherein performing the consistency judgment comprises: in response to determining target configuration data stored in a target executer among the dynamic heterogeneous redundant executers being different from target configuration data stored in other dynamic heterogeneous redundant executers, determining the judgment result indicating that the target executer stores the target configuration data inconsistent with target configuration data stored by other dynamic heterogeneous redundant executers;
Moser discloses:
reading the target configuration data stored in the each of the dynamic heterogeneous redundant executers, and performing consistency judgment on the target configuration data stored in the each of the dynamic heterogeneous redundant executers to determine a judgment result; (A challenging aspect of replication is to maintain strong replica consistency, as methods are invoked on the replicas, states of the replicas change dynamically, and as faults occur. Strong replica consistency means that, for each method invocation or operation, for each data access within said method invocation or operation, the replicas obtain the same values for the data. Moreover, for each result, message sent, or request made to other processes, objects or components, the replicas generate the same result, message or request, Moser, para [0037]. Here, reading the target configuration data corresponds to each replica accessing the replicated shared or private state and performing consistency judgement corresponds to determining whether the replicas obtain the same data values and results. The judgement result corresponds to a determination of whether strong replica consistency exists)
determining the [[a]] target executer from the dynamic heterogeneous redundant executers according to the judgment result, taking offline the target executer and cleaning the target executer, and bringing online a candidate executer; (Fault-tolerant computer systems are based on entity redundancy (replication) to mask faults and, thus, to provide continuous service to their users. Distributed systems provide the opportunity for fault tolerance by allowing replicas of such entities to be hosted on different computers, Moser, para [0029]. A challenging aspect of replication is to maintain strong replica consistency, as methods are invoked on the replicas, states of the replicas change dynamically, and as faults occur. Strong replica consistent means that the replicas obtain the same values for the data, Moser, para [0037]. Here the target executer is interpreted to the faulty or recovering replica and the other executers are similar to the primary and remaining backup replicas. The configuration data is analogous to the replica state that does not have the same values as the state of other replicas. The determination that strong replica consistency is absent means there is an inconsistency judgement)
reading, by the brought-online candidate executer, the backed-up network message flow, to store the target configuration data parsed from the network message flow in the brought-online candidate executer; and (A backup replica does not process operations unless the primary replica fails, at which time the backup replica is promoted to become the new primary replica. Before operating as the new primary replica the backup replica establishes its state from the checkpoint, which was recorded by the primary replica before it failed, and then starts processing operations as the new primary replica, Moser, para [0036]. Here, the failed primary is the target executer and once it fails it no longer performs the active primary role and a backup is promoted. This serves as taking the target executer offline or removing it from active service)
after the brought-online candidate executer stores the target configuration data, synchronizing the target configuration data stored in dynamic heterogeneous redundant executers in an online-state to the network node operating system, to cause the target configuration data take effect (A new or recovering backup replica must obtain its initial state from a checkpoint. Once it has obtained that initial state from a checkpoint, it can itself process operations. For semi-active replication, a new or recovering backup replica obtains checkpoints for the threads, relative to the order in which the threads claim and release mutexes, in order to achieve consistency of the state of the backup replica with that of the primary replica that was checkpointed, Moser, para [0108])
wherein performing the consistency judgment comprises: in response to determining target configuration data stored in a target executer among the dynamic heterogeneous redundant executers being different from target configuration data stored in other dynamic heterogeneous redundant executers, determining the judgment result indicating that the target executer stores the target configuration data inconsistent with target configuration data stored by other dynamic heterogeneous redundant executers; (For semi-active replication, a new or recovering backup replica obtains checkpoints for the threads, relative to the order in which the threads claim and release mutexes, in order to achieve consistency of the state of the backup replica with that of the primary replica that was checkpointed, Moser, para [0108]. The primary replica acts as the leader, which makes decisions about the order in which messages are processed, mutexes are granted and so forth, and communicates those decisions to the backup replicas, which follow the decisions of the leader, Moser, para [0130]. The CMT library contains wrapper functions for the functions of the operating system thread library that claim and release mutexes, semaphores, condition variables and so forth, and is interposed ahead of the operating system thread library. The application program invokes the claim( ) and releases( ) functions, it actually invokes the claim( ) and releases( ) wrapper functions of the CMT library, which in turn invoke the corresponding functions of the operating system thread library. Once the new or recovering backup replica has obtained that initial state from a checkpoint, it can itself process operations, Moser, para [0058]. Here, the restored state is used by executing components that interact with the operating system thread library. Once restoration is completed, the replica begins processing operations using that restored state. Thus, the restored data becomes operational or takes effect).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Yucel with Moser by cluster configuration backup and recovery (Yucel) with consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication (Moser). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Yucel with Moser in order to improve reliability through integrated fault tolerant recovery (See Moser, para [0058])
As per claim 6, Yucel and Moser disclose the method according to claim 1, further comprising:
Furthermore, Moser discloses:
integrating a specified source code into a source code of an open networking operating system of the white-box switch in advance, compiling the integrated source code to obtain an image container, installing the image container in the white-box switch, and after the white-box switch is powered on and started, running an extension container corresponding to the image container in the network node operating system where the white-box switch is running; or,
publishing a developed extension container as an image container, and after the white-box switch is powered on and started, loading the image container into the network node operating system of the white-box switch (Each executing object consists of one or more threads. Program code, inserted into the code of the self-checkpointing thread, checks the value of the restoring checkpoint flag and uses the checkpoint structure to restore the current position of the flow of control, including the names of nested method invocations and their parameters and local variables, and to start the thread executing, Moser, para [0144]. Code inserted into the self-checkpointing thread ensures that the thread does not repeat all of the processing that the thread already performed but, rather, restores values of variables from the checkpoint structure and resumes normal processing at the point at which the checkpoint was taken, Moser, para [0218]. Here, the modified application object executes at runtime through one or more threads. The executing modified object corresponds broadly to the running extension container. The inserted extension code is executed during startup or restoration and starts the associated thread executing which is similar to runtime activation of the integrated extension software after the host computer has started).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Yucel with Moser by cluster configuration backup and recovery (Yucel) with consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication (Moser). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Yucel with Moser in order to improve reliability through integrated fault tolerant recovery (See Moser, para [0058])
As per claim 7, Yucel and Moser disclose the method according to claim 1, wherein
Furthermore, Yucel discloses:
the candidate executer is preset with an online protection period; (Restoration may be performed, Yucel, para [0005]. This restoration phase is where nodes are isolated and integrity is re-established before they rejoin the cluster. This phase is analogous to an online protection period for a candidate executer during which checks are applied before it is fully trusted).
after reading, by the brought-online candidate executer, the backed-up network message flow, to store the target configuration data parsed from the network message flow in the brought-online candidate executer, the method further comprises: determining, for each non-offline dynamic heterogeneous redundant executer, whether the target configuration data stored in the non-offline dynamic heterogeneous redundant executer is consistent with the target configuration data stored in the candidate executer within the online protection period, wherein the non-offline dynamic heterogeneous redundant executer is not within the online protection period; and (Cluster configuration data may be stored in a healthy node or at a remote source may be used to restore a node affected. Creating a new cluster network environment based on a healthy node within the cluster network environment and for respective nodes affected by the integrity loss reviving an affected node as a restored node, Yucel, para [0005]- [0006]. Here, the healthy nodes and affected/ restored nodes are distinguished and healthy nodes configuration is used as an authoritative baseline. Checking whether restores nodes configuration matches that of healthy nodes during a restore phase corresponds to determining within an online protection period whether configuration data across redundant executers is consistent)
when the target configuration data stored in the non-offline dynamic heterogeneous redundant executer is inconsistent with the target configuration data stored in the candidate executer within the online protection period, taking the non-offline dynamic heterogeneous redundant executer offline (Services may be shut down, nodes may be isolated, restoration may be performed, Yucel, para [0004]. When configuration or integrity problems are detected, nodes may be isolated and services are shut down. This aligns with taking a non-off line executer offline when its configuration is inconsistent with the candidate executer during the protection period).
As per claim 9, Yucel and Moser disclose a non-transitory computer-readable storage medium,
Furthermore, Yucel discloses:
storing a computer program, wherein when the computer program is executed by a processor, the method according to claim 1 is implemented (Data storage device 234 can comprise mass storage devices, Yucel, para [0043]).
As per claim 10, Yucel and Moser disclose an electronic device, comprising a memory,
Furthermore, Yucel discloses:
a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the method according to claim 1 (Processors 204, a memory 206, Yucel, para [0044])
Claims 2-4 are rejected under 35 U.S.C. 103 as being unpatentable over Yucel et al. (US 20130238554 A1), hereinafter referred to as Yucel, in view of Moser et al. (US 20050034014 A1), hereinafter referred to as Moser in further view of Kurupati et al. (US 20030182291 A1), hereinafter referred to as Kurupati
As per claim 2, Yucel and Moser disclose the method according to claim 1, wherein backing up and parsing the network message flow to obtain the target configuration data, and backing up the target configuration data comprises:
parsing the network message flow to obtain the target configuration data, taking the target configuration data as to-be-stored data, and determining a key for the to-be-stored data; (Cluster configuration data may be stored in a healthy node or at a remote source and may be used to restore a node affected, Yucel, para [0005]. Here, cluster configuration data that must be extracted from the running environment and backups and then stored/used for restore, is disclosed. This corresponds to parsing network or cluster messages to obtain configuration, treating that as to-be-stored data and associating it with keys such as node IDs, resource IDs, for lookup)
However, Yucel in view of Moser does not explicitly disclose the limitation:
creating and/or opening a database corresponding to a specified identifier, wherein the database corresponding to the specified identifier comprises:
a hashlist describer table, an index memory, an index memory identifier, a data memory, and a data memory identifier;
determining a hash value for the key of the to-be-stored data;
searching, according to the hash value of the key of the to-be-stored data, a hashlist describer table of the database corresponding to the specified identifier, to obtain a hashlist describer corresponding to the key of the to-be-stored data, and determining, according to the hashlist describer corresponding to the key of the to-be-stored data, a target hashlist corresponding to the key of the to-be-stored data, wherein the target hashlist comprises index information for a plurality pieces of stored data; and
determining, according to the index information, whether the database corresponding to the specified identifier comprises the key of the to-be-stored data; and
searching, according to the hash value of the key of the to-be-stored data, a hashlist describer table of the database corresponding to the specified identifier, to obtain a hashlist describer corresponding to the key of the to-be-stored data, and determining, according to the hashlist describer corresponding to the key of the to-be-stored data, a target hashlist corresponding to the key of the to-be-stored data, wherein the target hashlist comprises index information for a plurality pieces of stored data; and
determining, according to the index information, whether the database corresponding to the specified identifier comprises the key of the to-be-stored data; and
when the database corresponding to the specified identifier does not comprise the key of the to-be-stored data, performing a data-adding action, wherein the data-adding action comprises updating the hashlist describer table, updating the index information in the index memory, and adding a value of the to-be-stored data in the data memory;
when the database corresponding to the specified identifier comprises the key of the to-be-stored data, performing a data-updating action, wherein the data-updating action at least comprises deleting the index information of original data in the index memory, deleting data information of the data memory, and updating the hashlist describer table
Kurupati discloses:
creating and/or opening a database corresponding to a specified identifier, wherein the database corresponding to the specified identifier comprises: (The data structure includes an index table for storing plurality of entries, each of the entries corresponding to one of a plurality of hash values, with each entry including a section pointer to identify a memory address of one of a plurality of sections of a key database and including valid bits to indicate a size of the respective section of the key database. The key database stores a plurality of data entries, Kurupati, Abstract, para [0023])
a hashlist describer table, an index memory, an index memory identifier, a data memory, and a data memory identifier; (Index table 530, key database 560 connected by pointers that identify locations and sizes, Kurupati, para [0020]. Here, a database-like structure is disclosed which composes of an index table and a key database (data memory), connected by pointers that identify locations and sizes. The index table corresponds to the hashlist describer table +index memory and the key database corresponds to data memory, section pointers and valid bits act as identifiers for portions of index and data memory which align with index memory identifier and data memory identifier).
determining a hash value for the key of the to-be-stored data; (Storing a number of data entries in a first section of a key database, the first section allocated to one of a plurality of entries of an index table responsive to a hash function applied, Kurupati, claim 53. Here, a hash function is applied to a key to determine where to place entries in an index table which analogous to determining a hash value for the key of the to-be stored data).
searching, according to the hash value of the key of the to-be-stored data, a hashlist describer table of the database corresponding to the specified identifier, to obtain a hashlist describer corresponding to the key of the to-be-stored data, and determining, according to the hashlist describer corresponding to the key of the to-be-stored data, a target hashlist corresponding to the key of the to-be-stored data, wherein the target hashlist comprises index information for a plurality pieces of stored data; and (The data structure includes an index table, each of the entries corresponding to one of a plurality of hash values with each entry including a section pointer to identify a memory address of one of a plurality of sections of a key database, Kurupati, claim 33. Here, a hash value selects an entry in the index table, which via a pointer identifies a section of the key database containing multiple entries with that hash. That entry is a hashlist describer and the section is a target hashlist comprising index information for multiple stored data items).
determining, according to the index information, whether the database corresponding to the specified identifier comprises the key of the to-be-stored data; and (Storing a number of data entries in a first section of a key database, the first section allocated to one of a plurality of entries of an index table responsive to a hash function applied to the key, Kurupati, claim 56. Once a section is identified by hash, the structure must check individual entries to see whether a matching key exists there which means it determines whether the database already stores that key. This is analogous to determining whether the database comprises the key)
when the database corresponding to the specified identifier does not comprise the key of the to-be-stored data, performing a data-adding action, wherein the data-adding action comprises updating the hashlist describer table, updating the index information in the index memory, and adding a value of the to-be-stored data in the data memory; (The number of valid bits set high to indicate a size of the allocated section, Kurupati, para [0024]. Here, inserting new key/value entries into a hash- indexed database, which requires updating the index or descriptor entry for the hash and writing the new value into the data store, is analogous to a data-adding action)
when the database corresponding to the specified identifier comprises the key of the to-be-stored data, performing a data-updating action, wherein the data-updating action at least comprises deleting the index information of original data in the index memory, deleting data information of the data memory, and updating the hashlist describer table (A low overhead data structure providing efficient search and data insertion capabilities. The key database including a number of sizes of section, a first free section of each of the sizes identified by a head pointer register, each of the sections to store at least one data entry. An index table including a number of entries, each entry including a number of valid bits to indicate allocation of one of the sections of the key database and a section pointer to identify a memory address of the allocated section, Kurupati, para [0029]. Before inserting, the system checks the section for existing entries with the same key, if found, the operation is an update rather than a pure insert, which is a "database comprises the key" condition. The index table identifies where each section lives and how big it is. When an existing record is updated or removed, its index-related information (pointer/offset, count, valid bits) must be changed. This is essentially deleting the old index information for that data and replacing it with new information. The old value for that key resides in a data entry in the key database, updating the data means that value is either overwritten or removed and a new value is stored in its place or in a new section. This is naturally deleting the original data information in data memory. When an entry is removed or relocated, the index entry describing the section must be updated such as size field via valid bits, pointer to section or whether the section remains allocated, which is analogous to updating the hashlist describer table).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Yucel with Moser by cluster configuration backup and recovery (Yucel) and consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication (Moser) with a data
structure for a low memory overhead database (Kurupati). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Yucel and Moser with Kurupati in order to effectively search a key database via an index table (See Kurupati, para [0029])
As per claim 3, Yucel and Moser disclose the method according to claim 2, wherein determining, according to the index information, whether the database corresponding to the specified identifier comprises the key of the to-be-stored data comprises:
However, Yucel in view of Moser does not explicitly disclose the limitations:
determining a location of a first item of the target hashlist in the index memory according to the hashlist describer corresponding to the key of the to-be-stored data;
wherein the target hashlist comprises index information for a plurality pieces of stored data, and the index information comprises a location of a next piece of stored data of each piece of stored data in the target hashlist in the index memory, a length of a value of each piece of stored data, a location of the value of each piece of stored data in the data memory, a length of a key of each piece of stored data, and content of the key of each piece of stored data;
traversing the index information of each piece of stored data comprised in the target hashlist, for the index information of each piece of stored data in the target hashlist, comparing content of a key of the piece of stored data in the index information of the piece of stored data with content of the key of the to-be-stored data; and
when the index information of the plurality pieces of stored data comprised in the target hashlist comprises a key of stored data having same content with the key of the to- be-stored data, determining the database corresponding to the specified identifier comprises the key of the to-be-stored data;
when the index information of the plurality pieces of stored data comprised in the target hashlist does not comprise a key of stored data having same content with the key of the to-be-stored data, determining the database corresponding to the specified identifier does not comprise the key of the to-be-stored data
Kurupati discloses:
determining a location of a first item of the target hashlist in the index memory according to the hashlist describer corresponding to the key of the to-be-stored data; (When a first free section 570 is allocated to receive an entry (or entries) 580, the address in the corresponding head pointer register 590 is copied over to the appropriate section pointer 542 in the index table 530, Kurupati, para [0029]. Here, the index entry's section pointer is used to get the start address of the bucket/section).
wherein the target hashlist comprises index information for a plurality pieces of stored data, and the index information comprises a location of a next piece of stored data of each piece of stored data in the target hashlist in the index memory, a length of a value of each piece of stored data, a location of the value of each piece of stored data in the data memory, a length of a key of each piece of stored data, and content of the key of each piece of stored data; (Each section 570 of key database 560 is capable of storing one or more entries 580, each size 1 section 570a may store one entry, Kurupati, para [0026]. This relies on how each data entry in the section actually stores key and value (content and length), plus the structure's knowledge of section size and layout)
traversing the index information of each piece of stored data comprised in the target hashlist, for the index information of each piece of stored data in the target hashlist, comparing content of a key of the piece of stored data in the index information of the piece of stored data with content of the key of the to-be-stored data; and (Referring to block 620, the entry 540 in the index table 530 corresponding to the n-bit hash value is accessed. For example, if the n-bit hash value equals the number 43, the 43.sup.rd entry of the index table 530 is the corresponding entry, Kurupati, para [0033]. This is the per-entry scan through the section after selecting it by hash)
when the index information of the plurality pieces of stored data comprised in the target hashlist comprises a key of stored data having same content with the key of the to- be-stored data, determining the database corresponding to the specified identifier comprises the key of the to-be-stored data; (In block 645, if one of the entries 580 includes a key 582 that matches the search key, the look-up succeeded. As illustrated at block 650, the rule 584 associated with the matching key 582 may then be accessed and, as shown at block 655, that rule 584 may be applied to the received packet from which the search key was generated, Kurupati, para [0036]. This is the result of the scan, if an entry's key matches, the database comprises the key, if none do, it does not)
when the index information of the plurality pieces of stored data comprised in the target hashlist does not comprise a key of stored data having same content with the key of the to-be-stored data, determining the database corresponding to the specified identifier does not comprise the key of the to-be-stored data (In block 645, if no entry 580 in the allocated section 570 includes a key 582 that matches the search key, the look-up has failed (see block 690), Kurupati, para [0035]. This is the result of the scan, if an entry's key matches, the database comprises the key, if none do, it does not)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Yucel with Moser by cluster configuration backup and recovery (Yucel) and consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication (Moser) with a data
structure for a low memory overhead database (Kurupati). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Yucel and Moser with Kurupati in order to effectively search a key database via an index table (See Kurupati, para [0029])
As per claim 4, Yucel and Moser disclose the method according to claim 2, wherein performing the data-adding action comprises:
However, Yucel in view of Moser does not explicitly disclose the limitations:
determining, according to the hashlist describer corresponding to the key of the to- be-stored data, a target location of a first item of the target hashlist corresponding to the key of the to-be-stored data in the index memory;
creating a specified index information hashlist item, and inserting the specified index information hashlist item before the first item of the target hashlist;
obtaining a location of the value of the to-be-stored data in the data memory according to the data memory identifier;
updating a length of the value of the to-be-stored data, a position of the value of the to-be-stored data in the data memory, a length of the key of the to-be-stored data, and content of the key of the to-be-stored data into the specified index information hashlist item; locating an end position of the index memory according to the index memory identifier, writing the value of the to-be-stored data into the end position of the index memory, and updating a value of the data memory identifier
Kurupati discloses:
determining, according to the hashlist describer corresponding to the key of the to- be-stored data, a target location of a first item of the target hashlist corresponding to the key of the to-be-stored data in the index memory; (Each of the plurality of entries including a valid bit to indicate allocation of one of the sections of the first data structure and a section pointer to identify a memory address of the allocated section, Kurupati, claim 1. Here, it is uses index entry (section pointer) to identify the memory address of the section (first item). The section pointer identifies where the first item for that hash resides).
creating a specified index information hashlist item, and inserting the specified index information hashlist item before the first item of the target hashlist; (A number of head pointer registers, the number of head pointer registers equal to the number of sizes, each of the number of head pointer registers to identify a first free section of one of the sizes of sections, Kurupati, claim 33. This allows allocation of new sections and linking them, creating a new data entry and potentially placing it at the start of a section/bucket is equivalent to inserting a new hashlist item before the first item in a list -based implementation)
obtaining a location of the value of the to-be-stored data in the data memory according to the data memory identifier; (The section pointer 542 will identify a section 570 in key database 560 that is currently allocated to the corresponding entry 540 of index table 530, and that allocated section 570 is accessed, Kurupati, para [0034]. The section pointer and index entries identify memory addresses in the key database (data memory). The pointer or value used to access a section or intra-section offset is a data memory identifier, using it to obtain the location for the value).
updating a length of the value of the to-be-stored data, a position of the value of the to-be-stored data in the data memory, a length of the key of the to-be-stored data, and content of the key of the to-be-stored data into the specified index information hashlist item; locating an end position of the index memory according to the index memory identifier, writing the value of the to-be-stored data into the end position of the index memory, and updating a value of the data memory identifier (The number r of valid bits 544 set high, if any, indicates the size of the section 570 in key database 560. The key database stores a plurality of data entries with each data entry including a search key, Kurupati, para [0038]. Here, the entries and metadata store size and position information and contain the key. Representing these fields explicitly as part of the index information hashlist is analogous to index and data organization)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Yucel with Moser by cluster configuration backup and recovery (Yucel) and consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication (Moser) with a data
structure for a low memory overhead database (Kurupati). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Yucel and Moser with Kurupati in order to effectively search a key database via an index table (See Kurupati, para [0029])
Claims 5 are rejected under 35 U.S.C. 103 as being unpatentable over Yucel et al. (US 20130238554 A1), hereinafter referred to as Yucel, in view of Moser et al. (US 20050083833 A1) hereinafter referred to as Moser in further view of Kurupati et al. (US 20030182291 A1), hereinafter referred to as Kurupati in further view of Yamashita et al. (US 20010051954 A1), hereinafter referred to as Yamashita
As per claim 5, Yucel, Moser and Kurupati disclose the method according to claim 2, wherein performing the data- updating action comprises:
However, Yucel in view of Moser in further view of Kurupati does not disclose:
taking stored data corresponding to a key of the stored data same as the key of
the to-be-stored data in the database corresponding to the specified identifier as to-be-deleted data;
obtaining index information of the to-be-deleted data, determining a location of the index information of the to-be-deleted data in the target hashlist, and determining, according to the location of the index information of the to-be-deleted data in the target hashlist, whether the index information of the to-be-deleted data is located in a first item of the target hashlist;
when the index information of the to-be-deleted data is located in the first item of the target hashlist, updating index information of a next piece of stored data of the index information of the to-be-deleted data in the target hashlist into the hashlist describer table;
when the index information of the to-be-deleted data is located in a non-first item of the target hashlist, removing the index information of the to-be-deleted data from the target hashlist; traversing the hashlist describer table, and updating describer information in the hashlist describer table to new describer information after data deletion;
traversing each hashlist table, and updating location information of a next item of each item in the hashlist table in the index memory to new location information after data deletion; locating a deletion start node and a deletion end node of the index memory and the data memory respectively;
creating a temporary memory buffer, wherein the temporary memory buffer is configured to store original data in the index memory and the data memory respectively, and writing data, from which corresponding segments are deleted, back to the index memory and the data memory of the database respectively based on the deletion start node and the deletion end node.
Yamashita discloses:
taking stored data corresponding to a key of the stored data same as the key of the to-be-stored data in the database corresponding to the specified identifier as to-be-deleted data; (A storage medium which stores one or more files including the file to be updated, each of which includes a plurality of pieces of data and one or more pieces of index information which correspond to the one or more files and associate a file name with a storage location of a predetermined piece of data of a file, Yamashita, para [0040]. When the file is to be updated, that file is taken as the file to be updated that is the to-be deleted data which means that old content that will be replaced. The piece of index information corresponding to the file is analogous to the index information of the to-be-deleted data that is obtained to know where the existing data is located).
obtaining index information of the to-be-deleted data, determining a location of the index information of the to-be-deleted data in the target hashlist, and determining, according to the location of the index information of the to-be-deleted data in the target hashlist, whether the index information of the to-be-deleted data is located in a first item of the target hashlist; (A first table and a second table which both indicate a storage location of each piece of data and a sequence of the plurality of pieces of data of each file. The index information associates a file name with a storage location of a predetermined piece of data of a file, Yamashita, para [0040]. For a given file (key), the index information points to a predetermined piece of data and the first or second tables define the sequence of pieces. This chain is analogous to the target hashlist and each FAT entry is an item in the list)
when the index information of the to-be-deleted data is located in the first item of
the target hashlist, updating index information of a next piece of stored data of the index information of the to-be-deleted data in the target hashlist into the hashlist describer table; (Address information which shows a storage location of the corresponding piece of index information and new contents to which the corresponding piece of index information is to be updated, Yamashita, para [0040])
when the index information of the to-be-deleted data is located in a non-first item of the target hashlist, removing the index information of the to-be-deleted data from the target hashlist; traversing the hashlist describer table, and updating describer information in the hashlist describer table to new describer information after data deletion; (A unit for deleting the index identifying information from the storage medium after the second table is updated, Yamashita, para [0040])
traversing each hashlist table, and updating location information of a next item of each item in the hashlist table in the index memory to new location information after data deletion; (A first table and a second table which both indicate a storage location of each piece of data and a sequence of the plurality of pieces of data of each file, and (c) one or more pieces of index information which are in a one-to-one correspondence with the one or more files and each associate a file name with a storage location of a predetermined piece of data of a file, Yamashita, para [0050])
locating a deletion start node and a deletion end node of the index memory and the data memory respectively; (The data updating apparatus 1000 is roughly made up of a storage medium 1001, a CPU (Central Processing Unit) 1002, and a RAM (Random Access Memory) 1003, each of which is connected by a bus. The CPU 1002 controls reading/writing of data from/into the storage medium 1001, and the RAM 1003 temporarily stores the data written or read by the CPU 1002, means for writing and generating temporary information into the storage medium, Yamashita, para [0008])
creating a temporary memory buffer, wherein the temporary memory buffer is
configured to store original data in the index memory and the data memory respectively, and writing data, from which corresponding segments are deleted, back to the index memory and the data memory of the database respectively based on the deletion start node and the deletion end node (A temporary index generating unit 107, a temporary index deleting unit 108, a data updating unit 109, and a restoration processing control unit 110, Yamashita, para [0074]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Yucel and Gettala by cluster configuration backup and recovery (Yucel) and consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication (Moser) and a data structure for a low memory overhead database (Kurupati) with restoration process (Yamashita). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Yucel, Moser, Kurupati with Yamashita in order to effectively maintain consistency in file management and actual storage devices (See Yamashita, para [0002]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAGHAVENDER CHOLLETI whose telephone number is (703) 756-1065. The examiner can normally be reached M-F 9am-5pm ET.
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, RUPAL DHARIA can be reached on (571) 272-3880. 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.
Respectfully submitted,
/RAGHAVENDER NMN CHOLLETI/Examiner, Art Unit 2492
/RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights