DETAILED ACTION
This office action is in response to applicant's communication filed on 01/07/2026.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The Applicant's remarks and amendments, in response to the last Office Action, have been considered with the results that follow:
Claims 1, 7, 9, 15 and 17 are amended.
Claims 5 and 13 are canceled.
Claims 1-4, 6-12, and 14-20 are now pending in this application.
The previously raised objections to the claims are withdrawn in view of Applicant's amendments.
The previously raised objection to the title is withdrawn in view of Applicant’s amended new title.
Response to Arguments
Applicant's arguments filed 02/05/2026 have been fully considered but they are moot, because a new ground(s) of rejection has been issued, in view of Applicant's amendments to the claims, and the arguments do not apply to the new combination of references being used in the current rejection.
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-4, 6-12, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Beavin (US 2016/0196306 A1) in view of Chainani (US 2016/0378833 A1).
Regarding claim 1,
Beavin teaches A computer-implemented method comprising:
detecting, in a query execution, a join of a first table and a second table; and in response to the detecting the join, optimizing the query execution by at least scanning a plurality of first value identifiers from the first table, translating the plurality of first value identifiers into … , building a hash table using the translated plurality of first value identifiers, performing a table scan semi-join on the second table by scanning a plurality of second value identifiers of the second table that have been filtered by the translated plurality of first value identifiers and reading one or more filtered second value identifiers of the second table, providing the one or more filtered second value identifiers of the second table as a probe into the hash table including the translated plurality of first value identifiers, and outputting one or more matching rows corresponding to matching value identifiers for matching values in the first table and the second table. *see paras19-26(“FIG. 3 illustrates data structures and aspects of query execution…dimension table 310 and fact table 320 [first, second table] are shown…to reduce resources consumed and increase speed of query execution [optimizing query execution]…hash table such as 340 is built for at least some rows of its respective dimension table 310 involved in the join process. A hash table 340 is created after scanning its dimension table 310 [scanning…first value identifiers from the first table…building a hash table using…]. This is typically quick and efficient, but still requires probing the one or more hash tables based on rows in the fact table 320…some systems determine a range of values for a key column of an inner table, such as a dimension table 310, for example, and then apply the range as a predicate for a key column of an outer table, e.g., fact table 320 [performing table scan semi-join…scanning second value identifiers filtered by translated first value identifiers, reading filtered second value identifiers/second table, providing filtered second value identifiers of second table as probe into hash table…]…a Bloom filter and the range predicate may be applied…FIG. 3 shows applying a predicate to dimension table 310 at run-time, wherein the query execution module scans dimension table 310 to apply the predicate 330 and may also generate hash table… using the results of applying the one or more predicates, the query execution module may also at run-time convert the results into one or more respective IN-list predicates for run-time probing of, or application to, larger, fact table 320 [translating…form a shared translation table] …consider tables having a “firstName” column that contains first names. For selecting rows in table 320 [outputting matching rows…] that include first names John, Jack and Rick, for example, an IN-list predicate could be stated as follows, according to an example syntax: firstName IN {‘John’, ‘Jack’, ‘Rick’}....”), paras28-35(“…FIG. 3 shows two rows of table 310 that survive application of the predicate, for example, and shows a query execution module responsively generating a hash table 340 for the payload column of the two surviving rows of dimension table 310. FIG. 3 also shows the query execution module converting those two rows into an IN-list predicate 315 at run-time. FIG. 3 also shows the query execution module applying the IN-list predicate 315 at run-time to fact table 320, yielding one surviving row [outputting matching rows…first…second table]. FIG. 3 shows probing hash table 340, using the join key value of the surviving row of fact table 320, to find a matching value from the payload column of dimension table… applying predicates to dimension tables 310 at run-time and then converting those results into IN-list predicates for application at run-time to a fact table 320 [translating first value identifiers…; teaches value identifiers domain, shared translation table under their broadest reasonable interpretation] can greatly improve join processing time…Bloom filter may also be created by query execution module to reduce the number of non-matching probes into hash tables. A bloom filter is an approximate filter that may have false positive rows that survive probing, but which are then eliminated during hash table look up. That is, responsive to scanning of a dimension table, a query execution module may generate a bloom filter and a hash table for rows of the dimension table that survive predicate application. Prior to probing the hash table, the query execution module probes bloom filter to determine whether each row of the probing can be discarded...”), paras36-46(“...join process 400 executed by a query execution module includes a build stage 405 and a probe stage 410…computing minimum and maximum join key values on a dimension table and then building a bloom filter and a hash table, the query execution module selectively performs one or more additional actions 415-445 …For surviving rows (e.g., the rows with keys B and C in FIG. 3) of each dimension table 310 to which the query execution module applied 420 a local predicate 330, the query execution module performs actions 425, which include comparing join key values with one another for a given join key column_in order to determine distinct join key values and count how many exist…Using a predicate to probe a table reduces the number of rows accessed within the table. For example, take the IN-list predicate, FACT.C1 IN (1,2,3). When this is applied to the FACT table as in IN-list predicate it is applied to every row of the FACT table. However, if this predicate is used to probe the FACT table (either using an index on the FACT table or zone maps, etc.) then only those rows in the FACT table where C1 is equal to one of the three values will be accessed [outputting matching rows]…dynamic join sequence adjustment recognizes when an IN-list predicate can significantly and efficiently reduce the number of rows in a FACT table that need to be accessed and in such cases use the IN-list predicate to probe the FACT table. In cases where the IN-list predicate doesn't significantly reduce the number of rows accessed in the FACT table, the IN-list predicate is applied against FACT table rather than used to probe the FACT table…query execution module converts the distinct join key values of small, independent dimension tables into respective IN-list predicates 315 for run time application 440 to, or probing 447 of, fact table 320…query execution module generates a hash table 340 (and may also generate a bloom filter or sparse index.) for dimension table 310 unless it is deemed 415 independent and deemed 425 small and determined 430 not to have a payload required for the query. Thus, a hash table 340 is built 405 for each non-small, independent dimension table 310, each non-independent dimension table 310, and for each small, independent dimension table 310 that has a payload, regardless of whether they are deemed 445 to be the filtering type. Each such hash table 340 (and a bloom filter or sparse index) is for probing 410 with respect to fact table 320, i.e., in response to scanning of fact table 320 to find matches in hash table 340 according to the query...”),
Beavin does not expressly teach ‘…translating the plurality of first value identifiers into a value identifiers domain of the second table to form a shared translation table, wherein the shared translation table is formed using a first dictionary of the first table and a second dictionary of the second table'
However, Chainani teaches …translating the plurality of first value identifiers into a value identifiers domain of the second table to form a shared translation table, wherein the shared translation table is formed using a first dictionary of the first table and a second dictionary of the second table *see paras31-36(“…method 500 in which a dictionary is generated and used in a database system (e.g., database system 18) according to an embodiment…is illustrated in FIG. 5. The method 500 may start at block 502, in which a column of a first table may be selected as a candidate column to create a dictionary…techniques used to identify the parent/child or dimension/fact table relations in the database schema may include schema specified primary-foreign key relationship, query analysis, metadata analysis, or any combination thereof. Using the first table being a dimension table as an example, the techniques used to identify the most commonly accessed dimension table columns and dimension/fact joins may include work load analysis, user input, or other known techniques…block 504, the method 500 may tokenize a foreign key in a second table that corresponds to a primary key in the first table [translating first value identifiers into value identifiers domain of second table]. The foreign key in the second table and primary key in the first table may be, for example, the parent/child or dimension/fact table relation in the database schema identified in block 502. As described herein, the tokenization process may use any known or other dictionary tokenization techniques, such as but not limited to, Huffman coding, arithmetic coding, and static dictionaries…block 506, the method 500 may generate the dictionary for the column using the tokens created in block 504 as indexes into the dictionary. The created tokens may be the compression symbols as described…the dictionary may be for one column of the first table (e.g., DICT_A_Key 206, DICT_A_Value1 208 and DICT_A_Value2 210), multiple columns of the first table (e.g., DICT_A_MULTI 212), or all columns of the first table (e.g., a special case of DICT_A_MULTI 212). In case of the dictionary being created for more than one column, the method 500 may identify multiple candidate columns in block 502. In one embodiment, the dictionary may be referred to as a decoding dictionary or a compression dictionary…” teaches shared translation table formed using first dictionary of first table and second dictionary of second table, under the broadest reasonable interpretation of claim elements), paras20-30(“…A dictionary according to the present invention may be a compression dictionary used to effectively join column data of a first table (e.g., DIM_A 202) to a second table (e.g., FACT_F 204), thus avoiding the actual join operation(s). Each dictionary may translate a second table's foreign key (FK) to one column value. Column values corresponding to multiple foreign keys of a first table (e.g., DIM_A 202) may be retrieved through a dictionary and these retrieved values may further be treated as virtual columns of the second table (e.g., FACT_F 204), therefore enabling “denormalized” type query optimizations such as applying the combination of local predicates and join predicates (e.g., dimension predicates) directly to the second table as local predicates. Because the virtual column values are still looked up and not physically materialized, this approach may avoid some of the complications and overhead of true physical denormalization… One exemplary structure of a dictionary 214 according to the present invention is shown in FIG. 4. Each entry of the dictionary 214 may include a compression symbol 216 and a corresponding column value 218. The compression symbol 216 may be an index in the dictionary 214 associated with the corresponding column value 218...”),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Beavin to incorporate the teachings of Chainani and enable Beavin to form a shared translation table based on first value identifiers/first dictionary of first table and value identifiers domain/second dictionary of second table, as doing so would enable efficient join operations between two tables using compression dictionaries and virtual columns in the target table(s) (Chainani, paras30-36).
Regarding claim 2,
Beavin as modified by Chainani teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Beavin further teaches The computer-implemented method of claim 1, wherein a database execution engine detects the join of the first table and the second table. *see paras19-26(“FIG. 3…dimension table 310 and fact table 320 are shown [first/second table]. Although such dimension tables 310 are typically smaller than the fact table 320, joining them with fact table 320 is still resource intensive…For a hash join process, a hash table such as 340 is built for at least some rows of its respective dimension table 310 involved in the join process [detects join…first/second table]. A hash table 340 is created after scanning its dimension table 310. This is typically quick and efficient, but still requires probing the one or more hash tables based on rows in the fact table 320…additional join processes and structures are disclosed herein…some systems determine a range of values for a key column of an inner table, such as a dimension table 310, for example, and then apply the range as a predicate for a key column of an outer table, e.g., fact table 320…consider a query for sales on consecutive Black Fridays, where a date dimension table is joined with a sales fact table that has thirteen months of sales transactions [detects join first/second table]. Predicates on the date dimension table will reduce it to only two rows, one for each Black Friday…since the two Black Fridays are twelve months apart and the sales fact table has thirteen months of sales transactions, most of the dates in the sales fact table fall within the twelve month range of Black Friday dates…In another optimization example, consider the following context, wherein a table called “product” is designated as a dimension table and has 100 rows that each represent a product and has columns for productID, productName and productLaunchDate. A table called “sales” is designated as a fact table and has 5 million rows, each representing a sales transaction, where the columns are transactionID,… and productID. A business analyst wanting to understand the sales for the iMac product in year 2013 may issue the following query (referred to herein as “Query 1”):…a query execution module, such as an instance of module 224 in FIG. 2, for example, may select actions and sequence at run-time according to a hash join execution plan, in which the query execution module applies the specified predicate on productName and then builds a hash table with product.productID as the key [detects join first/second table]. Rows that are included in the hash table are those “surviving rows” of the product table having “iMac” in the product name column, i.e., those rows that satisfy the product.productName=‘iMac’ predicate…for performing a join process the query execution module dynamically selects one or more actions at run-time according to predetermined criteria, which may include selecting a sequence of actions…”)
Regarding claim 3,
Beavin as modified by Chainani teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Beavin further teaches The computer-implemented method of claim 1, wherein the join comprises an inner join of a first column of the first table and a second column of the second table. *see paras19-26(“FIG. 3…dimension table 310 and fact table 320 are shown. Although such dimension tables 310 are typically smaller than the fact table 320, joining them with fact table 320 is still resource intensive and is, accordingly, relatively slow. There are various ways to reduce resources consumed and increase speed of query execution. A hash join process is one way. For a hash join process, a hash table such as 340 is built for at least some rows of its respective dimension table 310 involved in the join process. A hash table 340 is created after scanning its dimension table 310...One or more optimization techniques are sometimes used to improve probing or scanning. For example, some systems determine a range of values for a key column of an inner table, such as a dimension table 310, for example, and then apply the range as a predicate for a key column of an outer table, e.g., fact table 320 [inner join of first column of first table and second column of second table]…consider a query for sales on consecutive Black Fridays, where a date dimension table is joined with a sales fact table that has thirteen months of sales transactions. Predicates on the date dimension table will reduce it to only two rows, one for each Black Friday. Nevertheless, since the two Black Fridays are twelve months apart and the sales fact table has thirteen months of sales transactions, most of the dates in the sales fact table fall within the twelve month range of Black Friday dates…consider the following context, wherein a table called “product” is designated as a dimension table and has 100 rows that each represent a product and has columns for productID,…productLaunchDate. A table called “sales” is designated as a fact table and has 5 million rows, each representing a sales transaction, where the columns are transactionID,…productID. A business analyst wanting to understand the sales for the iMac product in year 2013 may issue the following query (referred to herein as “Query 1”): select sum(transactionAmount) from sales, product where sales.productID=product.productID …between ‘Jan. 1, 2013’ and ‘Dec. 31, 2013’ [inner join…first column of first table and second column of second table] …For this query, a query execution module, such as an instance of module 224 in FIG. 2, for example, may select actions and sequence at run-time according to a hash join execution plan, in which the query execution module applies the specified predicate on productName and then builds a hash table with product.productID as the key. Rows that are included in the hash table are those “surviving rows” of the product table having “iMac” in the product name column, i.e., those rows that satisfy the product.productName=‘iMac’ predicate...”)
Regarding claim 4,
Beavin as modified by Chainani teaches all the claimed limitations as set forth in the rejection of claim 3 above.
Beavin further teaches The computer-implemented method of claim 3, wherein the first column includes the plurality of first value identifiers, and wherein the second column includes the plurality of second value identifiers. *see paras19-26(“FIG. 3…dimension table 310 and fact table 320 are shown…For a hash join process, a hash table such as 340 is built for at least some rows of its respective dimension table 310 involved in the join process. A hash table 340 is created after scanning its dimension table 310…some systems determine a range of values for a key column of an inner table, such as a dimension table 310, for example, and then apply the range as a predicate for a key column of an outer table, e.g., fact table 320 [first column includes first value identifiers, second column includes second value identifiers]…A table called “sales” is designated as a fact table and has 5 million rows, each representing a sales transaction, where the columns are transactionID,… productID. A business analyst wanting to understand the sales for the iMac product in year 2013 may issue the following query (referred to herein as “Query 1”): select sum(transactionAmount) from sales, product where sales.productID= product.productID and product.productName=‘iMac’ and sales.transactionDate between…For this query, a query execution module, such as an instance of module 224 in FIG. 2, for example, may select actions and sequence at run-time according to a hash join execution plan, in which the query execution module applies the specified predicate on productName and then builds a hash table with product.productID as the key. Rows that are included in the hash table are those “surviving rows” of the product table having “iMac” in the product name column, i.e., those rows that satisfy the product.productName=‘iMac’ predicate…For example, the query execution module may apply one or more relevant predicates of the query to one or more relatively small dimension tables 310 at run-time. FIG. 3 shows applying a predicate to dimension table 310 at run-time, wherein the query execution module scans dimension table 310 to apply the predicate 330 and may also generate hash table 340. Then, using the results of applying the one or more predicates, the query execution module may also at run-time convert the results into one or more respective IN-list predicates for run-time probing of, or application to, larger, fact table 320. To illustrate the meaning of “IN-list predicate,” consider tables having a “firstName” column that contains first names. For selecting rows in table 320 that include first names John, Jack and Rick, for example, an IN-list predicate could be stated as follows, according to an example syntax: firstName IN {‘John’, ‘Jack’, ‘Rick’}. [firstName teaches first column includes first value identifiers, second column includes second value identifiers]”),
Regarding claim 6,
Beavin as modified by Chainani teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Beavin further teaches The computer-implemented method of claim 1, wherein the building of the hash table comprises inserting the translated plurality of first value identifiers into the hash table. *see paras19-26(“FIG. 3 illustrates data structures and aspects of query execution…dimension table 310 and fact table 320 are shown…hash table such as 340 is built for at least some rows of its respective dimension table 310 involved in the join process. A hash table 340 is created after scanning its dimension table 310. This is typically quick and efficient, but still requires probing the one or more hash tables based on rows in the fact table 320…some systems determine a range of values for a key column of an inner table, such as a dimension table 310, for example, and then apply the range as a predicate for a key column of an outer table, e.g., fact table 320 [‘building of the hash table… inserting translated plurality of first value identifiers…’]…a Bloom filter and the range predicate may be applied…FIG. 3 shows applying a predicate to dimension table 310 at run-time, wherein the query execution module scans dimension table 310 to apply the predicate 330 and may also generate hash table… using the results of applying the one or more predicates, the query execution module may also at run-time convert the results into one or more respective IN-list predicates for run-time probing of, or application to, larger, fact table 320…consider tables having a “firstName” column that contains first names. For selecting rows in table 320 that include first names John, Jack and Rick, for example, an IN-list predicate could be stated as follows, according to an example syntax: firstName IN {‘John’, ‘Jack’, ‘Rick’}....”), paras28-35(“…FIG. 3 shows two rows of table 310 that survive application of the predicate, for example, and shows a query execution module responsively generating a hash table 340 for the payload column of the two surviving rows of dimension table 310. FIG. 3 also shows the query execution module converting those two rows into an IN-list predicate 315 at run-time. FIG. 3 also shows the query execution module applying the IN-list predicate 315 at run-time to fact table 320, yielding one surviving row. FIG. 3 shows probing hash table 340, using the join key value of the surviving row of fact table 320, to find a matching value from the payload column of dimension table…applying predicates to dimension tables 310 at run-time and then converting those results into IN-list predicates for application at run-time to a fact table 320 can greatly improve join processing time…A Bloom filter may also be created by query execution module to reduce the number of non-matching probes into hash tables. A bloom filter is an approximate filter that may have false positive rows that survive probing, but which are then eliminated during hash table look up. That is, responsive to scanning of a dimension table, a query execution module may generate a bloom filter and a hash table for rows of the dimension table that survive predicate application [‘building of the hash table… inserting translated plurality of first value identifiers…’]...”),
Regarding claim 7,
Beavin as modified by Chainani teaches all the claimed limitations as set forth in the rejection of claim 1 above.
Beavin further teaches The computer-implemented method of claim 1, wherein the plurality of second value identifiers are filtered by a filter, wherein the filter detects whether or not the translated plurality of first value identifiers in the plurality of second value identifiers. *see para19-24(“…optimization techniques are sometimes used to improve probing or scanning…determine a range of values for a key column of an inner table, such as a dimension table 310, for example, and then apply the range as a predicate for a key column of an outer table, e.g., fact table 320. Alternatively, both a Bloom filter and the range predicate may be applied….”), paras34-36(“...A Bloom filter may also be created by query execution module to reduce the number of non-matching probes into hash tables. A bloom filter is an approximate filter that may have false positive rows that survive probing, but which are then eliminated during hash table look up. That is, responsive to scanning of a dimension table, a query execution module may generate a bloom filter and a hash table for rows of the dimension table that survive predicate application. Prior to probing the hash table, the query execution module probes bloom filter to determine whether each row of the probing can be discarded…computing minimum and maximum join key values on a dimension table and then building a bloom filter and a hash table, the query execution module selectively performs one or more additional actions 415-445…”), para44(“...Also regardless of whether they are deemed to be the filtering type, the query execution module generates a hash table 340 (and may also generate a bloom filter or sparse index in build process stage 405) for dimension table 310 unless it is deemed 415 independent and deemed 425 small and determined 430 not to have a payload required for the query. Thus, a hash table 340 is built 405 for each non-small, independent dimension table 310, each non-independent dimension table 310, and for each small, independent dimension table 310 that has a payload, regardless of whether they are deemed 445 to be the filtering type. Each such hash table 340 (and a bloom filter or sparse index) is for probing 410 with respect to fact table 320, i.e., in response to scanning of fact table 320 to find matches in hash table 340 according to the query”)
Regarding claim 8,
Beavin as modified by Chainani teaches all the claimed limitations as set forth in the rejection of claim 7 above.
Beavin further teaches The computer-implemented method of claim 7, wherein the filter comprises a bloom filter. *see para19-24(“…determine a range of values for a key column of an inner table, such as a dimension table 310, for example, and then apply the range as a predicate for a key column of an outer table, e.g., fact table 320. Alternatively, both a Bloom filter and the range predicate may be applied….”), paras34-36(“...A Bloom filter may also be created by query execution module to reduce the number of non-matching probes into hash tables. A bloom filter is an approximate filter that may have false positive rows that survive probing, but which are then eliminated during hash table look up. That is, responsive to scanning of a dimension table, a query execution module may generate a bloom filter and a hash table for rows of the dimension table that survive predicate application. Prior to probing the hash table, the query execution module probes bloom filter to determine whether each row of the probing can be discarded… computing minimum and maximum join key values on a dimension table and then building a bloom filter and a hash table, the query execution module selectively performs one or more additional actions 415-445…”), para44(“...Also regardless of whether they are deemed to be the filtering type, the query execution module generates a hash table 340 (and may also generate a bloom filter or sparse index in build process stage 405) for dimension table 310 unless it is deemed 415 independent and deemed 425 small and determined 430 not to have a payload required for the query. Thus, a hash table 340 is built 405 for each non-small, independent dimension table 310, each non-independent dimension table 310, and for each small, independent dimension table 310 that has a payload, regardless of whether they are deemed 445 to be the filtering type. Each such hash table 340 (and a bloom filter or sparse index) is for probing 410 with respect to fact table 320, i.e., in response to scanning of fact table 320 to find matches in hash table 340 according to the query”)
Regarding claim 9,
Claim 9 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 10,
Claim 10 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 11,
Claim 11 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 12,
Claim 12 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 14,
Claim 14 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 15,
Claim 15 recites substantially the same claim limitations as claim 7 and is rejected for the same reasons.
Regarding claim 16,
Claim 16 recites substantially the same claim limitations as claim 8 and is rejected for the same reasons.
Regarding claim 17,
Claim 17 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 18,
Claim 18 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 19,
Claim 19 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 20,
Claim 20 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Conclusion
The prior art made of record in PTO-892 and not relied upon is considered pertinent to applicant's disclosure.
THIS ACTION IS MADE FINAL. 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 extension fee 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 ANUGEETHA KUNJITHAPATHAM whose telephone number is (408)918-7510. The examiner can normally be reached M-F 9-5 PT.
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, Aleksandr Kerzhner can be reached at (571) 270-1760. 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.
/A.K./Examiner, Art Unit 2165
/ALEKSANDR KERZHNER/Supervisory Patent Examiner, Art Unit 2165