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 .
Detailed Action
This is a first Final Office Action for application 18/543,033 in response to arguments and amendments filed on 10/16/2025. Claims 1, 3-5, 17 and 19-20 are currently amended. Claims 1-20 are pending and examined below.
Claim Objections
Amendment to claim 17 is sufficient to overcome objection. Therefore, objection is withdrawn.
Response to Arguments
Applicant’s arguments, see pgs. 12-14, filed 10/16/2025, with respect to the rejection(s) of claim(s) 1, 19 and 20 under 35 USC § 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Konik (US Pub. 2016/0132558).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 5-13, 15-16 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Glebe et al. (US Pub. 2017/0322960) in view of Zhu (CN 113645217) and Konik (US Pub. 2016/0132558).
Regarding claim(s) 1, Glebe teaches
A computer-implemented method of accessing large objects (LOBs) in a database system, the method comprising: identifying, by one or more processors, in a query from a requestor, one or more predicates comprising a partial access of large object (LOB) data from a LOBs; (Fig. 1, Fig. 5; Par. [0005, 24-5, 61] data size is measured to determine if the LOB data should be stored in main memory or on disk for maximum query (i.e. partial access) responsiveness)
caching, by the one or more processors, a location of the partial access of the LOB data in a buffer, wherein the caching comprises labeling the location with at least one predicate of the one or more predicates; (Fig. 4; Par. [0047, 50] access frequency is used to determine whether or not the LOB is stored in memory (i.e. in a buffer) or on disk with an associated attribute (i.e. predicates like LOB-ID; #406) )
determining, by the one or more processors, based on comparing a pre-set access count to a count of accesses for the location, that the location is a frequently accessed location; (Fig. 4; Par. [0047, 50] access frequency (i.e. count) is used to determine whether or not the LOB is stored in memory (i.e. in a buffer) or on disk with an associated attribute (#406) )
based on determining that the location is the frequently accessed location, stabilizing, by the one or more processors, the location in an index; (Fig. 4; Par. [0047, 50] access frequency is used to determine whether or not (i.e. based on determining that the location is frequently accessed or not) the LOB is stored in memory or on disk with an associated attribute (#406) )
determining, by the one or more processors, that the location meets a length threshold and a frequency threshold; and (Fig. 4; Par. [0005, 47, 50] access frequency and size (i.e. length threshold) is used to determine whether or not (i.e. based on determining that the location is frequently accessed or not) the LOB is stored in memory or on disk with an associated attribute (#406))
based on determining that the location meets the length threshold and the frequency threshold, saving, by the one or more processors, the LOB data requested in the partial access of the LOB data inline with a base row; (Fig. 4; Par. [0005, 47, 50] access frequency and size (i.e. length threshold) is used to determine whether or not the LOB is stored in memory (i.e. inline) or on disk with an associated attribute (#406))
and storing, by the one or more processors, the full LOB in LOB pages in a LOB table space. (Par. [0061] in response to determining that the object size exceeds an upper boundary criteria, the object can be stored in disk storage as a an object spanning multiple disk pages (i.e. in a LOB table space))
Glebe does not explicitly teach
wherein the partial access of large object (LOB) data from the LOB comprises a portion of a full LOB
a pre-set access count
However, from the same field, Konik teaches
wherein the partial access of large object (LOB) data from the LOB comprises a portion of a full LOB (Par. [0003, 27] a materialized query table (MQT) is used to store query data (i.e. partial access of LOB data) below a given size threshold, including for BLOBs and CLOBs (i.e. LOBs))
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the materialized query tables of Konik into the LOB data management system of Glebe. The motivation for this combination would have been to improve the performance of queries as explained in Konik (Par. [0003]).
The combination of Glebe and Konic do not explicitly teach
a pre-set access count
However, from the same field Zhu teaches
a pre-set access count (Abs, Pg. 2 the preset access conditions including the initial access threshold are set by the user)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the preset access conditions of Zhu into the LOB data management system of Glebe. The motivation for this combination would have been to be able to adaptively adjust the access threshold as explained in Zhu (Pg. 6).
Regarding claim(s) 2, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 1, wherein stabilizing the location in the index comprises stabilizing, by the one or more processors, when rebuilding the index. (Par. [0032] an in memory index stores the main/most frequently accessed data separately from the disk storage data)
Regarding claim(s) 3, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 1, wherein the index comprises a LOB index, and wherein stabilizing the location in the LOB index comprises: storing, by the one or more processors, one or more LOB partial locations following a LOB key in one or more LOB index leaf pages. (Par. [0032] an in memory index stores the main/most frequently accessed data (i.e. LOB keys) separately from the disk storage data)
Regarding claim(s) 5, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 1, wherein saving the LOB data requested in the partial access of the LOB data inline with the base row comprises: appending, by the one or more processors, the LOB data with the at least one predicate with a LOB identifier in a LOB column to generate an inline LOB data part of the LOB. (Fig. 4; Par. [0005, 47, 50] access frequency and size (i.e. length threshold) is used to determine whether or not the LOB is stored (e.g. appended) in memory (i.e. inline) or on disk with an associated attribute (#406) )
Regarding claim(s) 6, Glebe, Zhu and Konik teach claim 5 as shown above, and Glebe further teaches
The computer-implemented method of claim 5, comprising: obtaining, by the one or more processors, a command to perform an update on the LOB data; (Par. [0053-4] when an update is performed on the LOB data, unless there is an update of the underlying data (e.g. full update), there is no change in main memory)
obtaining, by the one or more processors, from the base row, the LOB identifier of the LOB; and (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update), there is no change in main memory)
determining, by the one or more processors, based on the command, whether the update is partial data update to the LOB or a full data update to the LOB. (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless (e.g. partial) there is an update of the underlying data (e.g. full update), there is no change in main memory)
Regarding claim(s) 7, Glebe, Zhu and Konik teach claim 6 as shown above, and Glebe further teaches
The computer-implemented method of claim 6, further comprising: based on determining that the update is the partial data update, determining, by the one or more processors, if the partial data update is to LOB data comprising the inline LOB data part. (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update), there is no change in main memory (i.e. the inline LOB part))
Regarding claim(s) 8, Glebe, Zhu and Konik teach claim 7 as shown above, and Glebe further teaches
The computer-implemented method of claim 7, further comprising: based on determining that the partial data update is to the LOB data comprising the inline LOB data part, updating, by the one or more processors, the LOB data comprising the inline LOB data part and appending a higher version number to the LOB data comprising the inline LOB data part; and (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update with new version number), there is no change in main memory (i.e. the inline LOB part))
increasing, by the one or more processors, the count of accesses for the location. (Par. [0036] reference count is increased with each new in-memory reference)
Regarding claim(s) 9, Glebe, Zhu and Konik teach claim 7 as shown above, and Glebe further teaches
The computer-implemented method of claim 7, further comprising: based on determining that the partial data update is not to the LOB data comprising the inline LOB data part, determining, by the one or more processors, if the partial data update is a cached location or a stabilized location. (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update), there is no change in main memory (i.e. the cached or stabilized inline LOB part))
Regarding claim(s) 10, Glebe, Zhu and Konik teach claim 9 as shown above, and Glebe further teaches
The computer-implemented method of claim 9, further comprising: based on determining that the partial data update is the cached location or the stabilized location, obtaining, by the one or more processors, the cached location or the stabilized location; (Par. [0032] an in memory index stores the main/most frequently accessed (i.e. updated) data separately from the disk storage data)
utilizing, by the one or more processors, the cached location or the stabilized location to implement the partial data update in LOB pages; (Par. [0032] an in memory index stores (i.e. utilizes) the main/most frequently accessed (i.e. updated) data separately from the disk storage data)
identifying, by the one or more processors, locations in the LOB intersecting with the cached location or intersecting with the stabilized location in the index; (Par. [0032] an in memory index (i.e. cache) stores the main/most frequently accessed data separately from the disk storage data)
invalidating, by the one or more processors, the locations in the LOB intersecting with the cached location or intersecting with the stabilized location; (Par. [0032] an in memory index stores the main/most frequently accessed (i.e. updated or invalidated) data separately from the disk storage data)
for the stabilized location, caching the stabilized location; and (Par. [0032] an in memory index (i.e. cache) stores the main/most frequently accessed data separately from the disk storage data)
for the cached location, incrementing the count of accesses for the cached location. (Fig. 4; Par. [0047, 50] access frequency (i.e. count) is used to determine whether or not the LOB is stored in memory (i.e. in a buffer) or on disk with an associated attribute (#406) )
Regarding claim(s) 11, Glebe, Zhu and Konik teach claim 9 as shown above, and Glebe further teaches
The computer-implemented method of claim 9, further comprising: based on determining that the partial data update is not the cached location and not the stabilized location, reading, by the one or more processors, the LOB from a beginning of the LOB to obtain an update location; (Par. [0054] LOB data is accessed through a common file interface and can be provided to stream read/write (i.e. partial update) operations)
utilizing, by the one or more processors, the update location to implement the partial data update in LOB pages; (Par. [0054] LOB data is accessed through a common file interface and can be provided to stream read/write (i.e. partial update) operations)
identifying, by the one or more processors, locations in the LOB intersecting with the update location; (Par. [0054] LOB data is accessed through a common file interface and can be provided to stream read/write (i.e. partial update) operations)
invalidating, by the one or more processors, the locations in the LOB intersecting with the update location; and (Par. [0054] LOB data is accessed through a common file interface and can be provided to stream read/write (i.e. partial updates including old file location data) operations)
caching, by the one or more processors, the update location. (Fig. 4; Par. [0047, 50] access frequency is used to determine whether or not the LOB is stored in memory (i.e. in a buffer) or on disk with an associated attribute (i.e. predicates including location data; #406) )
Regarding claim(s) 12, Glebe, Zhu and Konik teach claim 6 as shown above, and Glebe further teaches
The computer-implemented method of claim 6, further comprising: based on determining that the update is the full data update to the LOB, updating, by the one or more processors, the LOB in LOB pages; and (Par. [0054] LOB data is accessed through a common file interface )
invalidating, by the one or more processors, cached locations, stabilized locations in the index, and inline data intersecting with the updated LOB. (Par. [0032] an in memory index stores the main/most frequently accessed (i.e. updated or invalidated) data separately from the disk storage data)
Regarding claim(s) 13, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 12, comprising: obtaining, by the one or more processors, a new query requesting data stored in the LOB; (Fig. 1; Par. [0005, 24-5] data size is measured to determine if the LOB data should be stored in main memory or on disk for maximum query (i.e. partial access) responsiveness)
obtaining, by the one or more processors, from the base row, the LOB identifier of the LOB; and (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update), there is no change in main memory)
determining, by the one or more processors, based on the new query, whether the new query comprises a new partial access to the data stored in the LOB or a full access to the data stored in the LOB. (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update), there is no change in main memory)
Regarding claim(s) 15, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 13, further comprising: based on determining that the new query is the new partial access to the data stored in the LOB, determining, by the one or more processors, if a portion of the data stored in the LOB accessed in the new partial access to the data stored in the LOB matches with an inline LOB predicate in the inline LOB data part. (Par. [0051] the database system can read the start position of the requested LOB and the next LOB to determine which data to retrieve (i.e. read the data stored in the LOB from the LOB pages) based on the query (i.e. predicates match))
Regarding claim(s) 16, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 15, further comprising: based on determining that the new partial access to the data stored in the LOB matches with the inline LOB predicate in the inline LOB data part, incrementing, by the one or more processors, a count of accesses for the inline LOB data part; and (Par. [0036] reference count is increased with each new in-memory reference)
returning, by the one or more processors, results for the new query from the inline LOB data part. (Par. [0051] the database system can read the start position of the requested LOB and the next LOB to determine which data to retrieve (i.e. read the data stored in the LOB from the LOB pages and return to user))
Regarding claim(s) 19, while worded slightly different, is rejected under the same rationale as claim 1.
Glebe further teaches
a memory; and one or more processors (Par. [0010] processor and memory are used)
Regarding claim(s) 20, while worded slightly different, is rejected under the same rationale as claim 19.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Glebe et al. (US Pub. 2017/0322960) in view of Zhu (CN 113645217) and Konik (US Pub. 2016/0132558), and further in view of Mattis et al. (US Pat. 6,915,307).
Regarding claim(s) 4, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
determining, by the one or more processors, if a length of the LOB data is smaller than a pre-determined length threshold; and (Par. [0032] an in memory index stores the main/most frequently accessed data separately from the disk storage data)
based on determining that the length is smaller than the pre-determined threshold, caching, by the one or more processors, the location, wherein a record cached in a buffer pool comprises the LOB identifier. (Par. [0032] an in memory index stores the main/most frequently accessed data (i.e. LOB keys) separately from the disk storage data)
The combination of Glebe, Zhu and Konik do not explicitly teach
The computer-implemented method of claim 1, wherein caching the location further comprises: generating, by the one or more processors, a hash based on a LOB identifier;
However, from the same field, Mattis teaches
The computer-implemented method of claim 1, wherein caching the location further comprises: generating, by the one or more processors, a hash based on a LOB identifier; (Col. 7 [Line 66] - Col. 8 [Line 18] a hash is generated for the object in the large object store)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the hash of Mattis into the LOB data management system of Glebe. The motivation for this combination would have been to be able to improve tracking efficiency as explained in Mattis (Col. 26 [Lines 6-8]).
Claim(s) 14 and 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Glebe et al. (US Pub. 2017/0322960) in view of Zhu (CN 113645217) and Konik (US Pub. 2016/0132558), and further in view of Bose et al. (US Pub. 2024/0126746).
Regarding claim(s) 14, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 13, further comprising: based on determining that the new query is the full access to the data stored in the LOB, reading, by the one or more processors, the data stored in the LOB from LOB pages; (Par. [0036] reference count is increased with each new in-memory reference)
based on determining that the length is smaller than the pre-determined threshold, caching, by the one or more processors, the location, wherein a record cached in a buffer pool comprises the LOB identifier. (Par. [0051] the database system can read the start position of the requested LOB and the next LOB to determine which data to retrieve (i.e. read the data stored in the LOB from the LOB pages and return to user) )
The combination of Glebe, Zhu and Konik do not explicitly teach
identifying, by the one or more processors, portions of the data stored in the LOB from the pages with intersecting inline portions of the data stored in the LOB of higher versions than the data stored in the LOB from the LOB pages
replacing, by the one or more processors, the portions of the data stored in the LOB from the LOB pages with the identified intersecting portions; and
returning, by the one or more processors, the data stored in the LOB from the pages with the replaced portions.
However, from the same field, Bose teaches
identifying, by the one or more processors, portions of the data stored in the LOB from the pages with intersecting inline portions of the data stored in the LOB of higher versions than the data stored in the LOB from the LOB pages; (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results are consistent with the system change number)
replacing, by the one or more processors, the portions of the data stored in the LOB from the LOB pages with the identified intersecting portions; and (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results (i.e. intersecting returned data) are consistent with the system change number)
returning, by the one or more processors, the data stored in the LOB from the pages with the replaced portions. (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results (i.e. intersecting returned data) are consistent with the system change number)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the object versions of Bose into the LOB data management system of Glebe. The motivation for this combination would have been to be able to improve efficiency by reducing the required number of change records as explained in Bose (Par. [0019]).
Regarding claim(s) 17, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 15, further comprising: based on determining that the new partial access to the data stored in the LOB does not match the inline LOB predicate in the inline LOB data part, determining, by the one or more processors, if the new partial access to the data stored in the LOB matches a cached location; (Par. [0032] an in memory index (i.e. cache) stores the main/most frequently accessed data separately from the disk storage data)
based on determining the new partial access to the data stored in the LOB matches the cached location, incrementing, by the one or more processors, a frequency count of the cached location; (Par. [0036] reference count is increased with each new in-memory reference)
utilizing, by the one or more processors, the cached location to read a part of the LOB data referenced in the new query from LOB pages; (Par. [0032] an in memory index (i.e. cache) stores the main/most frequently accessed (i.e. read) data separately from the disk storage data)
The combination of Glebe, Zhu and Konik do not explicitly teach
identifying, by the one or more processors, portions of the data stored in the LOB from the pages with intersecting inline portions of the data stored in the LOB of higher versions than the data stored in the LOB from the LOB pages;
replacing, by the one or more processors, the portions of the data stored in the LOB from the LOB pages with the identified intersecting portions; and
returning, by the one or more processors, results comprising the part of the LOB data referenced in the new query, a part of the LOB data referenced in the new query comprising the portions of the part of the LOB data from the pages with the replaced portions.
However, from the same field, Bose teaches
identifying, by the one or more processors, portions of the data stored in the LOB from the pages with intersecting inline portions of the data stored in the LOB of higher versions than the data stored in the LOB from the LOB pages; (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results are consistent with the system change number)
replacing, by the one or more processors, the portions of the data stored in the LOB from the LOB pages with the identified intersecting portions; and (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results (i.e. intersecting returned data) are consistent with the system change number)
returning, by the one or more processors, results comprising the part of the LOB data referenced in the new query, a part of the LOB data referenced in the new query comprising the portions of the part of the LOB data from the pages with the replaced portions. (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results (i.e. intersecting returned data) are consistent with the system change number)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the object versions of Bose into the LOB data management system of Glebe. The motivation for this combination would have been to be able to improve efficiency by reducing the required number of change records as explained in Bose (Par. [0019]).
Regarding claim(s) 18, Glebe, Zhu and Konik teach claim 1 as shown above, and Glebe further teaches
The computer-implemented method of claim 15, further comprising: based on determining that the new partial access to the data stored in the LOB does not match the inline LOB predicate in the inline LOB data part, determining, by the one or more processors, if the new partial access to the data stored in the LOB matches a cached location; (Par. [0032] an in memory index (i.e. cache) stores the main/most frequently accessed (e.g. with predicates) data separately from the disk storage data)
based on determining the partial new access to the data stored in the LOB does not match the cached location, determining, by the one or more processors, if the partial access to the data stored in the LOB matches a stabilized location in the index; (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update), there is no change in main memory (i.e. the cached or stabilized inline LOB part))
based on determining, the new partial access to the data stored in the LOB matches the stabilized location, utilizing, by the one or more processors, the stabilized location in the index to read a part of the LOB data referenced in the new query from LOB pages; (Par. [0053-4] when an update is performed on the LOB data (i.e. containing LOB-ID or similar attribute), unless there is an update of the underlying data (e.g. full update), there is no change in main memory (i.e. the cached or stabilized inline LOB part))
The combination of Glebe, Zhu and Konik do not explicitly teach
identifying, by the one or more processors, portions of the data stored in the LOB from the pages with intersecting inline portions of the data stored in the LOB of higher versions than the data stored in the LOB from the LOB pages;
replacing, by the one or more processors, the portions of the data stored in the LOB from the LOB pages with the identified intersecting portions; and
returning, by the one or more processors, results comprising the part of the LOB data referenced in the new query, a part of the LOB data referenced in the new query comprising the portions of the part of the LOB data from the pages with the replaced portions.
However, from the same field, Bose teaches
identifying, by the one or more processors, portions of the data stored in the LOB from the pages with intersecting inline portions of the data stored in the LOB of higher versions than the data stored in the LOB from the LOB pages; (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results are consistent with the system change number)
replacing, by the one or more processors, the portions of the data stored in the LOB from the LOB pages with the identified intersecting portions; and (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results (i.e. intersecting returned data) are consistent with the system change number)
returning, by the one or more processors, results comprising the part of the LOB data referenced in the new query, a part of the LOB data referenced in the new query comprising the portions of the part of the LOB data from the pages with the replaced portions. (Par. [0018-21] new versions (i.e. higher versions) of LOB content blocks are created so that database results (i.e. intersecting returned data) are consistent with the system change number)
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to combine the object versions of Bose into the LOB data management system of Glebe. The motivation for this combination would have been to be able to improve efficiency by reducing the required number of change records as explained in Bose (Par. [0019]).
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 J MITCHELL CURRAN whose telephone number is (469)295-9081. The examiner can normally be reached M-F 8:00am - 5:00pm.
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, Sherief Badawi can be reached at (571) 272-9782. 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.
/J MITCHELL CURRAN/Examiner, Art Unit 2161
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169