Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of claims
This office action is in response to claims filed on 05/26/2026; the parent application date of 11/23/2022 is considered.
Claims 21-39 and 41 are pending and rejected; claim 40 is canceled; claims 21, 28 and 35 are independent claims
The claim rejections directed to 35 USC § 112(b) is withdrawn based on applicants amendment.
Applicant’s request to hold the double patenting rejection in abeyance until the claims are in condition for allowance is noted by the examiner.
Response to Arguments
Applicant's arguments filed on 05/26/2026 have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claim(s) rejected based on 35 U.S.C. 103, filed on 05/26/2026 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
With respect to applicant’s argument: The double patenting rejection, the amended claims have been re-evaluated and do not overcome the double patenting rejection.
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.
Claims 21-40 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,831,773 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because, the claims in the instant application are obvious over the claims in the parent application. Please see the claim comparison in the table below.
US 11,831,773 B1
Instant application
1. A system, comprising:
data storage in a first region for a database service configured to store a plurality of database objects;
backup data storage in the first region configured to store one or more backups of the individual ones of the database objects;
one or more computing devices comprising one or more processors and memory and configured to implement a frontend for the database service configured to:
receive, from a client in accordance with an application programmatic interface (API), a request to restore a database to the first region from one or more other backups stored in another backup data storage implemented in a second region; and
request and receive, from an authentication service, an authentication token for the request from the client; and
one or more computing devices comprising one or more processors and memory and configured to implement a backup restore manager service for the first region configured to: perform backup operations to store the one or more backups of individual ones of the database objects to the backup data storage in the first region;
send, from the backup restore manager service for the first region to another backup restore manager service implemented in the second region, a credential request for a second region credential authorizing the backup restore manager service for the first region to retrieve the one or more other backups from the second region, wherein the credential request is generated using the authentication token;
receive, by the backup restore manager service for the first region from the other backup restore manager service, the second region credential;
2. The system of claim 1, further comprising: one or more computing devices comprising one or more processors and memory and configured to implement the other backup restore manager service configured to: receive, from the backup restore manager service in the first region, the credential request for the second region credential; determine whether the credential request is authorized based at least in part on validating that the credential request was generated using the authentication token; and based on a determination that the credential request is authorized, send, to the backup restore manager service, the second region credential.
3. The system of claim 2, further comprising: the other backup data storage in the second region for the database service configured to: store the one or more other backups of the individual ones of the database objects; receive, from the backup restore manager service of the first region, the backup retrieval request generated using the second region credential; determine whether the backup retrieval request includes a credential for services originating from within the second region; and based on a determination that the second region credential originated from within the second region, send, to the backup restore manager service of the first region the one or more backups.
4. The system of claim 1, wherein the backup restore manager service of the first region is further configured to: send, to the other backup restore manager service of the second region, a manifest request for location information of backup data objects for the backup in the second region, wherein the manifest request is generated using the authentication token; and receive, from the backup restore manager service of the second region, the location information.
5. The system of claim 1, further comprising: one or more computing devices comprising one or more processors and memory and configured to implement the authentication service configured to: receive, from the frontend, a request for the authentication token; generate the authentication token to authorize service calls on behalf the client; and send, to the frontend, the authentication token.
send, from the backup restore manager service for the first region to the other backup data storage in the second region, a backup restore request to retrieve the one or more other backups from the other backup data storage in the second region, wherein the backup restore request is generated using the second region credential; and
load, by the backup restore manager service for the first region, the one or more backups from the second region to restore the database.
21. A system, comprising: one or more processors and corresponding memory, of a second backup service in a second region, configured to:
receive, from a first service in a first region, a credential request for a second region credential authorizing the first service in the first region to perform one or more service calls at a second region, the received credential request for the second region credential generated using an authentication token for requests, on behalf of a client, to obtain the second region credential authorizing the first service to perform one or more service calls at the second region ;
determine, at the second backup service and based on validation of the authentication token, whether the first backup service in the first region is authorized to perform the one or more service calls; and
reject, based on the authentication token being invalid, the credential request; or
send, from the second backup service in the second region to the first backup service in the first region, the second region credential.
22. (Previously presented) The system of claim 21, wherein: the second region credential comprises a credential to retrieve one or more backups from the second region; and said determine comprises determine whether the first backup service in the first region is authorized to retrieve the one or more backups from the second region.
23. (Previously presented) The system of claim 21, wherein said determine whether the first backup service in the first region is authorized to perform the one or more service call is based at least in part on validating that the credential request was generated using the authentication token.
24. (Previously presented) The system of claim 21, wherein the second backup service in the second region is configured to: receive, from the first backup service of the first region, a service call generated using the second region credential; determine whether the service call includes a credential for services originating from within the second region; and based on a determination that the second region credential originated from within the second region, perform the service call.
25. (Previously presented) The system of claim 21, wherein the second backup service in the second region is configured to: store one or more backups of individual database objects; receive, from the first backup service of the first region, a backup retrieval request generated using the second region credential; determine whether the backup retrieval request includes a credential for services originating from within the second region; and based on a determination that the second region credential originated from within the second region, send the one or more backups to the first backup service of the first region.
26. (Previously presented) The system of claim 21, further comprising: one or more computing devices comprising one or more processors and memory and configured to implement an authentication service configured to: receive, from a frontend, a request for the authentication token; generate the authentication token to authorize service calls on behalf the client; and send, to the frontend, the authentication token.
27. (Previously presented) The system of claim 21, wherein the second backup service of the second region is configured to: receive, from the first backup service of the first region, a manifest request for location information of backup data objects for the backup in the second region, wherein the manifest request is generated using the authentication token; and send, to the first backup service of the first region, the location information.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 21-39 and 41 is/are rejected under 35 U.S.C. 103 as being unpatentable over De Dunjic US Pub. No.: 2019/0372958 A1 (hereinafter Dunjic) in view of Mehta et al. US Pub. No.: 2020/0195719 A1 (hereinafter Mehta).
Dunjic teaches:
As to claim 21, a system, comprising:
one or more processors and corresponding memory, of a second service in a second region (see Dunjic Fig. 1 and ¶32 client application 102 may be an app that requests to access a protected resource 140 [i.e. second service of second region]), configured to:
receive, from a first service in a first region, a credential request, wherein the credential request: is a request for a second region credential that authorizes the first service to perform one or more service calls at the second region, and generated using an authentication token for requests, on behalf of a client, to obtain the second region credential (see Dunjic Figs 5-6 and ¶¶69 83, the server receives, from a client application, a first signal including a request to obtain an access token for accessing a protected resource, such as an API or database [i.e. server receives for access token/credential from (first region)/(from client application) to perform service call (to access protected resource) in the server/at the second region]). The request includes, at least, a unique client identifier, an authorization code [i.e. the request is generated using an authentication token/authorization code, for requests on behalf of a client], and a public key associated with an end-user of the client application; ¶66, An authorization code is an intermediate credential, which encodes the authentication of the end-user and which may be exchanged for an access token. An access token is used to make authenticated requests to a protected resource, such as an AP )
determine, at the second service in the second region and based on validation of the authentication token, whether the first service in the first region is authorized to perform the one or more service calls (see Dunjic Figs 5-6 and ¶¶70 83, In operation 520, the authorization server validates the request for an access token submitted by the client application [i.e. the authorization server validates if the request to perform the one or more service call is authorized based on the authorization code], ¶66, An authorization code is an intermediate credential, which encodes the authentication of the end-user and which may be exchanged for an access token. An access token is used to make authenticated requests to a protected resource, such as an AP); and
reject, based on the authentication token being invalid, the credential request (see Dunjic Figs. 5-6 and ¶84, the server validates the request. For example, the server may verify that at least one, or all, of the client identifier, authorization code [i.e. authentication token], and public key in the authorization request corresponds to a valid application. If one or more of these is invalid, the server may reject the authorization request immediately ¶83, The authorization code is the credential that the client application received when an end-user of the client application was authenticated .); or
send, from the second service in the second region to the first service in the first region, the second region credential authorizing the first service in the first region to perform one or more service calls at the second region (see Dunjic Figs. 5-6 and ¶72 84, The first code, or the encrypted version of the authorization code from the client application, is then transmitted back to the client application, along with the access token assigned to the client application by the server, in operation 658.)
Dunjic does not explicitly teach but the related art Mehta teaches:
first backup service in a first region, second backup service in a second region (see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service)
Therefore, it would have been obvious for a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the system for controlling access to a protected resource taught by Dunjic wit she region-based distributed information management system disclosed by Mehta. A person of ordinary skill would have been motivated to do so, with a reasonable expectation of success, because backup authentication service works in conjunction with the first and second services to assist in determining if the first service is able to contact the second service and obtain access to the user's information through the second service (see Mehta ¶3)
As to claim 22, the combination of Dunjic and Mehta teaches the system of claim 21, wherein: the second region credential comprises a credential to retrieve one or more backups from the second region (see Dunjic ¶66 69, The access token may be used, for example, in making authenticated API calls to a resource server. As part of the request to the authorization server) and (see Mehta ¶316, region authorization service 742A may be configured to handle permissions that determine whether a client computing device 102A is allowed to request a secondary copy operation, restore secondary copy data, and/or request and/or perform other operations in the system 100); and
said determine comprises determine whether the first backup service in the first region is authorized to retrieve the one or more backups from the second region (see Mehta ¶316, region authorization service 742A may be configured to handle permissions that determine whether a client computing device 102A is allowed to request a secondary copy operation, restore secondary copy data, and/or request and/or perform other operations in the system 100).
Similar rational applied as above to combine the cited prior art references
As to claim 23, the combination of Dunjic and Mehta teaches the system of claim 21, wherein said determine whether the first backup service in the first region is authorized to perform the one or more service call is based at least in part on validating that the credential request was generated using the authentication token (see Dunjic ¶83, the server receives, from a client application, a first signal including a request to obtain an access token for accessing a protected resource, such as an API or database. The request includes, at least, a unique client identifier, an authorization code, and a public key associated with an end-user of the client application; ¶66, An authorization code is an intermediate credential, which encodes the authentication of the end-user and which may be exchanged for an access token. An access token is used to make authenticated requests to a protected resource, such as an AP [i.e. the request to access token is based on an authentication of the end user]).
Similar rational applied as above to combine the cited prior art references
As to claim 24, the combination of Dunjic and Mehta teaches the system of claim 21, wherein the second backup service in the second region is configured to: receive, from the first backup service of the first region, a service call generated using the second region credential (see Dunjic ¶96, In operation 710, the device generates a request based on the transaction details to access the protected resource for initiating the first transaction, where the request includes the access token received from the authentication server [i.e. the second region credentials]);
determine whether the service call includes a credential for services originating from within the second region; and based on a determination that the second region credential originated from within the second region, perform the service call (see Dunjic ¶96, In operation 710, the device generates a request based on the transaction details to access the protected resource for initiating the first transaction, where the request includes the access token received from the authentication server. In some embodiments, the request to access the protected resource may be generated only upon the device receiving a user input providing authorization to initiate the first transaction).
As to claim 25, the combination of Dunjic and Mehta teaches the system of claim 21, wherein the second backup service in the second region is configured to: store one or more backups of individual database objects (see Mehta ¶¶284 301, creating a backup or other secondary copy… a region database 444A, and a region synchronization service 446A);
receive, from the first backup service of the first region, a backup retrieval request generated using the second region credential (see Dunjic Fig. 5 and ¶74, client application sends the request to the protected resource, in operation 526 [i.e. the request using the authorization token].);
determine whether the backup retrieval request includes a credential for services originating from within the second region (see Dunjic Fig, 5 and ¶74, requests the authorization server to verify the bearer token submitted by the client application, in operation 528. That is, the authorization server receives, from a web server associated with the protected resource, a request to validate the bearer token); and
based on a determination that the second region credential originated from within the second region, send the one or more backups to the first backup service of the first region (see Mehta ¶171, the secondary copy data is transmitted to the client computing device; ¶312, client computing device 102A can then use the token to access the desired computing resource in the region A (e.g., primary data, secondary copy data, etc.)).
Same rational applied as above to combine the cited prior art references
As to claim 26, the combination of Dunjic and Mehta teaches the system of claim 21, further comprising: one or more computing devices comprising one or more processors and memory and configured to implement an authentication service configured to: receive, from a frontend, a request for the authentication token (see Dunjic Fig. 5 and ¶64, the client application (or relying party) generates an OpenID authentication request (which may be an OAuth 2.0 authorization request to access the end-user's identity) via a browser (e.g. browser 320 of FIG. 3), in operation 512).
generate the authentication token to authorize service calls on behalf the client (see Dunjic Fig. 5 and ¶66, Once the end-user is authenticated, the client application is provided with an authorization code in operation 514 [i.e. authentication code]); and
send, to the frontend, the authentication token see Dunjic Fig. 5 and ¶66, Once the end-user is authenticated, the client application is provided with an authorization code in operation 514 [i.e. authentication code]).
As to claim 27, the combination of Dunjic and Mehta teaches the system of claim 21, wherein the second backup service of the second region is configured to: receive, from the first backup service of the first region, a manifest request for location information of backup data objects for the backup in the second region, wherein the manifest request is generated using the authentication token (see Mehta ¶89, metadata [i.e. manifest]generally includes information about data objects and/or characteristics associated with the data objects... last accessed time, application type (e.g., type of application that generated the data object), location/network (e.g., a current, past or future location of the data object and network pathways to/from the data object)…, access control lists (ACLs), system metadata (e.g., registry information), combinations of the same or other similar information related to the data object); and
send, to the first backup service of the first region, the location information (see Mehta ¶89, last accessed time, application type (e.g., type of application that generated the data object), location/network (e.g., a current, past or future location of the data object and network pathways to/from the data object)).
Similar rational applied as above to combine the cited prior art references
As to independent claim 35, this claim is substantially directed to a computer-readable storage media storing instructions similar to the ones executed by the system of claim 21; therefore, it is rejected along similar rationale.
As to claim 36, the combination of Dunjic and Mehta teaches the one or more non-transitory, computer-readable storage media of claim 35, wherein: the second region credential comprises a credential to retrieve one or more backups from the second region see Dunjic Fig. 5 and ¶76, response to validating the bearer token, the authorization server sends the web server associated with the protected resource a notification indicating that the bearer token is valid, in operation 532) and (see Mehta ¶316, region authorization service 742A may be configured to handle permissions that determine whether a client computing device 102A is allowed to request a secondary copy operation, restore secondary copy data; Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service); and
said determining comprises determining whether the first backup service in the first region is authorized to retrieve the one or more backups (see Dunjic Fig. 5 and ¶76, response to validating the bearer token, the authorization server sends the web server associated with the protected resource a notification indicating that the bearer token is valid, in operation 532) and (see Mehta ¶316, region authorization service 742A may be configured to handle permissions that determine whether a client computing device 102A is allowed to request a secondary copy operation, restore secondary copy data; Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service).
Similar rational applied as above to combine the cited prior art references
As to claim 37, the combination of Dunjic and Mehta teaches the one or more non-transitory, computer-readable storage media of claim 35, wherein the instructions cause the one or more processors to perform said determining whether the first backup service in the first region is authorized, based at least in part on validating that the credential request was generated using the authentication token (see Dunjic Figs. 5-6 and ¶84, the server validates the request. For example, the server may verify that at least one, or all, of the client identifier, authorization code, and public key in the authorization request corresponds to a valid application) and (see Mehta ¶316, region authorization service 742A may be configured to handle permissions that determine whether a client computing device 102A is allowed to request a secondary copy operation, restore secondary copy data; Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service).
Similar rational applied as above to combine the cited prior art references
As to claim 38, the combination of Dunjic and Mehta teaches the one or more non-transitory, computer-readable storage media of claim 35, wherein the instructions cause the one or more processors to perform: receiving, from the first backup service of the first region, a service call generated using the second region credential (see Dunjic ¶74, client application sends the request to the protected resource, in operation 526. The protected resource, in turn, requests the authorization server to verify the bearer token submitted by the client application, in operation 528. That is, the authorization server receives, from a web server associated with the protected resource, a request to validate the bearer token);
determining whether the service call includes a credential for services originating from within the second region; and based on a determination that the second region credential originated from within the second region, performing the service call (see Dunjic ¶80, in operation 606, the authorization server receives from the protected resource a third signal including a request to validate a bearer token submitted by the client application, where the bearer token includes a digital signature. The authorization server validates the bearer token in operation 608, verifying the digital signature using the public key included in the request in operation 602).
As to claim 39, the combination of Dunjic and Mehta teaches the one or more non-transitory, computer-readable storage media of claim 35, wherein the instructions cause the one or more processors to perform: storing one or more backups of individual database objects (see Mehta ¶¶284 301, creating a backup or other secondary copy… a region database 444A, and a region synchronization service 446A; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service);
receiving, from the first backup service of the first region, a backup retrieval request generated using the second region credential (see Dunjic ¶, generates a response to the request from application 430 based on authorizations specified by the OAuth token and returns the response to application 430) (see Mehta ¶316, region authorization service 742A may be configured to handle permissions that determine whether a client computing device 102A is allowed to request a secondary copy operation, restore secondary copy data; Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service);
determining whether the backup retrieval request includes a credential for services originating from within the second region (see Dunjic Figs. 5-6 and ¶81, response to validating the bearer token, the authorization server sends the protected resource a fourth signal indicating that the bearer token is indeed valid in operation 610); and
based on a determination that the second region credential originated from within the second region, sending the one or more backups to the first backup service of the first region (see Mehta ¶171, maintaining backup copies in secondary storage device(s) 108)
Similar rational applied as above to combine the cited prior art references
As to claim 40, (Canceled)
As to claim 41, the combination of Dunjic and Mehta teaches the one or more non-transitory, computer-readable storage media of claim 35, wherein the instructions cause the one or more processors to perform: receiving, from the first backup service in the first region, a manifest request for location information of backup data objects for one or more backups in the second region, wherein the manifest request is generated using the authentication token(see Mehta ¶89, metadata [i.e. manifest]generally includes information about data objects and/or characteristics associated with the data objects... last accessed time, application type (e.g., type of application that generated the data object), location/network (e.g., a current, past or future location of the data object and network pathways to/from the data object)…, access control lists (ACLs), system metadata (e.g., registry information), combinations of the same or other similar information related to the data object); and
send, to the first backup service of the first region, the location information (see Mehta ¶89, last accessed time, application type (e.g., type of application that generated the data object), location/network (e.g., a current, past or future location of the data object and network pathways to/from the data object)).
Similar rational applied as above to combine the cited prior art references
As to independent claim 28, this claim is substantially directed to a method similar to the one executed by the system of claim 21; therefore, it is rejected along similar rationale.
As to dependent claims 29-34, these claims contain substantially similar subject matter as claims 22-27; therefore, they are rejected along the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NEGA WOLDEMARIAM whose telephone number is (571)270-7478. The examiner can normally be reached Monday to Friday, 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, Cathy Thiaw can be reached at 5712701138. 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.
NEGA . WOLDEMARIAM
Examiner
Art Unit 2407
/N.W/ Examiner, Art Unit 2407
/Catherine Thiaw/ Supervisory Patent Examiner, Art Unit 2407 7/11/2026
Prosecution Insights