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 .
In response to Applicant’s claims filed on June 24, 2026, claims 1-20 are now pending for examination in the application.
Response to Arguments
This office action is in response to amendment filed 06/22/2026. In this action Claim(s) 1-3, 8-9, 11-13, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US Pub. No. 20090024578) in view of Meyer et al. (US Pub. No. 20210240676). The Meyer et al. reference has been added to address the amendment of, each LOB staging record of said plurality of LOB staging records specifying replacement data for an address range of a respective LOB of said plurality of LOBs.
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.
Claim(s) 1-3, 8-9, 11-13, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US Pub. No. 20090024578) in view of Meyer et al. (US Pub. No. 20210240676).
With respect to claim 1, Wang et al. teaches a method, comprising:
a DBMS (Paragraph 52 discloses a relational database management system (RDBMS) called "Oracle Database") executing a database transaction that makes changes to data blocks of a database (Paragraph 28 discloses data types which can easily be managed in a row-oriented table of the transactional part of the data management system);
said database transaction making a plurality of LOB change calls to change a plurality of LOBs, wherein each of said plurality of LOB change calls changes a different respective LOB of said plurality of LOBs (Paragraph 23 discloses insert atom by appending the new data to be inserted at a physical end of the LOB);
said DBMS receiving a command to commit said database transaction (Paragraph 50 discloses system 400 performs an action 491 to evaluate one or more predetermined conditions which trigger reorganization of the LOB's data. If the condition(s) is/are met, then system 400 registers a post commit callback);
in response to said DBMS receiving a command to commit said database transaction, performing commit time operations to commit said database transaction, wherein said commit time operations include: executing a plurality of database writes to store content based on at least a first set of LOB staging records of said plurality of LOB staging records in a plurality of LOB content blocks (Paragraph 50 discloses an action 491 to evaluate one or more predetermined conditions which trigger reorganization of the LOB's data. If the condition(s) is/are met, then system 400 registers a post commit callback). Wang et al. does not disclose in response to said plurality of LOB change calls, storing a plurality of LOB staging records in a LOB staging cache, each LOB staging record of said plurality of LOB staging records specifying a change to LOB content of a respective LOB of said plurality of LOBs.
However, Meyer et al. teaches in response to said plurality of LOB change calls, storing a plurality of LOB staging records in a LOB staging cache, each LOB staging record of said plurality of LOB staging records specifying replacement data for an address range of a respective LOB of said plurality of LOBs (Paragraph 49 discloses the batch data will be loaded into the staging records of the data import object. This includes loading the survey dates into the custom staging field (i.e., survey_date_CSF) of the staging records. Then, one or more records in the survey target object will be generated/updated based on the staging records. As part of this record generating/updating, and because of the field mapping generated in FIG. 6, the survey dates in the custom staging field (i.e., survey_date_CSF) of the staging records will be stored in the survey field 444 of the records in the survey custom object).
Therefore, it would have been obvious at the time the invention was made to a person having ordinary skill in the art to modify Wang et al. with Meyer et al.’s staging record. This would have facilitated data management.
The Wang et al. reference as modified by Meyer et al. teaches all the limitations of claim 1. Regarding claim 2, Meyer et al. discloses the method of claim 1, wherein:
said plurality of LOB staging records includes a first set of LOB staging records and a second set of LOB staging records (Paragraph 19 discloses the data in the staging records 122 is used to generate/update records in the standard objects 130 and the custom objects 140. Specifically, the data in different fields in the staging records 122 may end up in different objects (e.g., standard objects 130, custom objects 140) in newly generated or updated records);
performing commit time operations includes:
determining that said first set of LOB staging records and said second set of LOB staging records specify changes to particular LOBs that are stored in a same first segment (Paragraph 20 discloses each of the staging records 122 has one or more imported record fields 125. Following processing of the batch data 172, each imported record field 125 is populated with a pointer to a record that was generated or updated based on the data in the staging record); and
in response to determining that said first set of LOB staging records and said second set of LOB staging records specify changes to LOBS that are stored in a same first segment, storing LOB content blocks for said particular LOBs contiguously within said same first segment (Paragraph 41 discloses one or more records in the standard object may be generated/updated based on the staging records and the new field mapping. Specifically, a single staging record may trigger a record to be generated/updated in the standard object based on the new field mapping. The data in different fields of a single staging record may end up stored in different records across the multiple staging objects and custom objects). The motivation to combine statement previously provided in the rejection of dependent claim 1 provided above, combining the Wang et al. reference and the Meyer et al. reference is applicable to dependent claim 2.
The Wang et al. reference as modified by Meyer et al. teaches all the limitations of claim 2. Regarding claim 3, Meyer et al. discloses the method of claim 2,
wherein said plurality of LOB staging records includes a third set of LOB staging records that specify changes to a third LOB stored in a second segment (Paragraph 41 discloses one or more records in the standard object may be generated/updated based on the staging records and the new field mapping. Specifically, a single staging record may trigger a record to be generated/updated in the standard object based on the new field mapping. The data in different fields of a single staging record may end up stored in different records across the multiple staging objects and custom objects); and
where executing a plurality of database writes includes executing a database write to store a LOB content block for said third LOB in said second segment (Paragraph 33 discloses custom staging field (to ensure data from the staging records can write to the target fields without error)). The motivation to combine statement previously provided in the rejection of dependent claim 2 provided above, combining the Wang et al. reference and the Meyer et al. reference is applicable to dependent claim 3.
The Wang et al. reference as modified by Meyer et al. teaches all the limitations of claim 1. Regarding claim 8, Meyer et al. discloses the method of claim 1, wherein before initiating said database transaction, said plurality of LOB staging records include a particular LOB staging record that specifies a change to a particular LOB content block, said particular LOB content block being retained after committing said database transaction (Paragraph 35 discloses one or more records in the custom object(s) and the standard object(s) may be generated/updated based on the staging records and the field mappings. Specifically, a single staging record may trigger a record to be generated/updated in multiple standard objects and custom objects). The motivation to combine statement previously provided in the rejection of dependent claim 1 provided above, combining the Wang et al. reference and the Meyer et al. reference is applicable to dependent claim 8.
The Wang et al. reference as modified by Meyer et al. teaches all the limitations of claim 1. Regarding claim 9, Meyer et al. discloses the method of claim 1, further including in response to a database read command for a particular LOB, applying one or more LOB staging records of said plurality of LOB staging records that specify changes to said particular LOB to return data requested by database read command (Paragraph 159 discloses reading log records in any data page transaction log between the storage checkpoint LSN and the cache checkpoint LSN; and setting dirty bits for all data pages changed by the log records). The motivation to combine statement previously provided in the rejection of dependent claim 1 provided above, combining the Wang et al. reference and the Meyer et al. reference is applicable to dependent claim 9.
With respect to claim 11, Wang et al. teaches one or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause:
a DBMS (Paragraph 52 discloses a relational database management system (RDBMS) called "Oracle Database") executing a database transaction that makes changes to data blocks of a database (Paragraph 28 discloses data types which can easily be managed in a row-oriented table of the transactional part of the data management system);
said database transaction making a plurality of LOB change calls to change a plurality of LOBs, wherein each of said plurality of LOB change calls changes a different respective LOB of said plurality of LOBs (Paragraph 23 discloses insert atom by appending the new data to be inserted at a physical end of the LOB);
said DBMS receiving a command to commit said database transaction (Paragraph 50 discloses system 400 performs an action 491 to evaluate one or more predetermined conditions which trigger reorganization of the LOB's data. If the condition(s) is/are met, then system 400 registers a post commit callback);
in response to said DBMS receiving a command to commit said database transaction, performing commit time operations to commit said database transaction, wherein said commit time operations include: executing a plurality of database writes to store content based on at least a first set of LOB staging records of said plurality of LOB staging records in a plurality of LOB content blocks (Paragraph 50 discloses an action 491 to evaluate one or more predetermined conditions which trigger reorganization of the LOB's data. If the condition(s) is/are met, then system 400 registers a post commit callback). Wang et al. does not disclose in response to said plurality of LOB change calls, storing a plurality of LOB staging records in a LOB staging cache, each LOB staging record of said plurality of LOB staging records specifying a change to LOB content of a respective LOB of said plurality of LOBs.
However, Meyer et al. teaches in response to said plurality of LOB change calls, storing a plurality of LOB staging records in a LOB staging cache, each LOB staging record of said plurality of LOB staging records specifying replacement data for an address range of a respective LOB of said plurality of LOBs (Paragraph 49 discloses the batch data will be loaded into the staging records of the data import object. This includes loading the survey dates into the custom staging field (i.e., survey_date_CSF) of the staging records. Then, one or more records in the survey target object will be generated/updated based on the staging records. As part of this record generating/updating, and because of the field mapping generated in FIG. 6, the survey dates in the custom staging field (i.e., survey_date_CSF) of the staging records will be stored in the survey field 444 of the records in the survey custom object).
Therefore, it would have been obvious at the time the invention was made to a person having ordinary skill in the art to modify Wang et al. with Meyer et al.’s staging record. This would have facilitated data management.
With respect to claim 12, it is rejected on grounds corresponding to above rejected claim 2, because claim 12 is substantially equivalent to claim 2.
With respect to claim 13, it is rejected on grounds corresponding to above rejected claim 3, because claim 13 is substantially equivalent to claim 3.
With respect to claim 18, it is rejected on grounds corresponding to above rejected claim 8, because claim 18 is substantially equivalent to claim 8.
With respect to claim 19, it is rejected on grounds corresponding to above rejected claim 9, because claim 19 is substantially equivalent to claim 9.
Claim(s) 6-7 and 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US Pub. No. 20090024578) and Meyer et al. (US Pub. No. 20210240676) in further view of Sorenson III (US Patent No. 10210167).
The Wang et al. reference as modified by Meyer et al. teaches all the limitations of claim 1. Regarding claim 6, Wang et al. reference as modified by Meyer et al. does not disclose determining that a threshold amount of data is stored in said LOB staging cache.
However, Sorenson III teaches the method of claim 1, wherein the method further includes:
determining that a threshold amount of data is stored in said LOB staging cache (Column Lines 7-58 discloses implement cache management policies, such as data indicating whether data pages or objects stored in the RAM and/or the SSD are clean, dirty, etc., data indicating whether data pages or objects are prioritized, SSD flushing parameters such as SSD flushing frequencies and SSD delay thresholds); and
in response to determining that a threshold amount of data is stored in said LOB staging cache, flushing said LOB staging cache (Column Lines 7-58 discloses implement cache management policies, such as data indicating whether data pages or objects stored in the RAM and/or the SSD are clean, dirty, etc., data indicating whether data pages or objects are prioritized, SSD flushing parameters such as SSD flushing frequencies and SSD delay thresholds).
Therefore, it would have been obvious at the time the invention was made to a person having ordinary skill in the art to modify Wang et al. and Meyer et al. with Sorenson III to include determining that a threshold amount of data is stored in said LOB staging cache. See Sorenson III Column 3 Lines 31-61.
The Wang et al. reference as modified by Meyer et al. and Sorenson III teaches all the limitations of claim 6. Regarding claim 7, Sorenson III discloses the method of claim 6, wherein flushing said LOB staging cache includes executing a plurality of database writes to store content specified by a second set of LOB staging records of said plurality of LOB staging records in one or more LOB content blocks (Column 11 Lines 11-22 discloses the primary responsibilities of coordinators 120 may include conducting read and write activity of object data 33 and metadata 31 for objects 30 in response to web services requests directed to those objects 30) and flush the fragment(s), e.g., via data operations 194, to data storage 150 (e.g., using 1 MB write I/O requests)). The motivation to combine statement previously provided in the rejection of dependent claim 6 provided above, combining the Wang et al. reference and the Sorenson III reference is applicable to dependent claim 7.
With respect to claim 16, it is rejected on grounds corresponding to above rejected claim 6, because claim 16 is substantially equivalent to claim 6.
With respect to claim 17, it is rejected on grounds corresponding to above rejected claim 7, because claim 17 is substantially equivalent to claim 7.
Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US Pub. No. 20090024578) and Meyer et al. (US Pub. No. 20210240676)in further view of Oliveira Lizardo et al. (US Pub. No. 20230060702).
The Wang et al. reference as modified by Meyer et al. teaches all the limitations of claim 1. Regarding claim 10, Wang et al. as modified by Meyer et al. does not disclose the method further includes rolling back said database transaction to a particular save point.
However, Oliveira Lizardo et al. discloses the method of claim 1, wherein:
each LOB staging record of said plurality of LOB staging records is associated with a save point of said database transaction (Paragraph 50 discloses Commit the transaction, or rollback in case of error);
the method further includes rolling back said database transaction to a particular save point (Paragraph 50 discloses Commit the transaction, or rollback in case of error); and
wherein applying one or more LOB staging records includes applying one or more LOB staging records based on the particular save point and one or more save points associated with said one or more LOB staging records (Paragraph 50 discloses Commit the transaction, or rollback in case of error).
Therefore, it would have been obvious at the time the invention was made to a person having ordinary skill in the art to modify Wang et al. and Meyer et al. with Oliveira Lizardo et al. to include determining that a threshold amount of data is stored in said LOB staging cache. See 20230060702 Paragraphs 3-5.
With respect to claim 20, it is rejected on grounds corresponding to above rejected claim 10, because claim 20 is substantially equivalent to claim 10.
Claims 4, 5, 14 and 15 are not rejected over prior art.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Pub. No. 20180275898 is directed to Managing I/O Operations For Data Objects In A Storage System: [Paragraph 0147] Furthermore, the various networks, systems, and methods discussed above may include hardware and/or software to decrease latency issues associated with modifying data in data objects, and particularly LOBs, by reading one or more smaller data chunks from storage devices 102 and/or enterprise data service 50 to buffer memory 108/208 in succession, modifying the data chunk(s), and writing/re-writing the modified data chunk(s) to storage device(s) 102 and/or enterprise data service 50. That is, the various embodiments discussed herein may be characterized as performing multiple read-write operations on a LOB over a period of time.
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 NICHOLAS E ALLEN whose telephone number is (571)270-3562. The examiner can normally be reached Monday through Thursday 830-630.
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, Boris Gorney can be reached at (571) 270-5626. 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.
/N.E.A/Examiner, Art Unit 2154
/BORIS GORNEY/Supervisory Patent Examiner, Art Unit 2154
Prosecution Insights