DETAILED ACTION
This Office Action, based on application 18/331,087 filed 7 June 2023, is filed in response to applicant’s amendment and remarks entered 10 November 2025. Claims 36-55 are currently pending and have been fully considered below.
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10 December 2025 has been entered.
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
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.
Response to Arguments
Applicant’s remarks, submitted 11 November 2025 in response to the Office Action mailed 10 September 2025, have been fully considered below.
Claim Rejections under 35 U.S.C. § 103
The applicant traverses the prior art rejection to Claim 36 (and similarly Claims 43, 50, and respective dependent claims) alleging cited prior art fails to disclose “receive, via an interface of the non-relational database service, a request specifying a value that updates a number of request units over time available to consume when performing requests to the database to increase throughput for the database” and “automatically create two or more new partitions of the database hosted by the non-relational database service until a number of new partitions, determined according to the value, is created that supports the number of request units over time available to consume when performing requests to the database specified by the request”. The Office has fully considered applicant’s remarks; however, is not persuaded for reasons now presented in the instant rejection of record. The applicant alleges the Office Action fails to cite a portion of ZENG where a request specifies the ‘expected rate of requests’ let alone a ’value’ as recited in the claim amendment. In response, the Office asserts the determination of the expected rate of requests meeting a threshold for repartitioning and subsequent decision by the metadata server to instruct the nodes to split a partition, for reasons explicitly or implied by ZENG, is analogous to applicant’s claimed ‘a request’. As such, the Office asserts cited prior art provides some teaching, suggestion, or motivation in the prior art that would lead a person of ordinary skill in the art to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Please note that MPEP § 804 states: “A complete response to a nonstatutory double patenting (NSDP) rejection is either a reply by applicant showing that the claims subject to the rejection are patentably distinct from the reference claims or the filing of a terminal disclaimer in accordance with 37 CFR 1.321 in the pending application(s) with a reply to the Office action (see MPEP § 1490 for a discussion of terminal disclaimers). Such a response is required even when the nonstatutory double patenting rejection is provisional. As filing a terminal disclaimer, or filing a showing that the claims subject to the rejection are patentably distinct from the reference application’s claims, is necessary for further consideration of the rejection of the claims, such a filing should not be held in abeyance. Only objections or requirements as to form not necessary for further consideration of the claims may be held in abeyance until allowable subject matter is indicated. Replies with an omission should be treated as provided in MPEP § 714.03. “
Claims 36-55 are rejected on the ground of nonstatutory double patenting as being unpatentable over respective claims of U.S. Patent No. 9,052,831 (PARENT) in view of RANSIL et al (US PGPub 2007/0168336) and ZENG et al (US PGPub 2011/0289049).
Instant Application
Claim 36
(and similarly Claims 43 and 50)
US Patent 9,052,831
Claim 3
A system, comprising:
A system, comprising:
a plurality of computing devices, respectively comprising at least one processor and a memory, that implement a non-relational database service;
a plurality of computing nodes, each comprising at least one processor and memory, wherein the plurality of computing nodes is configured to implement a data storage service; wherein the data storage service provides a service interface through which service requests are received; wherein the data storage service maintains a plurality of tables in a data store on behalf of one or more storage service clients, and wherein maintaining the plurality of tables comprises maintaining a plurality of partitions of table data, wherein a respective two or more replicas of each partition of the plurality of partitions of the table data are stored on respective computing nodes in the data store;
wherein the non-relational database service is configured to:
wherein the data storage service is configured …
receive, via an interface of the non-relational database service, a request specifying a value that updates a number of request units over time available to consume when performing requests to the database to increase throughput for the database;
wherein said issuing the split command comprises calling an operation defined in an application programming interface of the data storage service
automatically create two or more new partitions of the database hosted by the non-relational database service until a number of new partitions, determined according to the value, is created that supports the number of request units over time available to consume when performing requests to the database specified in the request, wherein a current partition of the database is stored on a plurality of storage nodes that implement a replica group for the current partition, and wherein automatically creating the two or more new partition comprises:
to detect that a particular partition of the plurality of partitions is being targeted by a higher number of service requests than one or more other partitions of the plurality of partitions; wherein in response to said detecting, the data storage service is configured to split the particular partition into two or more new partitions, each of which maintains a respective portion of the table data that was stored for the particular partition,
split the data stored in the current partition of the database to respectively add different portions of the data to the two or more new partitions of the database, wherein different respective plurality of nodes implement new replica groups for the two or more new partitions; and
wherein said splitting comprises: creating two or more destination replicas for the particular partition, wherein said creating comprises copying the table data of the particular partition to the two or more new destination replicas, wherein at least one of the two or more replicas of the particular partition is available for servicing requests directed to the particular partition during said creating; issuing a split command that: assigns each of the two or more replicas of the particular partition and the two or more destination replicas of the particular partition to different ones of two or more new replica groups in order to divide the two or more replicas and the two or more destination replicas into the two or more new replica groups; respectively configures the two or more new replica groups to service requests for different portions of the particular partition, wherein the different portions of the particular partition serviced at each of the two or more new replica groups is less than an amount of the particular partition respectively maintained at the assigned replicas in each of the two or more new replica groups prior to the issuing of the split command;
receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed.
and subsequent to said splitting, the data storage service is configured to direct service requests targeting items in different portions of the table data that was stored for the particular partition to a respective one of the two or more new replica groups that service requests for the portion of the particular partition including the targeted items.
At the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of the PARENT and RANSIL before him or her, to modify the system of the PARENT to include the claimed “receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed” as analogously taught by RANSIL (¶[0217]-— updates may be received and applied to the original partition while using the lazy replication mechanism of the replication of partitions) such that the claims of the PARENT are not patentably distinct from the claims of the instant application. A motivation for combining the lazy replication mechanism of RANSIL with the PARENT would have been to incorporate a mechanism to propagate updates to partitions being replicated without locking access to the source partition (¶[0217]).
Furthermore, at the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of PARENT and ZENG before him or her, to modify the creation of multiple partitions responsive to an increase in service requests of the PARENT to include the claimed “automatically create two or more new partitions … , determined according to the value, to support the number of request units over time available to consume when performing requests to the database specified in the request” as analogously taught by ZENG (¶[0020]—metadata may be divided as the expected rate of requests for metadata increases) such that the claims of the PARENT are not patentably distinct from the claims of the instant application. A motivation for changing the criteria for partition creation and splitting of the PARENT would have been to perform load balancing on the database so that service loads may be distributed across partitions when hot spots are created due to access bursting.
Instant Application
Claim 37
(and similarly Claims 44 and 51)
US Patent 9,052,831
Claim 3
The system of claim 36,
The system of Claim 3
wherein the non-relational database service is further configured to monitor a size of the data stored in the current partition for an increase in the size of the data stored in the current partition.
… wherein the data storage service is configured to detect that a particular partition of the plurality of partitions is being targeted by a higher number of service requests than one or more other partitions of the plurality of partitions … (a POSITA would conclude that one would need to monitor in order to detect)
The addition of the claimed “receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed’, as recited in the Parent Claims 36, 48, and 50, would be an obvious variant of the invention defined by the PARENT for reasons noted in conjunction with the double patenting rejection to the parent claims.
Instant Application
Claim 38
(and similarly Claims 45 and 52)
US Patent 9,052,831
Claim 3
The system of claim 36,
The system of Claim 3
wherein the current partition of the database is determined according to a key specified in a request to the non-relational database service.
The addition of the claimed “receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed’, as recited in the Parent Claims 36, 48, and 50, would be an obvious variant of the invention defined by the PARENT for reasons noted in conjunction with the double patenting rejection to the parent claims.
At the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of the PARENT and RANSIL before him or her, to modify the system of the PARENT to include the claimed “wherein the current partition of the database is determined according to a key specified in a request to the non-relational database service” as analogously taught by RANSIL (¶[0056] – database systems may be configured to use key-value pairs that may be used to create indexes to tables and other data structures) such that the claims of the PARENT are not patentably distinct from the claims of the instant application. A motivation for combining the use of an open source embedded database system of RANSIL with the PARENT APPLICATION would have been to make indexed search available on the web and to make it easy for developers to add search capability to their applications (¶[0057]).
Instant Application
Claim 39
(and similarly Claims 46 and 53)
US Patent 9,052,831
Claim 3
The system of claim 38,
The system of Claim 3
wherein the key uniquely identifies items in the database.
The addition of the claimed “receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed’, as recited in the Parent Claims 36, 48, and 50, would be an obvious variant of the invention defined by the PARENT for reasons noted in conjunction with the double patenting rejection to the parent claims.
At the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of the PARENT and RANSIL before him or her, to modify the system of the PARENT to include the claimed “wherein the key uniquely identifies items in the database” as analogously taught by RANSIL (¶[0063] – “Entity identifier (eID): a string (e.g., a UTF-8 encoded string) that a developer may use to uniquely identify an entity to their application”; ¶[0075] – “every eID is unique in the table; an eID may thus be viewed as a subscriber-provided entity key”) such that the claims of the PARENT are not patentably distinct from the claims of the instant application. A motivation for combining the use of an open source embedded database system of RANSIL with the PARENT would have been to make indexed search available on the web and to make it easy for developers to add search capability to their applications (¶[0057]).
Instant Application
Claim 40
(and similarly Claims 47 and 54)
US Patent 9,052,831
Claim 3
The system of claim 38,
The system of Claim 3
wherein a hash function is applied to the key to determine the current partition of the database.
The addition of the claimed “receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed’, as recited in the Parent Claims 36, 48, and 50, would be an obvious variant of the invention defined by the PARENT for reasons noted in conjunction with the double patenting rejection to the parent claims.
At the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of the PARENT and RANSIL before him or her, to modify the system of the PARENT to include the claimed “wherein the key uniquely identifies items in the database” as analogously taught by RANSIL (¶[0288] – “partitions may be formed based on a hash of the entity ID (eID)”) such that the claims of the PARENT are not patentably distinct from the claims of the instant application. A motivation for combining the use of an open source embedded database system of RANSIL with the PARENT would have been to make indexed search available on the web and to make it easy for developers to add search capability to their applications (¶[0057]).
Instant Application
Claim 41
(and similarly Claims 48 and 55)
US Patent 9,052,831
Claim 3
The system of claim 36,
The system of Claim 3
wherein the throughput is specified for performing read request to the database.
The addition of the claimed “receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed’, as recited in the Parent Claims 36, 48, and 50, would be an obvious variant of the invention defined by the PARENT for reasons noted in conjunction with the double patenting rejection to the parent claims.
At the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of the PARENT and ZENG before him or her, to modify the system of the PARENT to include the claimed “wherein the throughput is specified for performing read request to the database” as analogously taught by ZENG (Abstract – metadata may be retrieved from a scalable, fault-tolerant metadata service; entities may make requests to read or write the metadata) such that the claims of the PARENT are not patentably distinct from the claims of the instant application. A motivation for incorporating the feature of distinguishing between read requests from write requests of ZENG with the PARENT would have been to scale partitioning such that different types of requests may be made to different groups of servers which may be optimized to service that particular type of request (¶[0021]).
Instant Application
Claim 42
(and similarly Claim 49)
US Patent 9,052,831
Claim 3
The system of claim 36,
The system of Claim 3
wherein a range index is created for the database responsive to a request to the non-relational database service.
The addition of the claimed “receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed’, as recited in the Parent Claims 36, 48, and 50, would be an obvious variant of the invention defined by the PARENT for reasons noted in conjunction with the double patenting rejection to the parent claims.
At the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of the PARENT and RANSIL before him or her, to modify the system of the PARENT to include the claimed “wherein a range index is created for the database responsive to a request to the non-relational database service” as analogously taught by RANSIL (¶[0334] – “one embodiment may perform … equality and range lookups with the value”) such that the claims of the PARENT are not patentably distinct from the claims of the instant application. A motivation for combining the use of an open source embedded database system to include range lookups of RANSIL with the PARENT would have been to enable the system to perform a common database operations to retrieve all records where some value is between an upper and lower boundary.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 36-55 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over RANSIL and further in view of ZENG.
With respect to Claims 36, 43, and 50, RANSIL discloses a system/method/media, comprising:
a plurality of computing devices (Fig 4, query nodes 360, storage nodes 370, coordinator nodes 350), respectively comprising at least one processor and a memory (¶[0261] – “In one embodiment, a group membership and health component 226 may run on each node, and may communicate local health information about CPU, disk, memory, network utilization, and other local system metrics to one or more other nodes”, ), that implement a non-relational database service (¶[0056] – “the eID store may be implemented in accordance with a Berkeley Database … Unlike relational databases, a Berkeley Database does not support SQL queries”);
wherein the non-relational database service is configured to:
receive, via an interface of the non-relational database service, a request (¶[0039] – “web services may be used to provide web software developers programmatic access to web resources including technology platforms and data hosted on web-connected computers such as web server systems via a web service interface … a Web service interface may be configured to provide a standard, cross-platform API for communication between a client requesting some service to be performed and the service provider”);
automatically create two or more new partitions of a database hosted by a non-relational database service until a number of new partitions is created that supports the number of request units over time available to consume when performing requests to the database specified in the request (Section [0290] – buckets may be divided into separate partitions of data in response to potential situations; ¶[0277]; Fig 9B depicts buckets 252A split into partitions 254A, 254B, and 254C; ¶ [0281] - the partition manager performs actions to reconfigure the data service system to alleviate hot spots {analogous to “support the number of requests <sic> units over time available to consume”} which may occur as a result of a high processing load), wherein a current partition of the database is stored on a plurality of storage nodes that implement a replica group for the current partition (¶ [0280] – “for data durability and fault tolerance, data sets may be replicated across several storage nodes. In Fig 9C, the partitions 254 of Fig 9B have been replicated to form replication groups 256A, 256B, and 256C”), and wherein automatically creating the two or more new partition comprises:
split the data stored in the current partition of the database to respectively add different portions of the data to the two or more new partitions of the database (¶[0293] – “Fig 10 illustrates the splitting or partitions in replication groups according to one embodiment … the number of partitions 254 in bucket 254 may be increased by splitting partitions 254 in a replication group 256 … in the example illustrated in Fig 10, the replication group .. has been split into two partitions”), wherein different respective plurality of nodes implement new replica groups for the two or more new partitions (¶[0294] – “when a new storage node is added to one of the split replication groups … the replication group has more than the required number of members. A stressed host may then leave the replication group”); and
receive and perform one or more requests from a client application directed to the data of the current partition of the non-relational database service while the splitting of the data is performed (¶[0217]-— updates may be received and applied to the original partition while using the lazy replication mechanism of the replication of partitions).
RANSIL may not explicitly disclose wherein the request specifies a value that updates a number of request units over time available to consume when performing request to the database to increase throughput for the database, wherein the number of new partitions are determined according to the value.
However, ZENG discloses wherein the request specifies a value that updates a number of request units over time available to consume when performing request to the database to increase throughput for the database; wherein the number of new partitions are determined according to the value (¶[0020] – “Partitioning is scalable, so if the amount of metadata increases – or if the expected rate of requests for metadata increases – the metadata can be divided into a larger number of partitions, and can then be redistributed across a larger number of servers”; Fig 5, Metadata 512 may be stored in metadata database 514; ¶[0051] “metadata may be repartitioned after an initial partitioning of the metadata. One circumstance in which metadata may be repartitioned is where the amount of metadata grows to the point that it is no longer practical to serve a given partition on its currently-assigned set of nodes. When this circumstance occurs {the determination of the circumstance analogous to ‘a request’}, a metadata server may instruct the existing nodes to split the partition that they serve”. While ZENG may not explicitly recite how a circumstance in which metadata may be repartitioned is detected, ZENG explicitly discloses that (1) once the circumstance is detected, the metadata server may instruct nodes to split a partition they serve and move a resulting new partition to a new set of nodes and (2) repartitioning may happen as a result of an increase in the expected rate of requests {analogous to ‘a number of request units over time’ or representative of ‘a value’}. Since ZENG must somehow determine when the circumstance occurs in order to instruct repartitioning and repartitioning may happen based on an increase in the expected rate of requests, the Office asserts the determination of the expected rate of requests meeting a threshold for repartitioning and subsequent decision by the metadata server to instruct the nodes to split a partition due to the determination analogous to applicant’s claimed ‘a request’ including ‘a value’.).
RANSIL and ZENG are analogous art because they are from the same field of endeavor of storage management systems. At the time of the invention, it would have been obvious to one of ordinary skill in the art, having the teachings of RANSIL and ZENG before him or her, to modify the partition manager of RANSIL to include partition splitting responsive to detected increases in throughput as taught by ZENG. A motivation for doing so would have been to perform load balancing on the database so that service loads may be distributed across partitions when hot spots are created due to access bursting. Therefore, it would have been obvious to combine RANSIL and ZENG to obtain the invention as specified in the instant claims.
With respect to Claims 37, 44, and 51, the combination of RANSIL and ZENG disclose the system/method/media of each respective parent claim.
RANSIL further discloses wherein the non-relational database service is further configured to monitor a size of the data stored in the current partition for an increase in the size of the data stored in the current partition (¶ [0012] - “the searchable data service may include mechanisms .. for the automated monitoring and control of nodes within the searchable data service”).
With respect to Claims 38, 45, and 52, the combination of RANSIL and ZENG disclose the system/method/media of each respective parent claim.
RANSIL further discloses wherein the current partition of the database is determined according to a key specified in a request to the non-relational database service (¶[0056] – database systems may be configured to use key-value pairs that may be used to create indexes to tables and other data structures).
With respect to Claims 39, 46, and 53, the combination of RANSIL and ZENG disclose the system/method/media of each respective parent claim.
RANSIL further discloses wherein the key uniquely identifies items in the database (¶[0063] – “Entity identifier (eID): a string (e.g., a UTF-8 encoded string) that a developer may use to uniquely identify an entity to their application”; ¶[0075] – “every eID is unique in the table; an eID may thus be viewed as a subscriber-provided entity key”).
With respect to Claims 40, 47, and 54, the combination of RANSIL and ZENG disclose the system/method/media of each respective parent claim.
RANSIL further discloses wherein a hash function is applied to the key to determine the current partition of the database (¶[0288] – “partitions may be formed based on a hash of the entity ID (eID)”).
With respect to Claims 41, 48, and 55, the combination of RANSIL and ZENG disclose system/method/media of each respective parent claim.
ZENG further discloses wherein the throughput is specified for performing read requests to the database (Abstract – metadata may be retrieved from a scalable, fault-tolerant metadata service; entities may make requests to read or write the metadata).
With respect to Claims 42 and 49, the combination of RANSIL and ZENG disclose the system/method of each respective parent claim.
RANSIL further discloses wherein a range index is created for the database responsive to a request to the non-relational database service (¶[0334] – “one embodiment may perform … equality and range lookups with the value”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ERIC T LOONAN whose telephone number is (571)272-6994. The examiner can normally be reached M-F 8am-5pm.
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, Arpan Savla can be reached at 571-272-1077. 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.
/ERIC T LOONAN/Examiner, Art Unit 2137
Prosecution Insights