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 office action is in response to the claimed amendment filed on May 09, 2026, in which claims 1-20 are presented for further examination.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection necessitated by amendment and applicant’s arguments.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The independent claims 1, 16 and 17 recite “determining whether the first record comprises a first value of the second column; storing the first value in the version control system in response to determining that the first record comprises the first value of the second column”. However, the claims do not provide any end result under the condition when determining that the first record does not comprise the first value of the second column the claims render indefinite under that condition. It is also unclear how one having ordinary skill in the art would determine that the first record comprises the first value of the second column in order to store the first value in the version control system.
Furthermore, claims 1, 16 and 17 recite determining whether the second record comprises a second value of the second column; and storing the second record in the table in response to determining that the second record does not comprise the second value of the second column. However, the claims do not provide any end result under the condition when determining that the second record comprise the second value of the second column and the claims render indefinite under that condition. It is also unclear how one having ordinary skill in the art would determine that the second record does not comprise the second value of the second column in order to store the second record in the table.
Claims 2-15 and 18-20 are rejected for incorporating the deficiency of their respective base claims by dependency.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract without significantly more.
Step 1, Statutory Category:
Claims 1-15 are directed to a method
Claim 16 is directed to a computer program product
Claims 17-20 are directed to a computer system.
Therefore, claims 1-20 fall into at least one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter.
Step 2A, Prong One (Judicial exception recited)
The limitation “determining whether the first record comprises a first value of the second column” in claims 1, 16 and 17, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement, but for the recitation of generic computer components. One can mentally determine whether the first record comprises a first value of the second column.
The limitation “determining whether the second record comprises a second value of the second column” in claims 1, 16 and 17, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement, but for the recitation of generic computer components. One can mentally determine whether the second record comprises a second value of the second column.
The limitation “determining that the first record comprises the first value of the second column” in claims 1, 16 and 17, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement, but for the recitation of generic computer components. One can mentally determine that the first record comprises the first value of the second column.
At Step 2A, Prong Two:
The claim recites the following additional elements:
That the method is "implemented by a computing system" is a high-level recitation of a generic computer components and represents mere instructions to apply on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
The limitation “providing a database system with a table being configured to store data, the table comprising a first column and a second column, the first column being configured to comprising a first type of data, the second column being configured to comprising a second type of data, wherein the second type of data has a maximum size higher than a maximum size of the first type of data” amounts to data-gathering steps which is considered to be insignificant extra-solution activity, (See MPEP 2106.05(g)).
The limitation “providing a version control system” amounts to data-gathering steps which is considered to be insignificant extra-solution activity, (See MPEP 2106.05(g)).
The limitation “receiving a first query to store a first record in the table” amounts to data-gathering steps which is considered to be insignificant extra-solution activity, (See MPEP 2106.05(g)).
The limitation “storing the first value in the version control system in response to determining that the first record comprises the first value of the second column” recites insignificant extra-solution activity such as mere outputting of the result. The mere outputting of data does not meaningfully limit the abstract idea. Viewing the additional limitations together and the claim as a whole, nothing provides integration into a practical application. (See MPEP 2106.05 (g)).
The limitation “obtaining a reference token representing the first value in response to determining that the first record comprises the first value of the second column” amounts to data-gathering steps which is considered to be insignificant extra-solution activity, (See MPEP 2106.05(g)).
The limitation “storing the reference token in the second column of the table” recites insignificant extra-solution activity such as mere outputting of the result. The mere outputting of data does not meaningfully limit the abstract idea. Viewing the additional limitations together and the claim as a whole, nothing provides integration into a practical application. (See MPEP 2106.05 (g)).
The limitation “receiving a second query to store a second record in the table” amounts to data-gathering steps which is considered to be insignificant extra-solution activity, (See MPEP 2106.05(g)).
The limitation “storing the second record in the table in response to determining that the second record does not comprise the second value of the second column” recites insignificant extra-solution activity such as mere outputting of the result. The mere outputting of data does not meaningfully limit the abstract idea. Viewing the additional limitations together and the claim as a whole, nothing provides integration into a practical application. (See MPEP 2106.05 (g)).
The limitation “one or more computer-readable storage media, a memory and a processor” are recited at a high level of generality such that they amount to on more than mere instructions to apply the exception using a generic component. (see MPEP 2106.05(f)). These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer (see MPEP 2106.05(h)). Note, the mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application.
Step 2B (claim provides an inventive concept):
The conclusions for the mere implementation using a computer are carried over and does not provide significantly more.
With respect to the "obtaining ….." identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more.
With respect to the "receiving ….. steps" identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more.
With respect to the “storing … steps” identified as insignificant extra-solution activity above when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), " iv. Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93" and "i. … transmitting data over a network, …Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)".
With respect to the “one or more computer-readable storage media, a memory and a processor” amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, as demonstrate by: Relevant court decision: the followings are examples of court decisions demonstrating well-understood, routine and conventional activities, see e.g., MPEP 2106.05(d)(II) and MPEP 2106.05(f)(2): Computer readable storage media comprising instructions to implement a method, e.g., see Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea.
Looking at the claim as a whole does not change this conclusion and the claim appears to be ineligible.
Accordingly, claim 1 is directed to an abstract idea. The remaining independent claim 16 and 17 fall short the 35 USC 101 requirement under the same rationale.
The dependent claims 2-15 and 18-20 when analyzed and each taken as a whole are held to be patent ineligible under 35 USC 101 because the additional recited limitations fail to establish that the claims are not directed to an abstract idea.
Claim 2 recites “creating a logfile for logging changes of the table, wherein:
a log entry is created in the logfile to represent a change involving at least one given record of the table, the log entry comprising a value of the first column of the at least one given record and/or the reference token of the first value of the second column of the at least one given record; and the at least one given record being a deleted record and/or an inserted record”. This additional element is recited at a high level of generality and would function in its ordinary capacity for creating a logfile for logging changes of the table, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 3 recites “reading the log entry; and finding the reference token in preparation to undo the change”. This additional element is recited at a high level of generality and would function in its ordinary capacity for reading the log entry; and finding the reference token in preparation to undo the change, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 4 recites “wherein the database system is configured to manage data in the table using a command processor, wherein the first query is destined to the command processor, wherein the receiving of the first query comprises intercepting the first query by a handler of the database system; wherein the handler is configured to perform: the determining whether the first record comprises the first value of the second column; and the storing the first value in the version control system; the obtaining of the reference token from the version control system; changing the first query to replace the first value of the second column by the reference token; and forwarding the first query to the command processor for execution of the first query against the table”. This additional element is recited at a high level of generality and would function in its ordinary capacity for changing the first query to replace the first value of the second column by the reference token; and forwarding the first query to the command processor for execution of the first query against the table, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 5 recites “intercepting, by a handler, of the database system a read request of a third value of the second column, the read request being destined to the command processor; preventing, by the handler, the command processor to return the reference token associated the third value; returning, by the handler, the third value from the version control system”. This additional element is recited at a high level of generality and would function in its ordinary capacity for returning, by the handler, the third value from the version control system, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 6 recites “wherein the received first query is a request to insert the first record in the table or a request to update another record of the table by the first record”. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement. There is no additional elements recited which tie the abstract idea into a practical application and does not amount to significant more than the identified judicial exception.
Claim 7 recites “receiving a read request to read the table; identifying reference tokens of the table that satisfy the read request; providing values in the version control system which are associated with the identified reference tokens; and providing values of the first column that satisfy the read request from the table”. This additional element is recited at a high level of generality and would function in its ordinary capacity for providing values of the first column that satisfy the read request from the table, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 8 recites “receiving a delete request to delete a third value of the second column;
deleting from the table the reference token that represents the third value to be deleted; and deleting the third value of the second column from the version control system in response to a deletion condition being fulfilled”. This additional element is recited at a high level of generality and would function in its ordinary capacity for deleting the third value of the second column from the version control system in response to a deletion condition being fulfilled, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 9 recites “wherein the deletion condition requires that queries referencing the reference token that represents the third value to be deleted are ended”. This additional element is recited at a high level of generality and would function in its ordinary capacity for deleting the third value of the second column from the version control system in response to a deletion condition being fulfilled, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 10 recites “synchronizing the table with the target table such that the target table comprises records of the table, wherein a record of the target table comprises the reference token and the value of the first column”. This additional element is recited at a high level of generality and would function in its ordinary capacity for returning, by the handler, the third value from the version control system, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 11 recites “intercepting a third query referencing the target table; identifying the reference tokens of the target table that satisfy the third query; providing values in the version control system which are associated with the identified reference tokens; providing values of the first column that satisfy the third query from the target table”. This additional element is recited at a high level of generality and would function in its ordinary capacity for providing values of the first column that satisfy the third query from the target table, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 12 recites “wherein the version control system is remotely connected to the source and target database systems, wherein the version control system provides the reference token to a requester as a key to retrieve a corresponding second type of data, wherein the version control system automatically provides the reference token representing the stored first value of the second type of data upon storing the first value of the second type of data, wherein the reference token indicates a property of the associated first value of the second type of data, wherein the property enables the version control system to identify the first value of the second type of data using the reference token, wherein the property includes one of the following: a last modification date of the first value of the second type of data, a size of the first value of the second type of data, a storage location of the first value of the second type of data, and a mapping of the first value of the second type of data to a smaller size value”. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement. There is no additional elements recited which tie the abstract idea into a practical application and does not amount to significant more than the identified judicial exception.
Claim 13 recites “wherein the version control system is remotely connected to the source and target database systems and is closer to the target database system”. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement. There is no additional elements recited which tie the abstract idea into a practical application and does not amount to significant more than the identified judicial exception.
Claim 14 recites “enabling access in the version control system to the whole value of the second column or to a selected portion of the whole value of the second column using a cursor that enables traversal of portions of the whole value, the access being a read access and/or a write access”. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement. There is no additional elements recited which tie the abstract idea into a practical application and does not amount to significant more than the identified judicial exception.
Claim 15 recites “receiving a request to create the table; determining that a column of the table has values of the second type of data in accordance with the configurable parameter; creating the table with the second column of the table being tagged; wherein the method is performed in response to determining that the table is tagged”. This additional element is recited at a high level of generality and would function in its ordinary capacity for creating the table with the second column of the table being tagged, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 18 recites “create a logfile for logging changes of the table, wherein: a log entry is created in the logfile to represent a change involving at least one given record of the table, the log entry comprising a value of the first column of the at least one given record and/or the reference token of the first value of the second column of the at least one given record; and the at least one given record being a deleted record and/or an inserted record”. This additional element is recited at a high level of generality and would function in its ordinary capacity for create a logfile for logging changes of the table, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Claim 19 recites “wherein the received first query is a request to insert the first record in the table or a request to update another record of the table by the first record”. This limitation, as drafted, is a process that, under its broadest reasonable interpretation, covers a mental process as a form of evaluation or judgement. There is no additional elements recited which tie the abstract idea into a practical application and does not amount to significant more than the identified judicial exception.
Claim 20 recites “receiving a read request to read the table; identifying reference tokens of the table that satisfy the read request; providing values in the version control system which are associated with the identified reference tokens; and providing values of the first column that satisfy the read request from the table”. This additional element is recited at a high level of generality and would function in its ordinary capacity for receiving a read request to read the table; identifying reference tokens of the table that satisfy the read request; providing values in the version control system which are associated with the identified reference tokens; and providing values of the first column that satisfy the read request from the table, this additional element does not integrate the integrate the judicial exception into a practical application and does not amount to significantly more.
Remark
Applicant asserted that there is no language in the cited passages provided by the examiner in the prior arts that teaches or suggests “determining whether the first record comprises a first value of the second column”; “storing the first value (first value of the second column of the table) in the version control system in response to determining that the first record comprises the first value of the second column”, “receiving a query to store a record in the table and determining whether such a record comprises a first value of the second column of the table”; “obtaining a reference token representing the first value in response to determining that the first record comprises the first value of the second column”. After further reviewed applicant’s assertion in light of the original specification, it is conceivable that the examiner has provided prima facia evidence giving the broadest reasonable interpretation as to where each limitations of the claims found in the cited art. It is clear the application is failed to explicitly show how the abovementioned claimed limitations are achieved. Applicant is suggested to amend the claims to explicitly show how the steps of “determining whether the first record comprises a first value of the second column”; “storing the first value (first value of the second column of the table) in the version control system in response to determining that the first record comprises the first value of the second column”, “receiving a query to store a record in the table and determining whether such a record comprises a first value of the second column of the table”; and “obtaining a reference token representing the first value in response to determining that the first record comprises the first value of the second column” are achieved. Therefore the 35 USC 103 rejection set forth in the last office is hereby sustained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 10 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Hanus et al., (hereinafter “Hanus” US 2008/0243945 in view of Buchholz US 9,697,239.
As to claim 1, Hanus discloses a method for storing data, the method comprising:
providing a database system with a table being configured to store data, the table comprising a first column and a second column, the first column being configured to comprising a first type of data, the second column being configured to comprising a second type of data, wherein the second type of data has a maximum size higher than a maximum size of the first type of data (see [0008], handle logged data for Large Objects (LOBs) stored in DB2. LOB data is managed differently than conventional data, because it is much larger in size (up to 2GB). DB2 stores conventional data (i.e., first type of data) in base tables (i.e., first column), and stores actual LOB data (i.e., second type of data) separately in auxiliary tables. The base table for LOB data has a LOB column (i.e., second column) containing information identifying how to index into and access LOB data in the corresponding auxiliary table);
obtaining a reference token representing the first value in response to determining that the first record comprises the first value of the second column (see [0050], base table for LOB data has a LOB column (i.e., reference token) containing information identifying how to index into and access LOB data in the corresponding auxiliary table [0008], by linking (i.e., obtaining) the identifying information to LOB data in the VSAM store [0027]. Each access to LOB data is represented by a LOB Map Entry containing the ROWID, version number, and last page number to be read);
The instant specification does not define claim element "version control system", but recites that it may or may not be part of database system SDB (spec. [0023]) that enables data storage and access (spec. [0020]). Thus Examiner interprets "version control system" to be a database system that provides storage and access of versioned data.
Hanus identifies each type of LOB data in the base table with its own LOB column. Each LOB column contains (i.e., stores) an indicator field on the existence of LOB data; and a version field identifying a version of the LOB data (i.e., first value) for a given row (i.e., first record) in the base table when the row is inserted (i.e., first query to store) [0009]. Logged (i.e., versioned) LOB data is stored in a VSAM store (i.e., version control system) separate from the DB2 Log [0029].
Claim 1 further recites "obtaining a reference token representing the first value in response to determining that the first record comprises the first value of the second column; storing the reference token in the second column of the table;"
The base table for LOB data in Hanus has a LOB column (i.e., reference token) containing information identifying how to index into and access LOB data in the corresponding auxiliary table [0008], by linking (i.e., obtaining) the identifying information to LOB data in the VSAM store [0027]. Each access to LOB data is represented by a LOB Map Entry containing the ROWID, version number, and last page number to be read [0050].
Claim 1 further recites "receiving a second query to store a second record in the table; determining whether the second record comprises a second value of the second .
column; and storing the second record in the table in response to determining that the second record does not comprise the second value of the second column."
Each LOB column in Hanus contains an indicator field on the existence of LOB data, and if so, a version field identifying a specific version of the LOB data for a given row (i.e., second record) in the base table when the row is inserted (i.e., second query). When the indicator field is NULL, no data (i.e., second value) is stored in the corresponding auxiliary table [0009].
Hanus does not explicitly disclose a reference token.
Buchholz discloses a reference token (see col.2, lines 13-25 and 56-67, the databases of other database management systems, the token database of the token-based database system stores all data as tokens and references amongst the tokens. A token in the token database can represent any real world object. For example, a first token can represent (store) the color green and a second token can represent (store) a car. A reference amongst the first token and the second token can then represent (store) the color of the car. In a similar way, the token database stores code. More specifically, the token database stores code as a sequence of tokens. Using tokens to store code and also to store data enables the token-based database system to automatically keep code and data consistent in the token database).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Hanus. One having ordinary skill in the art would have found motivation to utilize VSM store as the version control system for logged LOB data separate from the DB2 log. One having ordinary skill in the art would also find it obvious to modify the system of Hanus to use a reference token, in order to automatically validate new information against existing information in the token database.
Claims 16-17 are analogous to claim 1, and are similarly rejected.
Claim 2 recites "The method of claim 1, the version control system being configured to maintain different versions of the second column, wherein the reference token represents a specific version of the first value of the second column in the first record, the method further comprising: creating a logfile for logging changes of the table, wherein: a log entry is created in the logfile to represent a change involving at least one given record of the table, the log entry comprising a value of the first column of the at least one given record and/or the reference token of the first value of the second column of the at least one given record; and the at least one given record being a deleted record and/or an inserted record."
Hanus creates a base table log record (i.e., log entry) in DB2 Log (i.e., logfile) when a transaction is processed to insert/update/delete (i.e., change) a record in the base table, together with the corresponding LOB log record [0025]. Each log record contains a key identifying a changed record (i.e., value of first column) and a corresponding (i.e., reference token) logged (i.e., versioned) LOB data (i.e., first value of second column) stored (i.e., maintained) separately in the VSAM store (i.e., version control system) [0026].
Claim 18 is analogous to claim 2, and is similarly rejected.
Claim 3 recites "The method of claim 2, further comprising: reading the log entry; and finding the reference token in preparation to undo the change."
LOB log records in Hanus are read through special handling by LOB log handlers [0026]. The handlers track data logged for the LOBs stored in the base table, and assemble a specific version of LOB record from the store [0028] in order to UNDO/REDO a transaction [0004].
Claim 10 recites "The method of claim 1, the database system being a source database system of a data analysis system, the data analysis system comprising a target database system, wherein the target database system comprises a target table that provides a replication copy of the table, the method further comprising: synchronizing the table with the target table such that the target table comprises records of the table, wherein a record of the target table comprises the reference token and the value of the first column."
Hanus uses Log Master to migrate (i.e., replicate) data (i.e., base tables only [0012]) from a production database (i.e., source database) to other databases (i.e., target database) for warehousing and decision support (i.e., data analysis) [0004], where the backup copy contains a snapshot (i.e., synchronized copy) of all rows (i.e., records) in the base table including values for conventional (i.e., first) column and COB column (i.e., reference token). Changes in actual LOB data are logged separately as multiple versions in the VSAM store [0066].
Claim 15 recites "The method of claim 1, wherein the second column is tagged to indicate that it comprises the second type of data, the database system comprising a configurable parameter indicating the second type of data, the method further comprising: receiving a request to create the table; determining that a column of the table has values of the second type of data in accordance with the configurable parameter; creating the table with the second column of the table being tagged; wherein the method is performed in response to determining that the table is tagged."
Hanus stores and manages three types of LOBs (i.e., second type of data) in DB2: BLOB for binary data, CLOB for single byte character data, and DBCLOB for double byte character data [0007]. Each type of LOB identified (i.e., tagged) in the base table requires (i.e., configured when base table is created) a separate LOB column
second column), each of which in turn contains an indicator field and a version field (i.e., parameters) [0009].
Claims 4-8, 11 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hanus and Buchholz as applied to claims 1 and 17 above respectively, and further in view of Anderson et al. US patent 6,047,291 [herein "Anderson"].
Claim 4 recites "The method of claim 1, wherein the database system is configured to manage data in the table using a command processor, wherein the first query is destined to the command processor, wherein the receiving of the first query comprises intercepting the first query by a handler of the database system; wherein the handler is configured to perform: the determining whether the first record comprises the first value of the second column; and the storing the first value in the version control system; the obtaining of the reference token from the version control system; changing the first query to replace the first value of the second column by the reference token; and forwarding the first query to the command processor for execution of the first query against the table."
Each LOB column in Hanus contains an indicator field on the existence of LOB data (i.e., first value); and a version field identifying a version of the LOB data for a given row (i.e., first record) in the base table when the row is inserted (i.e., first query) [0009]. Logged (i.e., versioned) LOB data is stored in the VSAM store (i.e., version control system) separate from the DB2 Log [0029], and linked (i.e., replaced) from the base table by identifying information (i.e., reference token) [0027].
Hanus teaches claim 1, but does not disclose this claim; however, DB2 triggers (i.e., handlers) allow automatic dispatch of specific procedures whenever a table is subject to (i.e., intercepting) an update, deletion or insertion (i.e., first query), while DB2 checks implement constraints on values stored in tables (e.g., existence of first value of second column). Multiple triggers are allowed, with user control over their order of execution (e.g., storing first value, obtaining reference token, changing and forwarding first query) (Anderson: 6:33-43).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Anderson to Hanus. One having ordinary skill in the art would have found motivation to utilize DB2 triggers and checks of Anderson to automatically maintain the consistent separation of conventional data from LOB data in Hanus when LOB data is subject to change.
Claim 5 recites "The method of claim 1, the database system is configured to manage data in the table using a command processor, the method further comprising: intercepting, by a handler, of the database system a read request of a third value of the second column, the read request being destined to the command processor; preventing, by the handler, the command processor to return the reference token associated the third value; returning, by the handler, the third value from the version control system."
LOB log records in Hanus are read (i.e., intercepted) through special handling by LOB log handlers [0026]. The handlers track data logged for the LOBs stored in the base .
table, and assemble a LOB record from a corresponding LOB log record and the linked (i.e., reference token) [0027] LOB data (i.e., third values) in the store (i.e., version control system) [0028].
Hanus teaches claim 1, but does not disclose this claim; however, relational extenders (i.e., handlers) in Anderson treat each new and complex data type as an object. Each object (i.e., third value) possesses hidden attributes that are accessed through a functional interface. An application only has visibility (i.e., read access) to the interface, which hides (i.e., prevents from returning) implementation details (i.e., reference token) of accessing the attributes (Anderson: 6:44-50).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Anderson to Hanus. One having ordinary skill in the art would have found motivation to utilize relational extenders of Anderson to provide read access to LOB data in Hanus while hiding implementation details.
Claim 6 recites "The method of claim 1, wherein the received first query is a request to insert the first record in the table or a request to update another record of the table by the first record."
Each LOB column in Hanus contains an indicator field on the existence of LOB data; and a version field identifying a version of the LOB data for a given row in the base table when the row is inserted (i.e., first query) [0009]. Actual LOB data is stored in the corresponding auxiliary table (i.e., another record) separate from the DB2 Log [0029], and linked from the base table by identifying information [0027].
Hanus teaches claim 1, but does not disclose this claim; however, DB2 triggers allow automatic dispatch of specific procedures whenever a table is subject to an update, deletion or insertion (i.e., first query), while DB2 checks implement constraints on values stored in tables (e.g., indicator field). Multiple triggers are allowed, with user control over their order of execution (Anderson: 6:33-43).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Anderson to Hanus. One having ordinary skill in the art would have found motivation to utilize DB2 triggers and checks of Anderson to automatically maintain the consistent separation of conventional data from LOB data in Hanus when LOB data is subject to change.
Claim 19 is analogous to claim 6, and is similarly rejected.
Claim 7 recites "The method of claim 1, further comprising: receiving a read request to read the table; identifying reference tokens of the table that satisfy the read request; providing values in the version control system which are associated with the identified reference tokens; and providing values of the first column that satisfy the read request from the table."
LOB log records in Hanus are read through special handling by LOB log handlers [0026]. The handlers track data logged for the LOBs stored in the base table, and
assemble (i.e., provide) a LOB record from a corresponding LOB log record and the linked (i.e., reference token) [0027] LOB data (i.e., values) in the store (i.e., version control system) [0028].
Hanus teaches claim 1, but does not disclose this claim; however, relational extenders in Anderson treat each new and complex data type as an object. Each object possesses hidden attributes that are accessed through a functional interface. An application only has visibility (i.e., read access) to the interface, which hides implementation details (i.e., reference token) of accessing the attributes (6:44-50). SQL queries (i.e., read request) can be performed on the combined traditional and complex data types satisfying content (i.e., values of first column) search criteria (i.e., satisfying read request) (Anderson: 2:32-47).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Anderson to Hanus. One having ordinary skill in the art would have found motivation to utilize relational extenders of Anderson to provide read access to LOB data in Hanus while hiding implementation details.
Claim 20 is analogous to claim 7, and is similarly rejected.
Claim 8 recites "The method of claim 1, further comprising: receiving a delete request to delete a third value of the second column; deleting from the table the reference token that represents the third value to be deleted; and deleting the third value of the second column from the version control system in response to a deletion condition being fulfilled."
Hanus teaches claim 1, but does not disclose this claim; however, DB2 triggers allow automatic dispatch of specific procedures whenever a table is subject to an update, deletion or insertion, while DB2 checks implement constraints (e.g., deletion condition) on values stored in tables. Multiple triggers are allowed, with user control over their order of execution (e.g., deleting reference token, deleting third value) (Anderson: 6:33-43).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Anderson to Hanus. One having ordinary skill in the art would have found motivation to utilize DB2 triggers and checks of Anderson to automatically maintain the consistent separation of conventional data from LOB data in Hanus when LOB data is subject to change.
Claim 11 recites "The method of claim 10, wherein the target database system further comprises a target handler, the target handler being configured for: intercepting a third query referencing the target table; identifying the reference tokens of the target table that satisfy the third query; providing values in the version control system which are associated with the identified reference tokens; providing values of the first column that satisfy the third query from the target table."
LOB log records in Hanus are read (i.e., intercepted) through special handling by LOB log handlers (i.e., target handler) [0026]. The handlers track data logged for the LOBs stored in the base table, and assemble a LOB record from the corresponding LOB log record and the linked (i.e., reference token) [0027] LOB data (i.e., values) in the store (i.e., version control system) [0028].
Hanus teaches claim 1, but does not disclose this claim; however, relational extenders in Anderson treat each new and complex data type as an object. Each object possesses hidden attributes that are accessed through a functional interface. An application only has visibility (i.e., read access) to the interface, which hides implementation details (i.e., reference token) of accessing the attributes (6:44-50). SQL queries (i.e., third query) can be performed on the combined traditional and complex data types satisfying content (i.e., values of first column) search criteria (i.e., satisfying third query) (Anderson: 2:32-47).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of Anderson to Hanus. One having ordinary skill in the art would have found motivation to utilize relational extenders of Anderson to provide read access to LOB data in Hanus while hiding implementation details.
Claims 9 is rejected under 35 U.S.C. 103 as being unpatentable over Hanus and Buchholz as applied to claim 8 above, in view of Anderson, and further in view of Remote Blob Store (RBS) (SQL Server). pp. 1-7, Feb 2023. https://learn.microsoft.com/en-us/sgl/relationale databases/blob/remote-blob-store-rbs-sgleerver/viewssgl-server-ver16fherein "RBS"].
Claim 9 recites "The method of claim 8, wherein the deletion condition requires that queries referencing the reference token that represents the third value to be deleted are ended."
Hanus and Anderson teach claim 8, where DB2 triggers allow automatic dispatch of specific procedures whenever a table is subject to an update, deletion or insertion, while DB2 checks implement constraints (e.g., deletion condition) on values stored in tables (Anderson: 6:33-43).
Hanus and Anderson do not disclose this claim; however, SQL Server Remote BLOB Store (RBS) lets database admins store binary large objects in commodity storage solutions instead of directly on the main database server. BLOBs are managed with ACID transactions, meaning that a BLOB (i.e., third value) cannot be read (i.e., queried) and written to (i.e., deleted) simultaneously, one has to end before the other can start (RBS: pp. 1/7).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of RBS to Hanus and Anderson. One having ordinary skill in the art would have found motivation utilize DB2 triggers and checks of Anderson to automatically maintain the separation of conventional data from LOB data in Hanus while keeping transactions ACID as in RBS.
Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Hanus and Buchholz as applied to claim 10 above, and further in view of Understanding Azure Blob Storage Metadata: A Complete Guide. Mar. 2023, pp. 1-11. https://www.smikar.com/azure-blob-storage metadata/ [herein "BlobMetadata"].
Claim 12 recites "The method of claim 10, wherein the version control system is remotely connected to the source and target database systems,"
Hanus uses Log Master to migrate data from a production database (i.e., source database) to other databases (i.e., target database) for data analysis applications such as warehousing and decision support [0004].
Claim 12 further recites "wherein the version control system provides the reference token to a requester as a key to retrieve a corresponding second type of data, wherein the version control system automatically provides the reference token representing the stored first value of the second type of data upon storing the first value of the second type of data, wherein the reference token indicates a property of the associated first value of the second type of data, wherein the property enables the version control system to identify the first value of the second type of data using the reference token,"
The base table for LOB data in Hanus has a LOB column containing (i.e., storing) information identifying how to index into and access LOB data in the corresponding auxiliary table [0008], by linking (i.e., providing to requester) the identifying (i.e., key) information (i.e., reference token) to (i.e., representing) actual LOB data (i.e., first value of second type) in the VSAM store [0027].
Hanus teaches claim 10, but does not disclose "wherein the property includes one of the following: a last modification date of the first value of the second type of data, a size of the first value of the second type of data, a storage location of the first value of the second type of data, and a mapping of the first value of the second type of data to a smaller size value."
However, Azure Blob Storage (i.e., version control system) is a scalable, secure and cost-effective cloud (i.e., remote) storage solution for large amount of unstructured data (BlobMetadata: pp. 2/11). Metadata (i.e., properties) are name-value pairs and can include information such as creation date (i.e., last modification date), author, title, and keywords.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of BlobMetadata to Hanus. One having ordinary skill in the art would have found motivation to store LOB data in Hanus with data analysis applications when it is accessed more frequently for data analysis than for production transactions.
Claim 13 recites "The method of claim 10, wherein the version control system is remotely connected to the source and target database systems and is closer to the target database system."
Hanus uses Log Master to migrate data from a production database (i.e., source database) to other databases (i.e., target database) for data analysis applications such as warehousing and decision support [0004].
Hanus teaches claim 10, but does not disclose this claim; however, Azure Blob Storage (i.e., version control system) is a scalable, secure and cost-effective cloud (i.e., .remote) storage solution for large amounts of unstructured data (BlobMetadata: pp. 2/11).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to apply the teachings of RBS to Hanus. One having ordinary skill in the art would have found motivation to store LOB data of Hanus with (i.e., closer to) data analysis applications when it is accessed more frequently for data analysis than for production transactions.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Hanus and Buchholz as applied to claim 1 above, in view of Anderson, and further in view of SQL - Cursors. pp. 1-5, May 2023. https://www.tutorialspoint.com/sql/sgl-cursors.htm [herein "SQLCursor"].
Claim 14 recites "The method of claim 1, further comprising: enabling access in the version control system to the whole value of the second column or to a selected portion of the whole value of the second column using a cursor that enables traversal of portions of the whole value, the access being a read access and/or a write access."
Hanus stores LOB data in a VSAM store (i.e., version control system) [0029].
Hanus teaches claim 1, but does not disclose this claim; however, Anderson performs SQL queries (i.e., read request) on the combined traditional and complex data types satisfying content (i.e., values of second column) search criteria (Anderson: 2:32-47). A cursor is temporary memory holding the result set of a SQL query (i.e., whole or selected portion), which enables iteration (i.e., traversal) through the result set one row at a time to retrieve (i.e., read) and manipulate (i.e., write) data (SQLCursor: pp. 1/5).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20200210395 (involved in parsing a DDL statement and obtaining a version control data construct for the columns of a table defined by the DDL statement. The table is created (220) based on the DDL statement with a version control attribute set on the columns. A versioning for rows of the table is managed based on the version control attribute for the column. The version control data construct associated with each column of the table in a context of a SQL-formatted command is identified. The version control data construct is recognized as a command indicating that data changes associated with data values for the column are not to be versioned in new rows for the table).
US 20200133934 A1 (involved in accessing a multi-version concurrency control (MVCC) block providing row state for a block of rows in a table of a database. The MVCC block is provided with a header portion and a data portion. The header portion is provider with a type indicator for indicating whether all of the rows of the block are visible to a several threads at a database management system or invisible to the several threads at the database management system. The write is performed under a lock to inhibit changes to the MVCC block).
US 20080005077 (involved in using data version management module to check database table for recording the received data. A new record for received data is created and inserted in the database table, when record related to the received data is determined. The encoded version column (EVC) data value of new record is set to zero and inserted into the table. The new version of received data is inserted into the table and EVC value to new version data is assigned when received data is not related to record. The EVC value for existing record is updated by module using received data).
US 7028057 (involved in a set of versions of a table, and automatically creates and maintains metadata permitting determination of proper subset of versions. The subset includes version in which constraint violation occurs as result of operation performed on given versions. The metadata is employed to locate rows in versions of subset for which operation on given versions results in violation of constraint).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEAN M CORRIELUS whose telephone number is (571)272-4032. The examiner can normally be reached Monday-Friday 6:30a-10p(Midflex).
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, Ann J Lo can be reached at (571)272-9767. 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.
/JEAN M CORRIELUS/Primary Examiner, Art Unit 2159 June 25, 2026
Prosecution Insights