DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over KATHPAL et al (US 20180300203 A1) in view of CHO et al (US 20170262521 A1).
As to claims 1, 8, and 15, KATHPAL teaches A computer-implemented method for distributed (KATHPAL [0001] discloses a method to backup and restore (i.e. data processing for) a distributed database; [0063] and Figure 1C discloses the database and its replicas are organized within shards stored in clusters):
determining to-be-backed-up (KATHPAL [0083] and Figure 1F disclose a backup module determines data to be backed up, obtains and stores the backup related metadata (i.e. a backup identifier, for example, a backup name, and list of databases that are excluded from the backup, a database cluster name, identifiers that identify the shards, an identifier that identifies the database cluster nodes, etc.));
determining at least one target storage node in which the several (KATHPAL Figure 1F, [0082] and [0084] discloses in order to determine which data to be backed up and how to obtain it from the physical storage devices, the topology of the distributed database is determined, including the mapping (i.e. topology structure information) between shards and nodes and between nodes and LUNs (i.e. physical storage devices));
exporting the several (KATHPAL [0088] discloses the snapshots (i.e. selected data shards in the target storage node) are cloned and mounted at a recovery node (i.e. an intermediate storage device separate from the first and second cluster)); and
storing the (KATHPAL [0102]-[0106], Figure 1K disclose the performed backup is stored on the node(s) of a secondary cluster according to the topology of the secondary cluster (which might have a different number of nodes/shards)).
KATHPAL fails to teach a distributed graph database.
However, CHO teaches sharding and replicating graph databases across clusters, by using mappings between the respective clusters, shards, and physical nodes (CHO [0043]-[0048]).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of KATHPAL to incorporate the PARTITIONING AND REPLICATING DATA IN SCALABLE DISTRIBUTED DATA STORES as taught by CHO for the purpose of efficiently and quickly (e.g., optimally) store and retrieve data associated with the applications and the network without requiring the applications to have knowledge of a relational model implemented in graph database (CHO [0038]).
As to claims 2, 9, and 16, KATHPAL teaches the (KATHPAL [0028] and [0054] disclose the backup can be performed either from the primary replica or from the secondary replica of any shard/cluster).
KATHPAL fails to teach a distributed graph database.
However, CHO teaches sharding and replicating graph databases across clusters, by using mappings between the respective clusters, shards, and physical nodes (CHO [0043]-[0048]).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of KATHPAL to incorporate the PARTITIONING AND REPLICATING DATA IN SCALABLE DISTRIBUTED DATA STORES as taught by CHO for the purpose of efficiently and quickly (e.g., optimally) store and retrieve data associated with the applications and the network without requiring the applications to have knowledge of a relational model implemented in graph database (CHO [0038]).
As to claims 3, 10, and 17, KATHPAL teaches the at least one target storage node that is determined from the storage node in the first cluster and in which the several (KATHPAL Figure 1F, [0082] and [0084] discloses in order to determine which data to be backed up and how to obtain it from the physical storage devices, the topology of the distributed database is determined, including the mapping (i.e. topology structure information) between shards and nodes and between nodes and LUNs (i.e. physical storage devices). Selecting an intermediate storage device in close proximity to the “target storage node” (i.e. backup source) would have been obvious consideration for the skilled person to reduce network overload/losses.).
KATHPAL fails to teach a distributed graph database.
However, CHO teaches sharding and replicating graph databases across clusters, by using mappings between the respective clusters, shards, and physical nodes (CHO [0043]-[0048]).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of KATHPAL to incorporate the PARTITIONING AND REPLICATING DATA IN SCALABLE DISTRIBUTED DATA STORES as taught by CHO for the purpose of efficiently and quickly (e.g., optimally) store and retrieve data associated with the applications and the network without requiring the applications to have knowledge of a relational model implemented in graph database (CHO [0038]).
As to claims 4, 11, and 18, KATHPAL teaches determining the at least one target storage node in which the several (KATHPAL Figure 1F, [0082] and [0084] discloses in order to determine which data to be backed up and how to obtain it from the physical storage devices, the topology of the distributed database is determined, including the mapping (i.e. topology structure information) between shards and nodes and between nodes and LUNs (i.e. physical storage devices). Selecting an intermediate storage device in close proximity to the “target storage node” (i.e. backup source) would have been obvious consideration for the skilled person to reduce network overload/losses.).
KATHPAL fails to teach a distributed graph database.
However, CHO teaches sharding and replicating graph databases across clusters, by using mappings between the respective clusters, shards, and physical nodes (CHO [0043]-[0048]).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of KATHPAL to incorporate the PARTITIONING AND REPLICATING DATA IN SCALABLE DISTRIBUTED DATA STORES as taught by CHO for the purpose of efficiently and quickly (e.g., optimally) store and retrieve data associated with the applications and the network without requiring the applications to have knowledge of a relational model implemented in graph database (CHO [0038]).
As to claims 5, 12, and 19, KATHPAL teaches determining the at least one target storage node in which the several (KATHPAL Figure 1F, [0082] and [0084] discloses in order to determine which data to be backed up and how to obtain it from the physical storage devices, the topology of the distributed database is determined, including the mapping (i.e. topology structure information) between shards and nodes and between nodes and LUNs (i.e. physical storage devices). Selecting data based on a load status would have been obvious consideration for the skilled person to reduce network overload/losses.).
KATHPAL fails to teach a distributed graph database.
However, CHO teaches sharding and replicating graph databases across clusters, by using mappings between the respective clusters, shards, and physical nodes (CHO [0043]-[0048]).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of KATHPAL to incorporate the PARTITIONING AND REPLICATING DATA IN SCALABLE DISTRIBUTED DATA STORES as taught by CHO for the purpose of efficiently and quickly (e.g., optimally) store and retrieve data associated with the applications and the network without requiring the applications to have knowledge of a relational model implemented in graph database (CHO [0038]).
As to claims 6, 13, and 20, KATHPAL teaches a quantity of (KATHPAL [0102]-[0103] discloses the topology of the second cluster can be the same or different to the one of the first cluster. It is noted that while the claims are silent on any re-sharding operations being performed on the intermediate storage device after obtaining the entire of the sharded database content, such aspect was taken into account when assessing the merit of the present dependent claims.).
KATHPAL fails to teach a distributed graph database.
However, CHO teaches sharding and replicating graph databases across clusters, by using mappings between the respective clusters, shards, and physical nodes (CHO [0043]-[0048]).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of KATHPAL to incorporate the PARTITIONING AND REPLICATING DATA IN SCALABLE DISTRIBUTED DATA STORES as taught by CHO for the purpose of efficiently and quickly (e.g., optimally) store and retrieve data associated with the applications and the network without requiring the applications to have knowledge of a relational model implemented in graph database (CHO [0038]).
As to claims 7 and 14, KATHPAL teaches a quantity of (KATHPAL [0102]-[0103] discloses the topology of the second cluster can be the same or different to the one of the first cluster. It is noted that while the claims are silent on any re-sharding operations being performed on the intermediate storage device after obtaining the entire of the sharded database content, such aspect was taken into account when assessing the merit of the present dependent claims.).
KATHPAL fails to teach a distributed graph database.
However, CHO teaches sharding and replicating graph databases across clusters, by using mappings between the respective clusters, shards, and physical nodes (CHO [0043]-[0048]).
Before the effective filing date, it would have been obvious to one of ordinary skill in the art, to modify the teachings of KATHPAL to incorporate the PARTITIONING AND REPLICATING DATA IN SCALABLE DISTRIBUTED DATA STORES as taught by CHO for the purpose of efficiently and quickly (e.g., optimally) store and retrieve data associated with the applications and the network without requiring the applications to have knowledge of a relational model implemented in graph database (CHO [0038]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
YIN et al (US 20200250150 A1) - Systems and methods to process a topology change in a clustered database are described. The system communicates a query to a source storage platform enquiring of a topology change in a clustered database stored on the source storage platform. The system receives a message, at a control computer responsive to communicating the query. The message includes node identifiers identifying nodes including a first node identifier identifying a first node included in the clustered database. The system automatically identifies an addition of the first node to the clustered database on the source storage platform. The system initializes the first node on the source storage platform by communicating a first node agent to the first node. The first node agent is configured to execute on the first node to extract the data image at the source storage platform and stream the data image to the secondary storage platform.
LAZIER et al (US 20180365119 A1) - A data transfer device is used to augment the capabilities of a data storage system. The data transfer device may be capable of persistently storing data for an indeterminate amount of time, and may be configured to store a portion of a bundle of redundancy coded shards that span between the data transfer device and a data storage system configured to store the remainder of the bundle. Data stored on the data transfer device may be read from and written directly to the data transfer device without transfer of data to the data storage system. If the data transfer device is not available, the remaining shards of the bundle may provide a regenerated, original form of the data.
PANESSE et al (US 20150012666 A1) - A redundant array of independent nodes are networked together. Each node executes an instance of an application that provides object-based storage. The nodes are grouped into a plurality of systems each having multiple nodes. The systems have one or more replication links each being formed to indicate replication of data from one system to another system in a replicated environment where each system is configured as a sub-domain in a Domain Name System (DNS) infrastructure. A DNS alias synchronization method comprises maintaining updated information, within each system, of all replication links involving that system and of DNS aliases of other systems associated with all replication links involving that system (S602-S607). This enables that system to process network-based requests, on behalf of the other systems, without redirecting the requests from the other systems to that system.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JARED M BIBBEE whose telephone number is (571)270-1054. The examiner can normally be reached Monday-Thursday 8AM-6PM.
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, APU MOFIZ can be reached at 5712724080. 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.
/JARED M BIBBEE/Primary Examiner, Art Unit 2161
Prosecution Insights