CTNF 18/559,010 CTNF 94113 DETAILED ACTION This office action is in response to the above identified application filed on November 03, 2023. A preliminary amendment filed concurrently amended the specification and claim 14. The application contains claims 1-14, wherein Claims 1-14 are pending Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Priority The present application is a National Stage entry of PCT/CN2023/077058, International Filing Date: 02/20/2023, that claims foreign priority to 202210316593.7, filed 03/28/2022. Information Disclosure Statement 06-52 The information disclosure statement (IDS) was submitted on April 17, 2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Specification The disclosure is objected to because of the use of the language “The present disclosure relates to …”. 06-16 AIA Applicant is reminded of the proper language and format for an abstract of the disclosure. The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details. The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided. Claim Objections Claim 10 is objected to because of the following informalities: Claim 10, line 2: “and/or” should read either “and” or “or”. Appropriate correction is required. See MPEP § 2173.05(i) . Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 AIA Claim 12 is 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 pre-AIA the applicant regards as the invention. Claim 12 recites the limitation "the write plugin" in line 1. There is insufficient antecedent basis for this limitation in the claim. Therefore, claim 12 is indefinite and rejected under 35 U.S.C. 112(b). Claim Rejections - 35 USC § 101 07-04-01 AIA 07-04 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 8-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claims 8-13 do not fall within at least one of the four categories of patent eligible subject matter because the claimed invention is software per se. Claim 8 recites a system comprising “a source database”, “a target database”, and “a data synchronization apparatus”. The disclosure does not indicate that “a source database”, “a target database”, or “a data synchronization apparatus” is necessarily hardware. The broadest reasonable interpretation of these components in light of the specification includes computer instructions only, which make it software per se. Therefore, claim 8 is rejected under 35 U.S.C. 101. Dependent claims 9-13 do not add any structure to the claims and are likewise rejected under 35 U.S.C. 101. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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 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. 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-3, 8-10, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over WU & FAN (CN 110781243 A) , in view of WU (CN 107172112 A) . With regard to claim 1 , WU & FAN teaches a method for data synchronization, applied to a system for data synchronization (Page 1, Abstract) , wherein the method comprises: obtaining initial source data from a source database (Page 1, Abstract: obtain to-be-synchronized data sent by the first database) ; obtain target source data containing a primary key of the initial source data (Page 1, Abstract: search a first data main key comprised in the to-be-synchronized data in a source main key list of a second database; if a matching target source main key is not found in the source main key list, create a target source main key field in the source main key list, initialize the value of the field corresponding to the first data main key in the second database, and synchronize the to-be-synchronized data into the second database. The to-be-synchronized data along with the matching target source main key corresponds to “target source data containing a primary key”) ; and synchronizing the target source data to a target database, to enable the target source data to be stored in the target database after a verification for the primary key is passed (Page 1, Abstract: synchronize the to-be-synchronized data into the second database if a matching target source main key is not found in the source main key list. Searching in a source main key list of a second database to determine a matching target source main key is not found in the source main key list corresponds to “a verification for the primary key is passed”) . WU & FAN does not teach generating fingerprint data for the initial source data to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data; WU teaches generating fingerprint data for the initial source data to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data (Page 4, lines 14-23: calculate the MD5 value of the file to be transmitted and try to write the MD5 value of the file to be transferred into the preset database as the primary key value of the database table. Page 5, lines 14-18: Message Digest Algorithm MD5 (MD5) is a logic operation used to generate a hash value of the file, the unique identifier MD5 value) ; 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 WU & FAN to incorporate the teachings of WU to generate fingerprint data for the initial source data to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data. Doing so would determine whether two files are the same file or two different documents by using the unique identifier of the file before transmitting a to-be-transmitted file to a receiving end to avoid processing resource waste as taught by WU (Page 5, lines 9-13; Page 1, Abstract) . With regard to claim 2 , As discussed in claim 1, WU & FAN and WU teach all the limitations therein. WU further teaches the method according to claim 1, wherein generating the fingerprint data for the initial source data comprises: calling a preset fingerprint generating model; and inputting the initial source data to the fingerprint generating model, to obtain the fingerprint data (Page 5, lines 14-18: use Message Digest Algorithm MD5 (MD5) to generate a unique identifier MD5 value for the input file. Message Digest Algorithm MD5 (MD5) implicitly teaches “a preset fingerprint generating model” that implements the algorithm, and MD5 corresponds to “the fingerprint data”) . With regard to claim 3 , As discussed in claim 2, WU & FAN and WU teach all the limitations therein. WU further teaches the method according to claim 2, wherein the preset fingerprint generating model can be implemented by using at least one of a message digest algorithm, a secure hash algorithm, a message authentication code algorithm, or a key-based message authentication code algorithm (Page 5, lines 14-18: Message Digest Algorithm MD5 (MD5)) . With regard to claim 8 , WU & FAN teaches a system for data synchronization (Page 1, Abstract) , comprising a source database, a target database, and a data synchronization apparatus (Page 1, Abstract: a first database, a second database, and a synchronization system) ; wherein the data synchronization apparatus is configured to: obtain initial source data from the source database (Page 1, Abstract: obtain to-be-synchronized data sent by the first database) ; obtain target source data containing a primary key of the initial source data (Page 1, Abstract: search a first data main key comprised in the to-be-synchronized data in a source main key list of a second database; if a matching target source main key is not found in the source main key list, create a target source main key field in the source main key list, initialize the value of the field corresponding to the first data main key in the second database, and synchronize the to-be-synchronized data into the second database. The to-be-synchronized data along with the matching target source main key corresponds to “target source data containing a primary key”) ; and synchronize the target source data to the target database to store the target source data after a verification for the primary key is passed (Page 1, Abstract: synchronize the to-be-synchronized data into the second database if a matching target source main key is not found in the source main key list. Searching in a source main key list of a second database to determine a matching target source main key is not found in the source main key list corresponds to “a verification for the primary key is passed”) . WU & FAN does not teach generate fingerprint data for the initial source data, to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data; WU teaches generate fingerprint data for the initial source data, to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data (Page 4, lines 14-23: calculate the MD5 value of the file to be transmitted and try to write the MD5 value of the file to be transferred into the preset database as the primary key value of the database table. Page 5, lines 14-18: Message Digest Algorithm MD5 (MD5) is a logic operation used to generate a hash value of the file, the unique identifier MD5 value) ; 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 WU & FAN to incorporate the teachings of WU to generate fingerprint data for the initial source data to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data. Doing so would determine whether two files are the same file or two different documents by using the unique identifier of the file before transmitting a to-be-transmitted file to a receiving end to avoid processing resource waste as taught by WU (Page 5, lines 9-13; Page 1, Abstract) . With regard to claim 9 , As discussed in claim 8, WU & FAN and WU teach all the limitations therein. WU & FAN and WU further teach the system according to claim 8, wherein the data synchronization apparatus comprises a Framework module, a fingerprint data generating module, a read plugin, and a write plugin (see discussion below) , wherein the Framework module is separately connected to the read plugin and the write plugin, wherein the read plugin is configured to read the initial source data to be synchronized from the source database ( WU & FAN , Page 7, lines 32-33: the obtaining module 10 is configured to obtain data to be synchronized sent by the first database) ; the fingerprint data generating module is configured to generate fingerprint data for the initial source data and use the fingerprint data as the primary key of the initial source data ( WU , Page 9, lines 17-26: the identifier obtaining subunit and the identifier writing subunit) ; the Framework module is configured to forward the initial source data and the primary key together as the target source data to the write plugin ( WU & FAN , Page 7, lines 34-36: the matching module 20 is configured to search a source primary key list of the second database for a target source primary key that matches the primary key of the first data) ; and the write plugin is configured to write the target source data to the target database ( WU & FAN , Page 7, lines 37-41: a primary key conversion module 30 is configured to create a target source primary key field in the source primary key list if the target source primary key is not found in the source primary key list, initialize the value of the field corresponding to the first data primary key in the second database, and synchronize data to the second database) . With regard to claim 10 , As discussed in claim 9, WU & FAN and WU teach all the limitations therein. WU further teaches the system according to claim 9, wherein the fingerprint data generating module is integrated into the read plugin and/or the Framework module (Page 9, lines 17-26: the identifier obtaining subunit, which is configured to obtain a unique identifier of the file to be transmitted, is a part of the first execution judgment unit 31) . With regard to claim 14 , WU & FAN teaches a non-transitory computer-readable storage medium, wherein when an executable computer program in the storage medium is executed by a processor (Page 8, lines 15-17: a processor) , a method for data synchronization is implemented, wherein, the method is applied to a system for data synchronization (Page 1, Abstract) , and comprises: obtaining initial source data from a source database (Page 1, Abstract: obtain to-be-synchronized data sent by the first database) ; obtain target source data containing a primary key of the initial source data (Page 1, Abstract: search a first data main key comprised in the to-be-synchronized data in a source main key list of a second database; if a matching target source main key is not found in the source main key list, create a target source main key field in the source main key list, initialize the value of the field corresponding to the first data main key in the second database, and synchronize the to-be-synchronized data into the second database. The to-be-synchronized data along with the matching target source main key corresponds to “target source data containing a primary key”) ; and synchronizing the target source data to a target database, to enable the target source data to be stored in the target database after a verification for the primary key is passed (Page 1, Abstract: synchronize the to-be-synchronized data into the second database if a matching target source main key is not found in the source main key list. Searching in a source main key list of a second database to determine a matching target source main key is not found in the source main key list corresponds to “a verification for the primary key is passed”) . WU & FAN does not teach generating fingerprint data for the initial source data to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data; WU teaches generating fingerprint data for the initial source data to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data (Page 4, lines 14-23: calculate the MD5 value of the file to be transmitted and try to write the MD5 value of the file to be transferred into the preset database as the primary key value of the database table. Page 5, lines 14-18: Message Digest Algorithm MD5 (MD5) is a logic operation used to generate a hash value of the file, the unique identifier MD5 value) ; 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 WU & FAN to incorporate the teachings of WU to generate fingerprint data for the initial source data to obtain target source data containing the fingerprint data, wherein the fingerprint data serves as a primary key of the initial source data. Doing so would determine whether two files are the same file or two different documents by using the unique identifier of the file before transmitting a to-be-transmitted file to a receiving end to avoid processing resource waste as taught by WU (Page 5, lines 9-13; Page 1, Abstract) . 07-21-aia AIA Claim s 4, 5, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over WU & FAN (CN 110781243 A) , in view of WU (CN 107172112 A) , and in further view of Morgan et al. (US 20200265027 A1) . With regard to claim 4 , As discussed in claim 1, WU & FAN and WU teach all the limitations therein. WU & FAN and WU do not teach the method according to claim 1, wherein synchronizing the target source data to the target database comprises: generating verification fingerprint data based on the initial source data in the target source data; and in response to determining that the primary key in the target source data is the same as the verification fingerprint data, transmitting the target source data to the target database. Morgan teaches the method according to claim 1, wherein synchronizing the target source data to the target database comprises: generating verification fingerprint data based on the initial source data in the target source data; and in response to determining that the primary key in the target source data is the same as the verification fingerprint data, transmitting the target source data to the target database ([0063]: when a submission, query, or deletion request is received by the collaboration platform that specifies a particular key-value pair, a hash is generated for the particular property key-value pair included in the request and compared to stored hash values of property key-value pairs. In response to determining that the hash value of the particular property key-value pair that was included in the request matches a stored hash value, such as the stored hash value of the property key-value pair, the collaboration platform executes an operation specified by the request such as deletion or returning requested data) . 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 WU & FAN and WU to incorporate the teachings of Morgan to generate verification fingerprint data based on the initial source data in the target source data and in response to determining that the primary key in the target source data is the same as the verification fingerprint data, transmit the target source data to the target database. Doing so would provide a layer of security when storing properties from multiple vendors and/or integrations. By hashing properties as they are stored in an integration database, anyone with access to the integration database is prevented from viewing and tampering with sensitive organizational data that is stored as properties as taught by Morgan ([0063]) . With regard to claim 5 , As discussed in claim 4, WU & FAN and WU and Morgan teach all the limitations therein. WU & FAN further teaches the method according to claim 4, further comprising: obtaining, by the target database, the primary key in the target source data (Page 7, lines 32-33: obtain data to be synchronized sent by the first database; the data to be synchronized includes a first data primary key) ; and determining whether there is a primary key of stored data that is matched with the primary key in the target source data (Page 7, lines 34-36: search a source primary key list of the second database for a target source primary key that matches the primary key of the first data) ; in response to determining that the primary key of the target source data exists in the target database, updating the target source data to the target database (Page 8, lines 5-6: if the target source primary key is found in the source primary key list, directly synchronize the data to be synchronized to the second database) ; in response to determining that the primary key of the target source data does not exist in the target database, inserting the target source data into the target database (Page 7, lines 37-41: if the target source primary key is not found in the source primary key list, initialize the value of the field corresponding to the first data primary key in the second database. The synchronization data is synchronized to the second database) . With regard to claim 11 , As discussed in claim 1, WU & FAN and WU teach all the limitations therein. WU & FAN and WU do not teach the system according to claim 9, wherein the fingerprint data generating module is integrated into the write plugin for generating verification fingerprint data based on the initial source data in the target source data, and the write plugin is further configured to: compare the primary key in the target source data with the verification fingerprint data; and transmit the target source data to the target database in response to determining that the primary key is the same as the verification fingerprint data. Morgan teaches the system according to claim 9, wherein the fingerprint data generating module is integrated into the write plugin for generating verification fingerprint data based on the initial source data in the target source data, and the write plugin is further configured to: compare the primary key in the target source data with the verification fingerprint data; and transmit the target source data to the target database in response to determining that the primary key is the same as the verification fingerprint data ([0063]: when a submission, query, or deletion request is received by the collaboration platform that specifies a particular key-value pair, a hash is generated for the particular property key-value pair included in the request and compared to stored hash values of property key-value pairs. In response to determining that the hash value of the particular property key-value pair that was included in the request matches a stored hash value, such as the stored hash value of the property key-value pair, the collaboration platform executes an operation specified by the request such as deletion or returning requested data) . 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 WU & FAN and WU to incorporate the teachings of Morgan to generate verification fingerprint data based on the initial source data in the target source data and in response to determining that the primary key in the target source data is the same as the verification fingerprint data, transmit the target source data to the target database. Doing so would provide a layer of security when storing properties from multiple vendors and/or integrations. By hashing properties as they are stored in an integration database, anyone with access to the integration database is prevented from viewing and tampering with sensitive organizational data that is stored as properties as taught by Morgan ([0063]) . 07-21-aia AIA Claim s 6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over WU & FAN (CN 110781243 A) , in view of WU (CN 107172112 A) , and in further view of TARANOV (US 20210406229 A1) . With regard to claim 6 , As discussed in claim 1, WU & FAN and WU teach all the limitations therein. WU & FAN and WU do not teach the method according to claim 1, wherein synchronizing the target source data to the target database comprises: obtaining first fingerprint data of data columns other than a newly added data column and second fingerprint data of data columns containing the newly added data column; determining whether there is a primary key in the target database that is matched with the first fingerprint data; and in response to determining that the primary key of the target source data exists in the target database, updating the target source data and the second fingerprint data to the target database. TARANOV teaches the method according to claim 1, wherein synchronizing the target source data to the target database comprises: obtaining first fingerprint data of data columns other than a newly added data column and second fingerprint data of data columns containing the newly added data column; determining whether there is a primary key in the target database that is matched with the first fingerprint data; and in response to determining that the primary key of the target source data exists in the target database, updating the target source data and the second fingerprint data to the target database (Fig. 3a; [0051]; Fig. 3d; [0055]: migration tables 330 and 340 have a field that specifies the old identifier utilized by such a primary key, namely in the source database 110, and the new identifier utilized by such a primary key, namely in the destination database 130. The added record 381 in migration table 340 can identify the old identifier of the primary key, maybe the identifier utilized in the source database 110, and the new identifier of the primary key that was assigned when the record was merged into the destination database 130, such as in the form of the record 372. In such a manner, the tree-traversing migration component 170 can perform migration of delineated data between two relational databases. The migration table teaches the mapping or matching between the primary keys in the source and the target, and the migration that follows teaches the updating the target database with the source data. The only difference is primary keys are used instead of fingerprints. Since using fingerprints in the claimed context is taught by prior art as discussed in the parent claim, and both primary keys and fingerprints can uniquely identify each record in the source and target databases, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have used fingerprints in place of primary keys to arrive at the claimed invention) . 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 WU & FAN and WU to incorporate the teachings of TARANOV to obtain first fingerprint data of data columns other than a newly added data column and second fingerprint data of data columns containing the newly added data column, determine whether there is a primary key in the target database that is matched with the first fingerprint data, and in response to determining that the primary key of the target source data exists in the target database, update the target source data and the second fingerprint data to the target database. Doing so would provide a schema agnostic mechanism for migrating delineated data between relational databases to address the problems of complexity and schema-specific relational database migration mechanisms as taught by TARANOV ([0004]) . With regard to claim 12 , As discussed in claim 8, WU & FAN and WU teach all the limitations therein. WU & FAN and WU do not teach the system according to claim 8, wherein the write plugin in the data synchronization apparatus is further configured to: obtain first fingerprint data of data columns other than a newly added data column and second fingerprint data of data columns containing the newly added data column; determine whether there is a primary key in the target database that is matched with the first fingerprint data; and in response to determining that the primary key of the target source data exists in the target database, update the target source data and the second fingerprint data to the target database. TARANOV teaches the system according to claim 8, wherein the write plugin in the data synchronization apparatus is further configured to: obtain first fingerprint data of data columns other than a newly added data column and second fingerprint data of data columns containing the newly added data column; determine whether there is a primary key in the target database that is matched with the first fingerprint data; and in response to determining that the primary key of the target source data exists in the target database, update the target source data and the second fingerprint data to the target database (Fig. 3a; [0051]; Fig. 3d; [0055]: migration tables 330 and 340 have a field that specifies the old identifier utilized by such a primary key, namely in the source database 110, and the new identifier utilized by such a primary key, namely in the destination database 130. The added record 381 in migration table 340 can identify the old identifier of the primary key, maybe the identifier utilized in the source database 110, and the new identifier of the primary key that was assigned when the record was merged into the destination database 130, such as in the form of the record 372. In such a manner, the tree-traversing migration component 170 can perform migration of delineated data between two relational databases. The migration table teaches the mapping or matching between the primary keys in the source and the target, and the migration that follows teaches the updating the target database with the source data. The only difference is primary keys are used instead of fingerprints. Since using fingerprints in the claimed context is taught by prior art as discussed in the parent claim, and both primary keys and fingerprints can uniquely identify each record in the source and target databases, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have used fingerprints in place of primary keys to arrive at the claimed invention) . 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 WU & FAN and WU to incorporate the teachings of TARANOV to obtain first fingerprint data of data columns other than a newly added data column and second fingerprint data of data columns containing the newly added data column, determine whether there is a primary key in the target database that is matched with the first fingerprint data, and in response to determining that the primary key of the target source data exists in the target database, update the target source data and the second fingerprint data to the target database. Doing so would provide a schema agnostic mechanism for migrating delineated data between relational databases to address the problems of complexity and schema-specific relational database migration mechanisms as taught by TARANOV ([0004]) . Allowable Subject Matter Claims 7 and 13 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims and overcoming all the objections and rejections set forth in this office action above. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to XIAOQIN HU whose telephone number is (571)272-1792. The examiner can normally be reached on Monday-Friday 7:00am-3:30pm. 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, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /XIAOQIN HU/Examiner, Art Unit 2168 /CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168 Application/Control Number: 18/559,010 Page 2 Art Unit: 2168 Application/Control Number: 18/559,010 Page 3 Art Unit: 2168 Application/Control Number: 18/559,010 Page 5 Art Unit: 2168 Application/Control Number: 18/559,010 Page 6 Art Unit: 2168 Application/Control Number: 18/559,010 Page 7 Art Unit: 2168 Application/Control Number: 18/559,010 Page 8 Art Unit: 2168 Application/Control Number: 18/559,010 Page 9 Art Unit: 2168 Application/Control Number: 18/559,010 Page 10 Art Unit: 2168 Application/Control Number: 18/559,010 Page 11 Art Unit: 2168 Application/Control Number: 18/559,010 Page 12 Art Unit: 2168 Application/Control Number: 18/559,010 Page 13 Art Unit: 2168 Application/Control Number: 18/559,010 Page 14 Art Unit: 2168 Application/Control Number: 18/559,010 Page 15 Art Unit: 2168 Application/Control Number: 18/559,010 Page 16 Art Unit: 2168 Application/Control Number: 18/559,010 Page 17 Art Unit: 2168 Application/Control Number: 18/559,010 Page 18 Art Unit: 2168 Application/Control Number: 18/559,010 Page 19 Art Unit: 2168 Application/Control Number: 18/559,010 Page 20 Art Unit: 2168
Prosecution Insights