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 .
This action is in response to Amendment filed 09/09/2025.
Claims 1, 11 and 21 have been amended, and no claim has been canceled or added. Currently, claims 1-30 are pending.
Response to Arguments
Applicant's arguments filed 09/09/2025 have been fully considered but they are not persuasive.
Regarding Applicant’s argument (see Remarks, pages 9-11) with respect to the Rejection of Claims Under §101 that amended claim is not directed to a judicial exception, the claims are integrated into a practical application, the claims recite significantly more than a judicial exception, the examiner’s mental process characterization is inapplicable, and other additional arguments based on improved computer functionality disclosed in the Specification, Examiner respectfully disagrees.
Regarding the amended claim 1 and similarly applied to independent claims 11 and 21, the recited limitation “an object-storage service” as broadly recited can be broadly interpreted as a storage device or a storage system. Any device/system providing storage functionality can be interpreted as an object-storage service as recited. The step/limitation of storing table data for a database in a plurality of partitions residing in an object-storage service recited at a high level of generality is directed to a generic computer function of storing data in different regions (i.e., partitions) of a storage device or in different storage devices (i.e., partitions) of a computer/storage system, which is insignificant extra-solution activity or well-understood, routine, conventional activity for implementing the abstract idea or mental processes of generating a change tracking entry, generating a change tracking stream (i.e., a collection of changes), and updating a second table version to include the change tracking stream. It should be noted that “a partition” is broadly interpreted as a portion or a part, and “a partition file” being not defined/disclosed in the Specification can be broadly interpreted as a collection/set/stream of data, which does not further specify the feature “change tracking stream” (i.e., a collection of changes/modifications). Similarly, limitation “lineage of executed transaction” is a lineage/sequence of changes/modification, which also does not further specified the feature “change tracking stream”.
As discussed, the amended claim 1 as currently presented is not effective to overcome the 101 rejection for being directed to abstract idea without significantly more because it broadly recites a concept and/or abstract idea of generating a change tracking entry, generating a change tracking stream, and updating a second data version to include the change tracking stream. The claimed invention as broadly recited fails to realize a practical application and/or improved functionality/technology as disclosed in the Specification as stated (e.g., there is no recitation of how to use immutable partitions and partition files in object-storage service as indicated, how “a first table version” and “a second table version” are related/different to in view of “partitions”, etc.).
Regarding Applicant’s arguments (see Remarks, page 11) with respect to the Rejection of Claims Under §103, in reference to the “storing functionality, that neither Vig nor Bhatnagar teaches or suggests that the partitions reside in an “object-storage service”, and/or storing database partitions as objects in an object-storage service, Examiner respectfully disagrees.
It should be noted that the term “object-storage service” as broadly recited can be broadly interpreted as equivalent to any storage device/system. The recitation of “storing…table data for a database in a plurality of partitions residing in an object-storage service” is not necessary interpreted as storing database partitions as objects in an object-storage service as stated. Vig et al. recited a system including a plurality of storage nodes which are allocated for storing partitions of a table (see [column 5, line 53 to column 6, line , wherein the system including a plurality of storage nodes can be interpreted as equivalent to an object-storage service as broadly recited, wherein each storage node can be interpreted as a partition residing in the object-storage service as recited.
Regarding Applicant’s arguments (see Remarks, pages 11-12) with respect to the Rejection of Claims Under §103, in reference to the “generating” functionality, that neither Vig nor Bhatnagar teaches or suggests generating a change tracking stream as a partition file, Examiner respectfully disagrees.
The term “partition file” being not defined in the Specification can be interpreted as just a file or any unit of data stored in the system. Vig et al. teaches a journal storing a set of changes/writes/transactions performed on a table (see [column 6, lines 20-30]), wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or a partition file as recited.
Regarding Applicant’s arguments (see Remarks, pages 11-12) with respect to the Rejection of Claims Under §103, in reference to the “updating” functionality, that neither Vig nor Bhatnagar teaches or suggests the specific mechanism of updating a table version by atomically referencing a new set of immutable partition objects and a partitional file in an object-storage service, Examiner respectfully disagrees.
The arguments appear to be invalid since the claimed invention does not recited any relation between a table version and a new set of immutable partition objects and a partition file in an object storage service as stated. Vig et al. teaches a journal storing a set of changes/writes/transactions performed on a table (see [column 6, lines 20-30]), wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or lineage of executed transactions as recited. It should be noted that when a change occurred in a table, table data changed from a first version to a second version, wherein table data associated with the first version is interpreted as a first table version, and table data associated with the second version is interpreted as a second table version. In addition, the journal can be seen as metadata associated with the table or metadata/data of the table.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-30 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 1, the term “partition file” in line 11 being not disclosed or mentioned in the Specification raises new matter issue.
Regarding claim 11, the term “partition file” in line 12 being not disclosed or mentioned in the Specification raises new matter issue.
Regarding claim 21, the term “partition file” in line 11 being not disclosed or mentioned in the Specification raises new matter issue.
Other dependent claims are rejected as incorporating and failing to resolve the deficiency of the rejected independent claims 1, 11 and 21 upon which they depend correspondingly.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of analyzing data without significantly more.
The claims recite abstract idea(s) of generating a change tracking entry, generating a change tracking stream and updating a second table version to include the change tracking stream, which are broadly recited steps/concepts that can be mentally performed in the human mind and/or with the aid of pencil and paper and directed to mental processes grouping of abstract ideas . This judicial exception is not integrated into a practical application because other additional elements including generic computer, genetic computer components and common computer functionality (e.g., accessing, storing, displaying, etc.) and/or insignificant extra-solution activity (e.g., mere data gathering) for implementing the abstract idea are not sufficient to integrate the abstract idea into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because additional elements include only generic/common computer components (e.g., memory, processor, program instructions, etc.) and generic/common computer functions (e.g., accessing, storing, displaying, etc.) and/or insignificant extra-solution activity (e.g., mere data gathering), which are not sufficient to amount to significantly more than the recited abstract idea.
Abstract idea analysis as follows:
Step 1:
According to the first part of the analysis, in the instant claims, claims 1-10 are directed to a method (i.e. a process), claims 11-20 are directed to a system comprising one or more processors (i.e., a machine), and claims 21-30 are directed to a non-transitory computer-storage medium storing instructions (i.e., article of manufacture). Thus, each of the claims falls within one of the four statutory categories (i.e. process, machine, manufacture, or composition of matter).
Step 2a Prong 1 (claims 1, 11 and 21):
The following limitations recited in claims 1, 11, and 21 are abstract ideas that fall under mental processes:
generating,…, a change tracking entry based on executing a transaction on the table data, the change tracking entry including information on at least one modification made to a first table version storing the table data (the step of generating a change tracking entry as broadly recited can be mentally performed by the human mind or with the aid of pencil and paper),
generating, …, a change tracking stream as a partition file associated with the at least one modification (the step of generating a change tracking stream as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper; it should be noted that the limitation contains “a change tracking stream” based on the specification, [0018]), the stream is no more than a collection of changes),
updating,…, a second table version to include the change tracking stream, the second table version including modified table data based on completing execution of the transaction on the table data in the first table version, the change tracking stream including lineage of executed transactions on the table data, the lineage comprising metadata columns indicating an action type and update status for the at least one modification made to the first table version (the step of updating as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper).
All the limitations above are mental steps that can be performed in the human mind or with the aid of pencil and paper.
Step 2a Prong 2 (Claims 1, 11, and 21):
The following limitations in claims 1, 11 and 21 are additional elements:
performed by at least one hardware processor configured as a change tracking manager in a database system functions comprising (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea),
storing, by a table data component of the change tracking manager, table data for a database in a plurality of partitions residing in an object-storage service (this step of storing as broadly recited is directed to generic computer function or insignificant extra-solution activity),
by a transaction data component of the change tracking manager (wherein “a transaction data component” or “the change tracking manager” recited at high level of generality are directed to no more than mere instructions for implementing or applying the abstract idea (i.e., the mental step of generating a change tracking entry)),
by a change tracking component of the change tracking manager (wherein “a change tracking component” or “the change tracking manager” recited at high level of generality are directed to no more than mere instructions for implementing or applying the abstract idea (i.e., the mental step of generating a change tracking stream)),
by the change tracking component (wherein “a change tracking component” recited at high level of generality is directed to no more than mere instructions for implementing or applying the abstract idea (i.e., the mental step of updating a second table version to include the change tracking stream)),
one or more processors configured as a change tracking manager (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea),
data storage containing instructions executable by the one or more processor to perform operations comprising (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea),
a non-transitory computer-storage medium storing instructions that, when executed by one or more processor configured as a change tracking manager, cause the one or more processors to perform operations comprising (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea).
These are a generic computer and/or generic computer components used to perform generic computer functions or insignificant extra-solution activity, such that they amount to no more than components used to execute mere instructions for implementing or applying the abstract idea. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract idea(s).
Step 2b (Claims 1, 11 and 21):
The following limitations in claims 1, 11 and 21 are additional elements:
performed by at least one hardware processor configured as a change tracking manager in a database system functions comprising (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea),
storing, by a table data component of the change tracking manager, table data for a database in a plurality of partitions residing in an object-storage service (this step of storing as broadly recited is directed to generic computer function or insignificant extra-solution activity),
by a transaction data component of the change tracking manager (wherein “a transaction data component” or “the change tracking manager” recited at high level of generality are directed to no more than mere instructions for implementing or applying the abstract idea (i.e., the mental step of generating a change tracking entry)),
by a change tracking component of the change tracking manager (wherein “a change tracking component” or “the change tracking manager” recited at high level of generality are directed to no more than mere instructions for implementing or applying the abstract idea (i.e., the mental step of generating a change tracking stream)),
by the change tracking component (wherein “a change tracking component” recited at high level of generality is directed to no more than mere instructions for implementing or applying the abstract idea (i.e., the mental step of updating a second table version to include the change tracking stream)),
one or more processors configured as a change tracking manager (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea),
data storage containing instructions executable by the one or more processor to perform operations comprising (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea),
a non-transitory computer-storage medium storing instructions that, when executed by one or more processor configured as a change tracking manager, cause the one or more processors to perform operations comprising (these elements are directed to generic computer components and mere instructions for implementing or applying the abstract idea).
These are a generic computer and/or generic computer components used to perform generic computer functions or insignificant extra-solution activity, which are directed to well-understood, routine, conventional activity, and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 2, 12 and 22, claims 2, 12 and 22 depend on claims 1, 11 and 21 respectively. As such, claims 2, 12 and 22 recite the abstract idea as presented in claims 1, 11 and 21.
In addition, claims 2, 12 and 22 include additional elements:
storing, by the table data component, the table data in immutable micro-partitions configured as the plurality of partitions (this step of storing as broadly recited is directed to generic storing function of a generic computer).
These are additional elements directed to generic computer function or insignificant extra-solution activity, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 3, 13 and 23, claims 3, 13 and 23 depend on claims 1, 11 and 21 respectively. As such, claims 3, 13 and 23 recite the abstract idea as presented in claims 1, 11 and 21.
In addition, claims 3, 13 and 23 include additional elements:
generating, by a metadata component of the change tracking manager, a first metadata file including metadata information of the first table version (this step of generating as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper, wherein the elements “a metadata component” or “the change tracking manager” recited at high level of generality are directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of generating)).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 4, 14 and 24, claims 4, 14 and 24 depend on claims 3, 13 and 23 respectively. As such, claims 4, 14 and 24 recite the abstract idea as presented in claims 3, 13 and 23.
In addition, claims 4, 14 and 24 include additional elements:
generating, by the metadata component of the change tracking manager, a second metadata file including metadata information of the second table version (this step of generating as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper, wherein the elements “a metadata component” or “the change tracking manager” recited at high level of generality are directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of generating)).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 5, 15 and 25, claims 5, 15 and 25 depend on claims 4, 14 and 24 respectively. As such, claims 5, 15 and 25 recite the abstract idea as presented in claims 4, 14 and 24.
In addition, claims 5, 15 and 25 include additional elements:
configuring, by the metadata component of the change tracking manager, the metadata information of the second table version to further include metadata of the at least one modification made to the first table version (this step of configuring as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper, wherein the elements “a metadata component” or “the change tracking manage” recited at high level of generality are directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of configuring)).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 6, 16 and 26, claims 6, 16 and 26 depend on claims 4, 14 and 24 respectively. As such, claims 6, 16 and 26 recite the abstract idea as presented in claims 4, 14 and 24.
In addition, claims 6, 16 and 26 include additional elements:
detecting, by the metadata component of the change tracking manager, the metadata information of the second table version is non-overlapping with the metadata information of the first table version (this step of detecting as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper through mental processes of observation and comparison, wherein the elements “a metadata component” or “the change tracking manage” recited at high level of generality are directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of configuring)),
deleting, by the metadata component, the first metadata file based on the detecting (the step of deleting as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper, such as thinking and planning on what to do, and wherein the element “the metadata component recited at high level of generality is directed to mere instructions for implementing or applying the abstract idea).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 7, 17 and 27, claims 7, 17 and 27 depend on claims 1, 11 and 21 respectively. As such, claims 7, 17 and 27 recite the abstract idea as presented in claims 1, 11 and 21.
In addition, claims 7, 17 and 27 include additional elements:
detecting, by the change tracking component, the at least one modification includes a plurality of modifications performed on the table data in the first table version, the plurality of modifications corresponding to a plurality of executed transactions (this step of detecting as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper, wherein the element “the change tracking component” recited at high level of generality is directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of detecting/determining)).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 8, 18 and 28, claims 8, 18 and 28 depend on claims 7, 17 and 27 respectively. As such, claims 8, 18 and 28 recite the abstract idea as presented in claims 7, 17 and 27.
In addition, claims 8, 18 and 28 include additional elements:
updating, by the change tracking component, the change tracking stream in the second table version to include a lineage of the plurality of executed transaction (the step of updating as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper, wherein the element “the change tracking component” recited at high level of generality is directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of updating)).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 9, 19 and 29, claims 9, 19 and 29 depend on claims 8, 18 and 28 respectively. As such, claims 9, 19 and 29 recite the abstract idea as presented in claims 8, 18 and 28.
In addition, claims 9, 19 and 29 include additional elements:
configuring, by the change tracking component, the change tracking stream as a column in the second table version (the step of configuring as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper, wherein the element “the change tracking component” recited at high level of generality is directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of updating)).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
Regarding claims 10, 20 and 30, claims 10, 20 and 30 depend on claims 8, 18 and 28 respectively. As such, claims 10, 20 and 30 recite the abstract idea as presented in claims 8, 18 and 28.
In addition, claims 10, 20 and 30 include additional elements:
detecting, by a query component of the change tracking manager, a query on the lineage of the plurality of executed transactions for a pre-configured time period (the step of detecting as broadly recited can be mentally performed in the human mind or with the aid of pencil and paper (e.g., receiving a query and determining the query is about a particular thing), wherein the elements “a query component” or “the change tracking component” recited at high level of generality are directed to mere instructions for implementing or applying the abstract idea (e.g., the mental step of updating)),
outputting, by the query component, a delta in response to the query, the delta comprising a subset of the plurality of executed transactions executed during the pre-configured time period (the step of outputting as broadly recited is directed to mere data gathering or outputting at high level of generality, or insignificant extra-solution activity).
These are additional elements directed to a mental step (i.e., abstract idea) and mere instructions or insignificant extra-solution activity for implementing the abstract idea, which do not integrate the judicial exception (e.g., an abstract idea) into a practical application and do not amount to significantly more, see MPEP 2106.05(d)(II).
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, 3-5, 7-8, 10-11, 13-15, 17-18, 20-21, 23-25, 27-28 and 30 (effective filing date 12/07/2018) are rejected under 35 U.S.C. 103 as being unpatentable over Vig et al. (U.S. Patent No. 10,853,182, effectively filed date 12/21/2015), and further in view of Bhatnagar et al. (U.S. Publication No. 2015/0278320, Publication date 10/01/2015).
As to claim 1, Vig et al. teaches:
“A method” (see Vig et al., Abstract) comprising:
“performing by at least one hardware processor configured as a change tracking manager in a database system functions comprising” (see Vig et al., Fig. 18 and [column 30, lines 29-35] for logging/tracking change records of a table T1, wherein a system for managing the table and logging change records of the table as disclosed can be interpreted as equivalent to a change tracking manager as recited; also see Fig. 3 for Journal manager 322):
“storing, by a table data component of the change tracking manager, table data for a database in a plurality of partitions residing in an object storage service” (see Vig et al., [column 5, line 53 to column 6, line 2] for storing data of a table into partitions stored in four storage nodes (i.e., partitions) of the system (see Fig. 1) (i.e., an object-storage service), wherein any code/module for storing table data into partitions as disclosed can be interpreted as equivalent to a table data component as recited);
“generating, by a transaction data component of the change tracking manager, a change tracking entry based on executing a transaction on the table data, the change tracking entry including information on at least one modification made to a first table version storing the table data” (see Vig et al., [column 4, lines 44-48] for generating change records with respect to committed transactions, wherein each change record as disclosed can be interpreted as a change tracking entry as recited; also see [column 4, lines 15-20] for change records of the particular table, wherein any code/module for logging/generating change records can be interpreted as equivalent to a transaction data component as recited);
“generating, by a change tracking component of the change tracking manager, a change tracking stream as a partition file associated with the at least one modification” (see Vig et al., [column 6, lines 20-30] for a journal storing a set of changes/writes/transactions performed on a table, wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or a partition file as recited; also see [column 12, lines 53-55] for generating a stream specification to access change records via a stream-oriented API, wherein the stream-oriented API for accessing change records can be interpreted as equivalent to a change tracking stream as recited; also see [column 13, line 65 to column 14, line 15] for generating a chain/stream of change records for each partition of a table).
In addition, Vig et al. teaches the change tracking stream including lineage of executed transactions on the table data (see Vig et al., [column 6, lines 20-30] teaches a journal storing a set of changes/writes/transactions performed on a table, wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or lineage of executed transactions as recited
However, Vig et al. does not explicitly teach a feature for storing change records in a table as recited as follows:
“updating, by the change tracking component, a second table version to include the change tracking stream, the second table version including modified table data based on completing execution of the transaction on the table data in the first table version, the change tracking stream including lineage of executed transactions on the table data, the lineage including metadata columns indicating an action type and update status for the at least one modification made to the first table version”.
On the other hand, Bhatnagar et al. explicitly teaches a feature for storing change records in a table as recited as follows:
“updating, by the change tracking component, a second table version to include the change tracking stream, the second table version including modified table data based on completing execution of the transaction on the table data in the first table version, the change tracking stream including lineage of executed transactions on the table data, the lineage including metadata columns indicating an action type and update status for the at least one modification made to the first table version” (see Bhatnagar et al., [0009] for generating/updating a shadow audit data table (i.e., a second table version) that replicates all or portion of a main data table and is populated with corresponding data that indicate whether the data in the main table has been deleted, inserted, updated (i.e., indicating action type or update status as recited), a user identification for the user associated with the deletion, insertion or update of the data, and/or the date/time of the data modification, wherein the main table can be interpreted as the first table version as recited, and the shadow audit data table as disclosed can be interpreted as a second table version (i.e., a second table) as broadly recited).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bhatnagar et al.'s teaching to Vig et al.’s system by implementing a feature of storing change records stream in a table. Ordinarily skilled artisan would have been motivated to do so to provide Vig et al.’s system with an effective alternative way to manage change records for a table. In addition, both of the references (Vig et al. and Bhatnagar et al.) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as, database system that include a feature for tracking change records of a table/database. This close relation between both of the references highly suggests an expectation of success when combined.
As to claim 3, this claim is rejected based on the same arguments as above to reject claim 1 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“generating, by a metadata component of the change tracking manager, a first metadata file including metadata information of the first table version” (see Vig et al., [column 10, lines 22-27] and [column 14, lines 19-21] for generating metadata for a given table (i.e., a table version), wherein any storage/structure for storing metadata as disclosed can be interpreted as equivalent to a metadata file as recited, and wherein any module/component for generating/obtaining metadata as disclosed can be interpreted as equivalent to a metadata component as recited; also see [column 6, lines 20-28] wherein journal for a given table can also be interpreted as a metadata file of the given table).
As to claim 4, this claim is rejected based on the same arguments as above to reject claim 3 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“generating, by the metadata component of the change tracking manager, a second metadata file including metadata information of the second table version” (see Vig et al., [column 10, lines 22-27] and [column 14, lines 19-21] for generating metadata for a given table (i.e., a table version), wherein any storage/structure for storing metadata as disclosed can be interpreted as equivalent to a metadata file as recited, and wherein any module/component for generating/obtaining metadata as disclosed can be interpreted as equivalent to a metadata component as recited; also see [column 6, lines 20-28] wherein journal for a given table can also be interpreted as a metadata file of the given table).
As to claim 5, this claim is rejected based on the same arguments as above to reject claim 4 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“configuring, by the metadata component of the change tracking manager, the metadata information of the second table version to further include metadata of the at least one modification made to the first table version” (see Vig et al., [column 6, lines 20-28] wherein a journal storing change records related to a given table can be interpreted as metadata information of the given table, and for each change/modification applied to table data, data of the given table is transformed from a first table version to a second table version, and the journal (metadata information) of the given table is updated with a change record (i.e., metadata) related to the change/modification).
As to claim 7, this claim is rejected based on the same arguments as above to reject claim 1 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“detecting, by the change tracking component, the at least one modification includes a plurality of modifications performed on the table data in first table version, the plurality of modifications corresponding to a plurality of executed transactions” (see Vig et al., [column 8, lines 57-64] wherein modifications resulting from a committed write-containing transaction directed at a table must be detected in order to generate a change record as disclosed; also see [column 15, lines 23-28] and [column 30, lines 41-45]).
As to claim 8, this claim is rejected based on the same arguments as above to reject claim 7 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“updating, by the change tracking component, the change tracking stream in the second table version to include a lineage of the plurality of executed transactions” (see Vig et al., [column 30, lines 41-60] for updating a journal (i.e., the change tracking stream) with change records, wherein a set of change records (see [column 4, lines 56-66] for a restore record set) representing writes to the table can be interpreted as a lineage of the plurality of executed transactions as recited).
As to claim 10, this claim is rejected based on the same arguments as above to reject claim 8 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“detecting, by a querying component of the change tracking manager, a query on the lineage of the plurality of executed transactions for a pre-configured time period” (see Vig et al., [column 16, lines 5-42] for allowing a journal consumer to identify/query for a respective set of changes which were committed to the table at minute-level granularity (e.g., one-minute period)); and
“outputting, by the querying component, a delta in response to the query, the delta comprising a subset of the plurality of executed transactions executed during the pre-configured time period” (see Vig et al., [column 16, lines 5-42] for allowing a journal consumer to identify/query for a respective set of changes which were committed to the table at minute-level granularity (e.g., one-minute period); also see [column 4, lines 48-66] for identifying/outputting a restore record set (i.e., a subset of changes/transactions)).
As to claim 11, Vig et al. teaches:
“A system” (see Vig et al., Abstract and Fig. 18), comprising:
“one or more processors configured as a change tracking manager” (see Vig et al., Fig. 18 and [column 30, lines 29-35] for logging/tracking change records of a table T1, wherein a system including processor(s) for managing the table and logging change records of the table as disclosed can be interpreted as equivalent to a change tracking manager as recited; also see Fig. 3 for Journal manager 322); and
“data storage containing instructions executable by the one or more processors to perform operations comprising” (see Vig et al., Fig. 18 for system memory storing code):
“storing, by a table data component of the change tracking manager, table data for a database in a plurality of partitions residing in an object-storage service” (see Vig et al., [column 5, line 53 to column 6, line 2] for storing data of a table into partitions stored in four storage nodes (i.e., partitions) of the system (i.e., storage service), wherein any code/module for storing table data into partitions as disclosed can be interpreted as equivalent to a table data component as recited);
“generating, by a transaction data component of the change tracking manager, a change tracking entry based on executing a transaction on the table data, the change tracking entry including information on at least one modification made to a first table version storing the table data” (see Vig et al., [column 4, lines 44-48] for generating change records with respect to committed transactions, wherein each change record as disclosed can be interpreted as a change tracking entry as recited; also see [column 4, lines 15-20] for change records of the particular table, wherein any code/module for logging/generating change records can be interpreted as equivalent to a transaction data component as recited);
“generating, by a change tracking component of the change tracking manager, a change tracking stream as a partition file associated with the at least one modification” (see Vig et al., [column 6, lines 20-30] for a journal storing a set of changes/writes/transactions performed on a table, wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or a partition file as recited; also see [column 12, lines 53-55] for generating a stream specification to access change records via a stream-oriented API, wherein the stream-oriented API for accessing change records can be interpreted as equivalent to a change tracking stream as recited; also see [column 13, line 65 to column 14, line 15] for generating a chain/stream of change records for each partition of a table).
In addition, Vig et al. teaches the change tracking stream including lineage of executed transactions on the table data (see Vig et al., [column 6, lines 20-30] teaches a journal storing a set of changes/writes/transactions performed on a table, wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or lineage of executed transactions as recited
However, Vig et al. does not explicitly teach a feature for storing change records in a table as recited as follows:
“updating, by the change tracking component, a second table version to include the change tracking stream, the second table version including modified table data based on completing execution of the transaction on the table data in the first table version, the change tracking stream including lineage of executed transactions on the table data, the lineage including metadata columns indicating an action type and update status for the at least one modification made to the first table version”.
On the other hand, Bhatnagar et al. explicitly teaches a feature for storing change records in a table as recited as follows:
“updating, by the change tracking component, a second table version to include the change tracking stream, the second table version including modified table data based on completing execution of the transaction on the table data in the first table version, the change tracking stream including lineage of executed transactions on the table data, the lineage including metadata columns indicating an action type and update status for the at least one modification made to the first table version” (see Bhatnagar et al., [0009] for generating/updating a shadow audit data table (i.e., a second table version) that replicates all or portion of a main data table and is populated with corresponding data that indicate whether the data in the main table has been deleted, inserted, updated (i.e., indicating action type or update status as recited), a user identification for the user associated with the deletion, insertion or update of the data, and/or the date/time of the data modification, wherein the main table can be interpreted as the first table version as recited, and the shadow audit data table as disclosed can be interpreted as a second table version (i.e., a second table) as broadly recited).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bhatnagar et al.'s teaching to Vig et al.’s system by implementing a feature of storing change records stream in a table. Ordinarily skilled artisan would have been motivated to do so to provide Vig et al.’s system with an effective alternative way to manage change records for a table. In addition, both of the references (Vig et al. and Bhatnagar et al.) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as, database system that include a feature for tracking change records of a table/database. This close relation between both of the references highly suggests an expectation of success when combined.
As to claim 13, this claim is rejected based on the same arguments as above to reject claim 11 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“generating, by a metadata component of the change tracking manager, a first metadata file including metadata information of the first table version” (see Vig et al., [column 10, lines 22-27] and [column 14, lines 19-21] for generating metadata for a given table (i.e., a table version), wherein any storage/structure for storing metadata as disclosed can be interpreted as equivalent to a metadata file as recited, and wherein any module/component for generating/obtaining metadata as disclosed can be interpreted as equivalent to a metadata component as recited; also see [column 6, lines 20-28] wherein journal for a given table can also be interpreted as a metadata file of the given table).
As to claim 14, this claim is rejected based on the same arguments as above to reject claim 13 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“generating, by the metadata component of the change tracking manager, a second metadata file including metadata information of the second table version” (see Vig et al., [column 10, lines 22-27] and [column 14, lines 19-21] for generating metadata for a given table (i.e., a table version), wherein any storage/structure for storing metadata as disclosed can be interpreted as equivalent to a metadata file as recited, and wherein any module/component for generating/obtaining metadata as disclosed can be interpreted as equivalent to a metadata component as recited; also see [column 6, lines 20-28] wherein journal for a given table can also be interpreted as a metadata file of the given table).
As to claim 15, this claim is rejected based on the same arguments as above to reject claim 14 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“configuring, by the metadata component of the change tracking manager, the metadata information of the second table version to further include metadata of the at least one modification made to the first table version” (see Vig et al., [column 6, lines 20-28] wherein a journal storing change records related to a given table can be interpreted as metadata information of the given table, and for each change/modification applied to table data, data of the given table is transformed from a first table version to a second table version, and the journal (metadata information) of the given table is updated with a change record (i.e., metadata) related to the change/modification).
As to claim 17, this claim is rejected based on the same arguments as above to reject claim 11 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“detecting, by the change tracking component, the at least one modification includes a plurality of modifications performed on the table data in first table version, the plurality of modifications corresponding to a plurality of executed transactions” (see Vig et al., [column 8, lines 57-64] wherein modifications resulting from a committed write-containing transaction directed at a table must be detected in order to generate a change record as disclosed; also see [column 15, lines 23-28] and [column 30, lines 41-45]).
As to claim 18, this claim is rejected based on the same arguments as above to reject claim 17 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“updating, by the change tracking component, the change tracking stream in the second table version to include a lineage of the plurality of executed transactions” (see Vig et al., [column 30, lines 41-60] for updating a journal (i.e., the change tracking stream) with change records, wherein a set of change records (see [column 4, lines 56-66] for a restore record set) representing writes to the table can be interpreted as a lineage of the plurality of executed transactions as recited).
As to claim 20, this claim is rejected based on the same arguments as above to reject claim 18 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“detecting, by a querying component of the change tracking manager, a query on the lineage of the plurality of executed transactions for a pre-configured time period” (see Vig et al., [column 16, lines 5-42] for allowing a journal consumer to identify/query for a respective set of changes which were committed to the table at minute-level granularity (e.g., one-minute period)); and
“outputting, by the querying component, a delta in response to the query, the delta comprising a subset of the plurality of executed transactions executed during the pre-configured time period” (see Vig et al., [column 16, lines 5-42] for allowing a journal consumer to identify/query for a respective set of changes which were committed to the table at minute-level granularity (e.g., one-minute period); also see [column 4, lines 48-66] for identifying/outputting a restore record set (i.e., a subset of changes/transactions)).
As to claim 21, Vig et al. teaches:
“A computer-storage medium storing instructions that, when executed by one or more processors configured as a change tracking manager, cause the one or more processors to perform operations comprising” (see Abstract, Fig. 18 and [column 30, lines 29-35] for memory system storing code/instructions for logging/tracking change records of a table T1, wherein a system for managing the table and logging change records of the table as disclosed can be interpreted as equivalent to a change tracking manager as recited; also see Fig. 3 for Journal manager 322):
“storing, by a table data component of the change tracking manager, table data for a database in a plurality of partitions residing in an object-storage service” (see Vig et al., [column 5, line 53 to column 6, line 2] for storing data of a table into partitions stored in four storage nodes (i.e., partitions) of the system (see Fig. 1) (i.e., object-storage service), wherein any code/module for storing table data into partitions as disclosed can be interpreted as equivalent to a table data component as recited);
“generating, by a transaction data component of the change tracking manager, a change tracking entry based on executing a transaction on the table data, the change tracking entry including information on at least one modification made to a first table version storing the table data” (see Vig et al., [column 4, lines 44-48] for generating change records with respect to committed transactions, wherein each change record as disclosed can be interpreted as a change tracking entry as recited; also see [column 4, lines 15-20] for change records of the particular table, wherein any code/module for logging/generating change records can be interpreted as equivalent to a transaction data component as recited); and
“generating, by a change tracking component of the change tracking manager, a change tracking stream as a partition file associated with the at least one modification” (see Vig et al., [column 6, lines 20-30] for a journal storing a set of changes/writes/transactions performed on a table, wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or a partition file as recited; also see [column 12, lines 53-55] for generating a stream specification to access change records via a stream-oriented API, wherein the stream-oriented API for accessing change records can be interpreted as equivalent to a change tracking stream as recited; also see [column 13, line 65 to column 14, line 15] for generating a chain/stream of change records for each partition of a table).
In addition, Vig et al. teaches the change tracking stream including lineage of executed transactions on the table data (see Vig et al., [column 6, lines 20-30] teaches a journal storing a set of changes/writes/transactions performed on a table, wherein the journal including a set/stream of changes as disclosed can be interpreted as a change tracking stream or lineage of executed transactions as recited
However, Vig et al. does not explicitly teach a feature for storing change records in a table as recited as follows:
“updating, by the change tracking component, a second table version to include the change tracking stream, the second table version including modified table data based on completing execution of the transaction on the table data in the first table version, the change tracking stream including lineage of executed transactions on the table data, the lineage including metadata columns indicating an action type and update status for the at least one modification made to the first table version”.
On the other hand, Bhatnagar et al. explicitly teaches a feature for storing change records in a table as recited as follows:
“updating, by the change tracking component, a second table version to include the change tracking stream, the second table version including modified table data based on completing execution of the transaction on the table data in the first table version, the change tracking stream including lineage of executed transactions on the table data, the lineage including metadata columns indicating an action type and update status for the at least one modification made to the first table version” (see Bhatnagar et al., [0009] for generating/updating a shadow audit data table (i.e., a second table version) that replicates all or portion of a main data table and is populated with corresponding data that indicate whether the data in the main table has been deleted, inserted, updated (i.e., indicating action type or update status as recited), a user identification for the user associated with the deletion, insertion or update of the data, and/or the date/time of the data modification, wherein the main table can be interpreted as the first table version as recited, and the shadow audit data table as disclosed can be interpreted as a second table version (i.e., a second table) as broadly recited).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bhatnagar et al.'s teaching to Vig et al.’s system by implementing a feature of storing change records stream in a table. Ordinarily skilled artisan would have been motivated to do so to provide Vig et al.’s system with an effective alternative way to manage change records for a table. In addition, both of the references (Vig et al. and Bhatnagar et al.) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as, database system that include a feature for tracking change records of a table/database. This close relation between both of the references highly suggests an expectation of success when combined.
As to claim 23, this claim is rejected based on the same arguments as above to reject claim 21 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“generating, by a metadata component of the change tracking manager, a first metadata file including metadata information of the first table version” (see Vig et al., [column 10, lines 22-27] and [column 14, lines 19-21] for generating metadata for a given table (i.e., a table version), wherein any storage/structure for storing metadata as disclosed can be interpreted as equivalent to a metadata file as recited, and wherein any module/component for generating/obtaining metadata as disclosed can be interpreted as equivalent to a metadata component as recited; also see [column 6, lines 20-28] wherein journal for a given table can also be interpreted as a metadata file of the given table).
As to claim 24, this claim is rejected based on the same arguments as above to reject claim 23 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“generating, by the metadata component of the change tracking manager, a second metadata file including metadata information of the second table version” (see Vig et al., [column 10, lines 22-27] and [column 14, lines 19-21] for generating metadata for a given table (i.e., a table version), wherein any storage/structure for storing metadata as disclosed can be interpreted as equivalent to a metadata file as recited, and wherein any module/component for generating/obtaining metadata as disclosed can be interpreted as equivalent to a metadata component as recited; also see [column 6, lines 20-28] wherein journal for a given table can also be interpreted as a metadata file of the given table).
As to claim 25, this claim is rejected based on the same arguments as above to reject claim 24 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“configuring, by the metadata component of the change tracking manager, the metadata information of the second table version to further include metadata of the at least one modification made to the first table version” (see Vig et al., [column 6, lines 20-28] wherein a journal storing change records related to a given table can be interpreted as metadata information of the given table, and for each change/modification applied to table data, data of the given table is transformed from a first table version to a second table version, and the journal (metadata information) of the given table is updated with a change record (i.e., metadata) related to the change/modification).
As to claim 27, this claim is rejected based on the same arguments as above to reject claim 21 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“detecting, by the change tracking component, the at least one modification includes a plurality of modifications performed on the table data in first table version, the plurality of modifications corresponding to a plurality of executed transactions” (see Vig et al., [column 8, lines 57-64] wherein modifications resulting from a committed write-containing transaction directed at a table must be detected in order to generate a change record as disclosed; also see [column 15, lines 23-28] and [column 30, lines 41-45]).
As to claim 28, this claim is rejected based on the same arguments as above to reject claim 27 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“updating, by the change tracking component, the change tracking stream in the second table version to include a lineage of the plurality of executed transactions” (see Vig et al., [column 30, lines 41-60] for updating a journal (i.e., the change tracking stream) with change records, wherein a set of change records (see [column 4, lines 56-66] for a restore record set) representing writes to the table can be interpreted as a lineage of the plurality of executed transactions as recited).
As to claim 30, this claim is rejected based on the same arguments as above to reject claim 28 and is similarly rejected including the following:
Vig et al. as modified by Bhatnagar et al. teaches:
“detecting, by a querying component of the change tracking manager, a query on the lineage of the plurality of executed transactions for a pre-configured time period” (see Vig et al., [column 16, lines 5-42] for allowing a journal consumer to identify/query for a respective set of changes which were committed to the table at minute-level granularity (e.g., one-minute period)); and
“outputting, by the querying component, a delta in response to the query, the delta comprising a subset of the plurality of executed transactions executed during the pre-configured time period” (see Vig et al., [column 16, lines 5-42] for allowing a journal consumer to identify/query for a respective set of changes which were committed to the table at minute-level granularity (e.g., one-minute period); also see [column 4, lines 48-66] for identifying/outputting a restore record set (i.e., a subset of changes/transactions)).
Claims 2, 12 and 22 (effective filing date 12/07/2018) are rejected under 35 U.S.C. 103 as being unpatentable over Vig et al. (U.S. Patent No. 10,853,182, effectively filed date 12/21/2015), in view of Bhatnagar et al. (U.S. Publication No. 2015/0278320, Publication date 10/01/2015), and further in view of Zukowski (“How snowflake internally performs updates?”, published on 02/07/2018).
As to claims 2, 12, and 22, Vig et al. as modified by Bhatnagar et al. teaches all limitations recited in claims 1, 11 and 21 including storing table data in partitions (e.g., storage nodes) (see Vig et al., [column 5, line 53 to column 6, line 2]).
However, Vig et al. as modified by Bhatnagar et al. does not explicitly teach partitions or storage nodes for storing table data as being immutable as recited as follows:
“storing, by the table data component, the table data in immutable micro-partitions configured as the plurality of partitions”.
On the other hand, Zukowski explicitly teaches partitions or storage nodes for storing table data as being immutable as recited as follows:
“storing, by the table data component, the table data in immutable micro-partitions configured as the plurality of partitions” (see Zukowski, Answer section, lines 2-3 for storing table data (e.g., records) in immutable micro-partitions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Zukowski's teaching to Vig et al.’s system (as modified by Bhatnagar et al.) by implementing a feature of configuring partitions for storing table data as being immutable. Ordinarily skilled artisan would have been motivated to do so, as suggested by Zukowski (see Question section), to provide Vig et al.’s system with an effective way to manage different versions of table data in the system. In addition, both of the references (Vig et al. and Zukowski) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as, database management for storing table data in a plurality of partitions. This close relation between both of the references highly suggests an expectation of success when combined.
Claims 6, 16 and 26 (effective filing date 12/07/2018) are rejected under 35 U.S.C. 103 as being unpatentable over Vig et al. (U.S. Patent No. 10,853,182, effectively filed date 12/21/2015), in view of Bhatnagar et al. (U.S. Publication No. 2015/0278320, Publication date 10/01/2015), and further in view of Lee Chang Byung (KR-101736993-B1, Published date 05/17/2017).
As to claims 6, 16, and 26, Vig et al. as modified by Bhatnagar et al. teaches all limitations recited in claims 4, 14 and 24.
However, Vig et al. as modified by Bhatnagar et al. does not explicitly teach a feature of detecting non-overlapping between information and deleting information based of the detecting as recited as follows:
“detecting, by the metadata component, metadata information of the second table version is non-overlapping with the metadata information of the first table version; and
deleting, by the metadata component, the first metadata file based on the detecting”.
On the other hand, Lee Chang Byung explicitly teaches a feature of detecting non-overlapping between information and deleting information based of the detecting (see Lee Chang Byung, [page 6, lines 12-15] for detecting non-overlapping information and deleting the non-overlapping information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Lee Chang Byung's teaching to Vig et al.’s system (as modified by Bhatnagar et al.) by implementing a feature of deleting a file based on detecting non-overlapping between information with other file. Ordinarily skilled artisan would have been motivated to do so to provide Vig et al.’s system with an effective way to manage the integrity of data in files in the system.
Claims 9, 19 and 29 (effective filing date 12/07/2018) are rejected under 35 U.S.C. 103 as being unpatentable over Vig et al. (U.S. Patent No. 10,853,182, effectively filed date 12/21/2015), in view of Bhatnagar et al. (U.S. Publication No. 2015/0278320, Publication date 10/01/2015), and further in view of Konagolli Suresh et al. (U.S. Publication No. 2013/0024422, Publication date 01/24/2013).
As to claims 9, 19, and 29, Vig et al. as modified by Bhatnagar et al. teaches all limitations recited in claims 8, 18 and 28 including appending change records in a journal (i.e., the change tracking stream) (see Vig et al., [column 8, line 57 to column 9, line 20]).
However, Vig et al. as modified by Bhatnagar et al. does not explicitly teach a feature for storing change tracking information in a column of the table as recited as follows:
“configuring, by the change tracking component, the change tracking stream as a column in the second table version”.
On the other hand, Konagolli Suresh et al. explicitly teaches a feature for storing change tracking information in a column of a table (see Konagolli Suresh et al., [0024] for tracking changes in a database by adding a first column to a schema of each database table; also see [0028] and TABLE 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Konagolli Suresh et al.'s teaching to Vig et al.’s system (as modified by Bhatnagar et al.) by implementing a feature of tracking changes in a table using a column in the table. Ordinarily skilled artisan would have been motivated to do so to provide Vig et al.’s system with an effective way to track changes to rows in a table as suggested by Konagolli Suresh et al. (see [0004]). In addition, both of the references (Vig et al. and Konagolli Suresh et al.) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as, database management including a feature of tracking changes to a table. This close relation between both of the references highly suggests an expectation of success when combined.
Examiner’s Notes
Examiner cites particular columns and line numbers in the references as applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in its 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 and the additional related prior arts made of record that are considered pertinent to applicant's disclosure to further show the general state of the art.
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 PHUONG THAO CAO whose telephone number is (571)272-2735. The examiner can normally be reached Monday - Friday: 9:00 am - 6:00 pm.
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, Amy Ng can be reached on 571-270-1698. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/Phuong Thao Cao/Primary Examiner, Art Unit 2164
Prosecution Insights