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 .
Continued Examination Under 37 CFR 1.114
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 11/10/2025 has been entered. This office action is made Non-Final.
Status of claims
This office action is in response to claims filed on 11/10/2025; the parent application date of 11/23/2022 is considered.
Claims 21-40 are pending and rejected; claims 21, 28 and 35 are independent claims
Response to Arguments
Applicant’s arguments with respect to claim(s) rejected based on 35 U.S.C. 103, filed on 11/10/2025 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
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 § 112
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.
Claims 1, 28 and 35 recite the limitation one or more processors and corresponding memory, of a second backup service in a second region, configured to: receive, from a first backup service in a first region, a credential request for a second region credential authorizing the first backup 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 backup service to perform one or more service calls at the second region; " in the first limitation. Since there are two recitations of “a second region”, it is not clear which one of “a second region” is referenced by the cited “the second region.” There is insufficient antecedent basis for this limitation in the claim.
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-40 is/are rejected under 35 U.S.C. 103 as being unpatentable over De Boer US Pub. No.: 2020/0076794 A1 (hereinafter Boer) in view of Mehta et al. US Pub. No.: 2020/0195719 A1 (hereinafter Mehta).
Boer teaches:
As to claim 21, a system, comprising:
one or more processors and corresponding memory, of a second service in a second region (see Boer Fig. 4 and ¶18, endpoint associated with a cloud application or service), 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 [Examiner’s note: see applicants own disclosure ¶¶14-15 (spec)
The first region is a source of data.
The second region is a destination of data.
The credential is received from the source/first region.
The credential request is received from the second/destination region using a client token to access data from source/first region.
Data from the source/first region may be obtained using the credential from the source/first region] (see Boer Abstract, Figs. 3-5 and ¶¶18 23 28 and 30, a request to access an application from the client computing system [i.e. a request for authorization/credential token], forwarding the request and the authentication token from the reverse proxy to the application, receiving the request [i.e. credential request] and the authentication token [i.e. client authentication token] at the application [i.e. destination/second region], requesting, by the application, of an authorization token [i.e. credentials of source/first region] from an OAuth server [i.e. first region] based on the authentication token, receiving the authorization token from the OAuth server [i.e. credentials of source/first region]; ¶34, service is incorporated into an application by service broker 822, which is an API that publishes to Cloud Controller 812 the ability to list service offerings, provision the service, and enable applications to make calls out to it. A ‘provision’ call may reserve resources on a service and a ‘bind’ call may deliver information to an application necessary for accessing the resource);
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 Boer Figs. 3-5 and ¶¶23-25 30 34, Application 330 therefore accepts the token issued by reverse proxy 320 and uses the JWT bearer token grant flow (e.g., https://tools.ietf org/html/rfc7523) to authenticate client 310 and broker the token for an OAuth token [i.e. determine the whether the first service in the region is authorized to perform the service]. Application 330 is a registered client of OAuth server 340 and therefore uses a client id, client secret and URL of a corresponding OAuth service binding to execute the JWT bearer token grant flow); and
reject, based on the authentication token being invalid, the credential request (see Boer Figs. 3-5 and ¶¶16 24-25 30, Application 124 may then serve requests from client 110 based on authorizations associated with the token [i.e. reject/approve based on authentication token]); 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 Boer Figs. 3-5 and ¶¶16 24-25 30 34, Application 124 may then serve requests from client 110 based on authorizations associated with the token [i.e. reject/approve based on authentication token])
Boer 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 certificate-initiated access to service taught by Boer 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 Boer 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 Boer ¶18, authentication and authorization, service 228 may provide resources to application 224 based on authorizations associated with the forwarded token; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service); 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).
Same rational applied as above to combine the cited prior art references
As to claim 23, the combination of Boer 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 Boer ¶32 34, OAuth server 726 and uses authorization services provided by OAuth server 726. Each of applications 724a and 724b is associated with a respective one of cloud platform routers 723a and 723b which may operate as described with respect to router 623; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service).
Same rational applied as above to combine the cited prior art references
As to claim 24, the combination of Boer 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 Boer ¶28, Service 450 therefore generates a response to the request from application 430 based on authorizations specified by the OAuth token and returns the response to application 430);
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 Boer ¶¶30 34, application 530 creates an authentication token and requests an OAuth token from OAuth server 540. To issue the request, application 530 may map the certificate to a set of credentials used for authentication to OAuth server 540).
As to claim 25, the combination of Boer 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 Boer ¶28, generates a response to the request from application 430 based on authorizations specified by the OAuth token and returns the response to application 430; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service);
determine whether the backup retrieval request includes a credential for services originating from within the second region (see Boer Figs. 3-5 and ¶¶24-25 30, OAuth server 340 may confirm [i.e. determine] the provenance of the JWT token using a corresponding public key of proxy 320. OAuth server 340 then creates an OAuth token and associates the OAuth token with the authorizations; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service); 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, maintaining backup copies in secondary storage device(s) 108).
Same rational applied as above to combine the cited prior art references
As to claim 26, the combination of Boer 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 Boer ¶30, application 530 creates an authentication token and requests an OAuth token from OAuth server 540);
generate the authentication token to authorize service calls on behalf the client (see Boer ¶30, application 530 may map the certificate to a set of credentials used for authentication to OAuth server 540); and
send, to the frontend, the authentication token (see Boer ¶¶30 34, if application 530 is registered as an identity provider to OAuth server 540, application 530 may broker the token for an OAuth token using a JWT bearer flow).
As to claim 27, the combination of Boer 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)).
Same rational applied as above to combine the cited prior art references
As to claim 36, the combination of Boer 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 Boer Figs. 3-5 and ¶¶24-25 30, OAuth server 340 may confirm [i.e. determine] the provenance of the JWT token using a corresponding public key of proxy 320. OAuth server 340 then creates an OAuth token and associates the OAuth token with the authorizations; and see Mehta 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 Boer Figs. 3-5 and ¶¶24-25 30, OAuth server 340 may confirm [i.e. determine] the provenance of the JWT token using a corresponding public key of proxy 320. OAuth server 340 then creates an OAuth token and associates the OAuth token with the authorizations; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service).
Same rational applied as above to combine the cited prior art references
As to claim 37, the combination of Boer 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 Boer ¶32, OAuth server 726 and uses authorization services provided by OAuth server 726. Each of applications 724a and 724b is associated with a respective one of cloud platform routers 723a and 723b which may operate as described with respect to router 623; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service).
Same rational applied as above to combine the cited prior art references
As to claim 38, the combination of Boer 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 Boer ¶¶32 34, OAuth server 726 and uses authorization services provided by OAuth server 726. Each of applications 724a and 724b is associated with a respective one of cloud platform routers 723a and 723b which may operate as described with respect to router 623);
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 Boer ¶¶30 34, application 530 creates an authentication token and requests an OAuth token from OAuth server 540. To issue the request, application 530 may map the certificate to a set of credentials used for authentication to OAuth server 540).
As to claim 39, the combination of Boer 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 Boer ¶28, generates a response to the request from application 430 based on authorizations specified by the OAuth token and returns the response to application 430);
determining whether the backup retrieval request includes a credential for services originating from within the second region (see Boer Figs. 3-5 and ¶¶24-25 30, OAuth server 340 may confirm [i.e. determine] the provenance of the JWT token using a corresponding public key of proxy 320. OAuth server 340 then creates an OAuth token and associates the OAuth token with the authorizations; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service); 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)
Same rational applied as above to combine the cited prior art references
As to claim 40, the combination of Boer 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, by the second backup service in the second region from the first backup service in the first region, a credential request for a second region credential to retrieve one or more backups from the second region, the credential request generated in accordance with an authentication token for requests on behalf of a client (see Boer Abstract, Figs. 3-5 and ¶¶18 23 28 and 30, a request to access an application from the client computing system, forwarding the request and the authentication token from the reverse proxy to the application, receiving the request [i.e. credential request] and the authentication token [i.e. client authentication token] at the application [i.e. destination/second region], requesting, by the application, of an authorization token [i.e. credentials of source/first region] from an OAuth server [i.e. first region] based on the authentication token, receiving the authorization token from the OAuth server [i.e. credentials of source/first region]; and see Mehta Figs. 3 6-7 9 and ¶¶163-168, 314-323, first and second regions backup copy operation/service); and
rejecting, based on the authentication token being invalid, the credential request (see Boer Figs. 3-5 and ¶¶16 24-25 30, Application 124 may then serve requests from client 110 based on authorizations associated with the token [i.e. reject/approve based on authentication token]).
Same rational applied as above to combine the cited prior art references
As to independent claim 28, this claim directed to a method executed by the system of claim 21; therefore, it is rejected along similar rationale.
As to independent claim 35, this claim directed to a computer-readable storage media storing instructions 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 claim 22-27; therefore, they are rejected along the same rationale.
Conclusion
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 2/20/2026