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 .
EXAMINER’S NOTE: The claims have been reviewed and considered under the new guidance pursuant to the 2019 Revised Patent Subject Matter Eligibility Guidance (PEG 2019) issued January 7, 2019.
This communication is in response to Applicant’s RCE Amendment filed on 11 March 2026. Claims 3 and 12 have been canceled. Claims 1, 10, and 19 have been amended. Claims 1-2, 4-7, 9-11, 13-16, and 18-19 remain pending.
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 March 2026 has been entered.
Response to Arguments
Applicant's arguments, pages 6-7, filed 11 March 2026, with respect to the rejection of claims 1-2, 4-7, 9-11, 13-16, and 18-19 in view of Krstic et al. have been fully considered, but they are not persuasive.
With respect to the applicant’s argument that the Krstic et al. disclosure, fail to disclose the granting of a permission wherein a first application grants permissions to a second application because Krstic et al. only discloses a request being denied in the scenario described in paragraph 43. Examiner acknowledges applicant’s perspective, however, disagrees as Krstic et al. discloses in paragraph 43 and Figure 6, the access control manager grants permission to allow applications to access resources by receiving a request from a first application (e.g., debugger) to attach to a second application (e.g., debuggee) wherein the request comprises a second application identifier associated with the second application (e.g., debuggee) and in response to the request, determine whether the second application is protected or part of a restricted class for permission to access resources, in response to the request, comparing the first and second identifiers and determines whether the second application is protected or as part of a restricted class of resources and if not, the first application may be allowed to attach to the second application. Krstic et al. discloses the verification step for indicating whether the second application has permission to access the resources is shown wherein if it is determined the second application is part of protected class, processing logic determines whether the second application specifically allows the first application to attach (e.g., exception) based on the entitlement of the second application. If so, the first application is allowed to attach to the second application and permission is granted to access the requested resources. Krstic et al. further discloses in paragraph 44, the techniques described in Figures 4 and 6, can be applied to controlling access of not only software components but also hardware components of a data processing system.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 4-7, 9-11, 13-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Krstic et al. (Pub No. 2015/0347774) (first embodiment - Fig. 4) in view of Krstic et al. (Pub No. 2015/0347774) (alternate embodiment - Fig. 6), and in further view of in view of Weiss et al. (Pub No. 2018/0302443).
Referring to the rejection of claim 1, Krstic et al. (Fig. 4) discloses a method at a permission service on a computing device for managing permissions, the method comprising:
receiving a request at the permission service from a first application, (See Krstic et al., Fig. 4, para. 38, i.e., processing logic receives a request from an application for accessing a resource)
performing an action at the permission service based on the received request; (See Krstic et al., Fig. 4, para. 38, i.e., in response to the request, determines a class or type of resources the application is entitled to access, which is authorized (and signed) by a predetermined authority and comparing a first resource class identifier identifying the determined class of resources with a second resource class identifier identifying a class of resources the requested resource belongs)
and returning results of the action to the first application indicating permission to access the resources. (See Krstic et al., Fig. 4, para. 38, i.e., if the first and second resource class identifiers are matched, the application is allowed permission to access the requested resource)
However, Krstic et al. (Fig. 4) fails to explicitly disclose the request comprising an identifier associated with an operating system for a second application and a permission for the second application to access resources.
Krstic et al. (Fig. 6) discloses a second embodiment wherein a method for accessing control of an operating system for a second application as shown in Figure 6.
Krstic et al. (Fig. 6) discloses the request comprising an identifier associated with an operating system for a second application and a permission for the second application to access resources; (See Krstic et al., Fig. 6, para. 43, i.e., the access control manager grants permission to allow applications to access resources by receiving a request from a first application (e.g., debugger) to attach to a second application (e.g., debuggee) wherein the request comprises a second application identifier associated with the second application (e.g., debuggee) and in response to the request, determine whether the second application is protected or part of a restricted class for permission to access resources)
Krstic et al. (Fig. 6) discloses performing an action at the permission service based on the received request; (See Krstic et al., Fig. 6, para. 43, i.e., in response to the request, comparing the first and second identifiers and determines whether the second application is protected or as part of a restricted class of resources and if not, the first application may be allowed to attach to the second application)
Krstic et al. (Fig. 6) discloses and returning results of the action to the first application indicating whether the second application has the permission to access the resources. (See Krstic et al., Fig. 6, para. 43, i.e., If it is determined the second application is part of protected class, processing logic determines whether the second application specifically allows the first application to attach (e.g., exception) based on the entitlement of the second application. If so, the first application is allowed to attach to the second application and permission is granted to access the requested resources)
Krstic et al. (Fig. 6) discloses wherein the action is to grant the permission to the identifier, the request further comprising an identifier of the first application, and wherein the method further comprises: determining that the first application has permission to grant permissions to the second application based on the identifier of the first application. (See Krstic et al., Fig. 6, para. 43, i.e., after the access control manager grants permission to the identifier to access resources, a method for access control of an operating system is disclosed to determine that the processing logic receives a request from a first application (e.g., debugger) to attach to a second application (e.g., debuggee) wherein the request comprises a second application identifier associated with the second application (e.g., debuggee) and in response to the request, determine whether the second application is protected or part of a restricted class for permission to access resources. In response to the request, comparing the first and second identifiers and determines whether the second application is protected or as part of a restricted class of resources and if not, the first application may be allowed to attach to the second application. Krstic et al. discloses the verification step for indicating whether the second application has permission to access the resources is shown wherein if it is determined the second application is part of protected class, processing logic determines whether the second application specifically allows the first application to attach (e.g., exception) based on the entitlement of the second application. If so, the first application is allowed to attach to the second application and permission is granted to access the requested resources)
The combination of Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) fail to explicitly disclose wherein the first application is a service that enforces the permission using the request to the permission service.
Weiss et al. discloses a secure policy-based separation of data and application on computing devices that operate in different environments so that both types of applications can run simultaneously while complying with all required polices.
Weiss et al. discloses wherein the first application is a service that enforces the permission using the request to the permission service. (See Weiss et al., para. 181, 189-192, and 222-223, i.e., the first application for enforcing permission using a request is disclosed as the domain import-export enforcement point for enabling applications within a domain to interact with each other and avoid interaction with applications of other domains which permits a domain to maintain control over its data. Each domain application has at least one domain import-export policy enforcement points to enable data exchange to the permitted domain policies. In the dynamic domain checking method, domain membership of a domain import-export policy enforcement point or an application is done using policy elements that describe applications or their characteristics in conjunction with checks by the involved policy enforcement points (domain import-export policy enforcement points, Loader applications, or other policy enforcement points) at the time a request is made between applications or policy enforcement points. If a first application in a first domain makes a request for data from a second application in the first domain, the second application checks the first application for domain membership before responding to the request. The check can be for characteristics of the first application such as its UIC, the file storage location it was run from, the signature it was signed with, a password or other authentication for identifying the application uniquely or as a member of a selected group. The check can be performed by an aspect of the OS on some devices, or in a policy management point or policy enforcement point, such as a Loader application. If the characteristics of the first application meet those required by domain policy, the second application will respond to the request. If they do not, the second application will ignore the request, respond with an error, or take other action to refuse the request as deemed proper. The domain policy is distributed through one or more policy management points which allocate it to policy enforcement points, which translate and enforce domain policy as follows: the private domain storage location is translated to a local, encrypted storage location (e.g. a file system) on the local device, for example on the device's SD card. The private domain storage is mapped and permissioned so it is accessible only to domain applications (for example, using the device OS's user or group ID file protection mechanisms)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention to combine Krstic et al.’s (Fig. 4) method and system for access control to restricted resource classes to an operating system of a data processing system and Krstic et al.’s (Fig. 6) method and system for access control to restricted resource classes to an operating system of a data processing system modified with Weiss et al. secure policy-based separation of data and application on computing devices that operate in different environments so that both types of applications can run simultaneously while complying with all required polices.
Motivation for such an implementation would enable access permissions being enforced specifying network access restrictions for one or more permitted applications for a domain by using policy enforcement. (See Weiss et al., para. 48 and 222-223)
Motivation for such an implementation would enable the second application to provide an exception to allow the first application to access resource of the second application or to attach to or control the second application wherein the first application is allowed permission to access the second application and resources of the second application. (See Krstic et al., para. 22)
Referring to the rejection of claims 2 and 11, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses wherein the action is a check to determine whether the identifier is associated with the permission at the permission service. (See Krstic et al., para. 27-28, i.e., when a request to access a particular resource is determined, an access control manager compares the first and second identifiers and if there is a match, the application is entitled to access requested resource and granted permission associated with allowing the application to access the resource)
Referring to the rejection of claims 4 and 13, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses wherein the identifier is a user identifier for the operating system. (See Krstic et al., para. 31, i.e., each user, application, or process on an operating systems is identified by a u user identifier which belongs to a primary group identified by a group identifier)
Referring to the rejection of claims 5 and 14, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses wherein the permission includes a permission name that is comprised of a domain, an action and a subject. (See Weiss et al., para. 123-128 and 182, i.e., a permission name is used as a descriptive name that makes it clear what resources the permission is protecting and what action it protects based on the subject at hand, “DOMAIN-X-CALENDAR-READ” or “DOMAIN-X-VIEW”, or “DOMAIN-X-PROVIDE-VIEW” and permission names that are specified in application manifests using names that must match between a requesting application, which must be granted a permission and the application receiving the request which requires the permission)
The rationale for combining Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) in view of Weiss et al. is the same as claim 1.
Referring to the rejection of claims 6 and 15, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses wherein the domain includes prefixes unique within a computing system. (See Weiss et al., para. 135-136, i.e., a unique name defining the domain’s namespace by pre-pending a string to the filter name)
The rationale for combining Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) in view of Weiss et al. is the same as claim 1.
Referring to the rejection of claims 7 and 16, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses wherein the permission name is unique within the domain. (See Weiss et al., para. 124 and 190, i.e., the domain policy comprises policy elements that define permission names which are specified in application manifests using names that are unique for identifying the application within the domain policy)
The rationale for combining Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) in view of Weiss et al. is the same as claim 1.
Referring to the rejection of claims 9 and 18, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses wherein the permission service is configured both statically at run time and dynamically after run time with associations between identifiers and permissions. (See Weiss et al., para. 6, i.e., applications having permissions to run both dynamically and statically have OS level protections applied to them for providing access control to specific resources)
The rationale for combining Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) in view of Weiss et al. is the same as claim 1.
Referring to the rejection of claim 10, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses a computing device configured as a permission service for managing permissions, the computing device comprising:
a processor configured to execute instructions; a memory for storing instructions (See Krstic et al., para. 56, i.e., a processor is disclosed, item 1001, memory 1003)
and a communications subsystem, wherein the computing device is configured to: (See Krstic et al., para. 60, i.e., a wireless transceiver, item 1005 is disclosed as a communications subsystem)
receive a request at the permission service from a first application, (See Krstic et al., Fig. 4, para. 38, i.e., processing logic receives a request from an application for accessing a resource)
perform an action at the permission service based on the received request; (See Krstic et al., Fig. 4, para. 38, i.e., in response to the request, determines a class or type of resources the application is entitled to access, which is authorized (and signed) by a predetermined authority and comparing a first resource class identifier identifying the determined class of resources with a second resource class identifier identifying a class of resources the requested resource belongs)
and return results of the action to the first application indicating permission to access the resources. (See Krstic et al., Fig. 4, para. 38, i.e., if the first and second resource class identifiers are matched, the application is allowed permission to access the requested resource)
However, Krstic et al. (Fig. 4) fails to explicitly disclose the request comprising an identifier associated with an operating system for a second application and a permission for the second application to access resources.
Krstic et al. (Fig. 6) discloses a second embodiment wherein a method for accessing control of an operating system for a second application as shown in Figure 6.
Krstic et al. (Fig. 6) discloses the request comprising an identifier associated with an operating system for a second application and a permission for the second application to access resources; (See Krstic et al., Fig. 6, para. 43, i.e., the access control manager grants permission to allow applications to access resources by receiving a request from a first application (e.g., debugger) to attach to a second application (e.g., debuggee) wherein the request comprises a second application identifier associated with the second application (e.g., debuggee) and in response to the request, determine whether the second application is protected or part of a restricted class for permission to access resources)
Krstic et al. (Fig. 6) discloses perform an action at the permission service based on the received request; (See Krstic et al., Fig. 6, para. 43, i.e., in response to the request, comparing the first and second identifiers and determines whether the second application is protected or as part of a restricted class of resources and if not, the first application may be allowed to attach to the second application)
Krstic et al. (Fig. 6) discloses and return results of the action to the first application indicating whether the second application has the permission to access the resources. (See Krstic et al., Fig. 6, para. 43, i.e., If it is determined the second application is part of protected class, processing logic determines whether the second application specifically allows the first application to attach (e.g., exception) based on the entitlement of the second application. If so, the first application is allowed to attach to the second application and permission is granted to access the requested resources)
Krstic et al. (Fig. 6) discloses wherein the action is to grant the permission to the identifier, the request further comprising an identifier of the first application, and wherein the method further comprises: determining that the first application has permission to grant permissions to the second application based on the identifier of the first application. (See Krstic et al., Fig. 6, para. 43, i.e., after the access control manager grants permission to the identifier to access resources, a method for access control of an operating system is disclosed to determine that the processing logic receives a request from a first application (e.g., debugger) to attach to a second application (e.g., debuggee) wherein the request comprises a second application identifier associated with the second application (e.g., debuggee) and in response to the request, determine whether the second application is protected or part of a restricted class for permission to access resources. In response to the request, comparing the first and second identifiers and determines whether the second application is protected or as part of a restricted class of resources and if not, the first application may be allowed to attach to the second application. Krstic et al. discloses the verification step for indicating whether the second application has permission to access the resources is shown wherein if it is determined the second application is part of protected class, processing logic determines whether the second application specifically allows the first application to attach (e.g., exception) based on the entitlement of the second application. If so, the first application is allowed to attach to the second application and permission is granted to access the requested resources)
The combination of Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) fail to explicitly disclose wherein the first application is a service that enforces the permission using the request to the permission service.
Weiss et al. discloses a secure policy-based separation of data and application on computing devices that operate in different environments so that both types of applications can run simultaneously while complying with all required polices.
Weiss et al. discloses wherein the first application is a service that enforces the permission using the request to the permission service. (See Weiss et al., para. 181, 189-192, and 222-223, i.e., the first application for enforcing permission using a request is disclosed as the domain import-export enforcement point for enabling applications within a domain to interact with each other and avoid interaction with applications of other domains which permits a domain to maintain control over its data. Each domain application has at least one domain import-export policy enforcement points to enable data exchange to the permitted domain policies. In the dynamic domain checking method, domain membership of a domain import-export policy enforcement point or an application is done using policy elements that describe applications or their characteristics in conjunction with checks by the involved policy enforcement points (domain import-export policy enforcement points, Loader applications, or other policy enforcement points) at the time a request is made between applications or policy enforcement points. If a first application in a first domain makes a request for data from a second application in the first domain, the second application checks the first application for domain membership before responding to the request. The check can be for characteristics of the first application such as its UIC, the file storage location it was run from, the signature it was signed with, a password or other authentication for identifying the application uniquely or as a member of a selected group. The check can be performed by an aspect of the OS on some devices, or in a policy management point or policy enforcement point, such as a Loader application. If the characteristics of the first application meet those required by domain policy, the second application will respond to the request. If they do not, the second application will ignore the request, respond with an error, or take other action to refuse the request as deemed proper. The domain policy is distributed through one or more policy management points which allocate it to policy enforcement points, which translate and enforce domain policy as follows: the private domain storage location is translated to a local, encrypted storage location (e.g. a file system) on the local device, for example on the device's SD card. The private domain storage is mapped and permissioned so it is accessible only to domain applications (for example, using the device OS's user or group ID file protection mechanisms)
The rationale for combining Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) in view of Weiss et al. is the same as claim 1.
Referring to the rejection of claim 19, (Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) modified by Weiss et al.) discloses a non-transitory computer readable medium for storing instruction code, which, when executed by a processor of a computing device configured as a permission service for managing permissions cause the computing device to: (See Krstic et al., para. 65, i.e., a non-transitory computer-readable storage media is disclosed)
receive a request at the permission service from a first application, (See Krstic et al., Fig. 4, para. 38, i.e., processing logic receives a request from an application for accessing a resource)
perform an action at the permission service based on the received request; (See Krstic et al., Fig. 4, para. 38, i.e., in response to the request, determines a class or type of resources the application is entitled to access, which is authorized (and signed) by a predetermined authority and comparing a first resource class identifier identifying the determined class of resources with a second resource class identifier identifying a class of resources the requested resource belongs)
and return results of the action to the first application indicating permission to access the resources. (See Krstic et al., Fig. 4, para. 38, i.e., if the first and second resource class identifiers are matched, the application is allowed permission to access the requested resource)
However, Krstic et al. (Fig. 4) fails to explicitly disclose the request comprising an identifier associated with an operating system for a second application and a permission for the second application to access resources.
Krstic et al. (Fig. 6) discloses a second embodiment wherein a method for accessing control of an operating system for a second application as shown in Figure 6.
Krstic et al. (Fig. 6) discloses the request comprising an identifier associated with an operating system for a second application and a permission for the second application to access resources; (See Krstic et al., Fig. 6, para. 43, i.e., the access control manager grants permission to allow applications to access resources by receiving a request from a first application (e.g., debugger) to attach to a second application (e.g., debuggee) wherein the request comprises a second application identifier associated with the second application (e.g., debuggee) and in response to the request, determine whether the second application is protected or part of a restricted class for permission to access resources)
Krstic et al. (Fig. 6) discloses perform an action at the permission service based on the received request; (See Krstic et al., Fig. 6, para. 43, i.e., in response to the request, comparing the first and second identifiers and determines whether the second application is protected or as part of a restricted class of resources and if not, the first application may be allowed to attach to the second application)
Krstic et al. (Fig. 6) discloses and return results of the action to the first application indicating whether the second application has the permission to access the resources. (See Krstic et al., Fig. 6, para. 43, i.e., If it is determined the second application is part of protected class, processing logic determines whether the second application specifically allows the first application to attach (e.g., exception) based on the entitlement of the second application. If so, the first application is allowed to attach to the second application and permission is granted to access the requested resources)
Krstic et al. (Fig. 6) discloses wherein the action is to grant the permission to the identifier, the request further comprising an identifier of the first application, and wherein the method further comprises: determining that the first application has permission to grant permissions to the second application based on the identifier of the first application. (See Krstic et al., Fig. 6, para. 43, i.e., after the access control manager grants permission to the identifier to access resources, a method for access control of an operating system is disclosed to determine that the processing logic receives a request from a first application (e.g., debugger) to attach to a second application (e.g., debuggee) wherein the request comprises a second application identifier associated with the second application (e.g., debuggee) and in response to the request, determine whether the second application is protected or part of a restricted class for permission to access resources. In response to the request, comparing the first and second identifiers and determines whether the second application is protected or as part of a restricted class of resources and if not, the first application may be allowed to attach to the second application. Krstic et al. discloses the verification step for indicating whether the second application has permission to access the resources is shown wherein if it is determined the second application is part of protected class, processing logic determines whether the second application specifically allows the first application to attach (e.g., exception) based on the entitlement of the second application. If so, the first application is allowed to attach to the second application and permission is granted to access the requested resources)
The combination of Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) fail to explicitly disclose wherein the first application is a service that enforces the permission using the request to the permission service.
Weiss et al. discloses a secure policy-based separation of data and application on computing devices that operate in different environments so that both types of applications can run simultaneously while complying with all required polices.
Weiss et al. discloses wherein the first application is a service that enforces the permission using the request to the permission service. (See Weiss et al., para. 181, 189-192, and 222-223, i.e., the first application for enforcing permission using a request is disclosed as the domain import-export enforcement point for enabling applications within a domain to interact with each other and avoid interaction with applications of other domains which permits a domain to maintain control over its data. Each domain application has at least one domain import-export policy enforcement points to enable data exchange to the permitted domain policies. In the dynamic domain checking method, domain membership of a domain import-export policy enforcement point or an application is done using policy elements that describe applications or their characteristics in conjunction with checks by the involved policy enforcement points (domain import-export policy enforcement points, Loader applications, or other policy enforcement points) at the time a request is made between applications or policy enforcement points. If a first application in a first domain makes a request for data from a second application in the first domain, the second application checks the first application for domain membership before responding to the request. The check can be for characteristics of the first application such as its UIC, the file storage location it was run from, the signature it was signed with, a password or other authentication for identifying the application uniquely or as a member of a selected group. The check can be performed by an aspect of the OS on some devices, or in a policy management point or policy enforcement point, such as a Loader application. If the characteristics of the first application meet those required by domain policy, the second application will respond to the request. If they do not, the second application will ignore the request, respond with an error, or take other action to refuse the request as deemed proper. The domain policy is distributed through one or more policy management points which allocate it to policy enforcement points, which translate and enforce domain policy as follows: the private domain storage location is translated to a local, encrypted storage location (e.g. a file system) on the local device, for example on the device's SD card. The private domain storage is mapped and permissioned so it is accessible only to domain applications (for example, using the device OS's user or group ID file protection mechanisms)
The rationale for combining Krstic et al. (Fig. 4) and Krstic et al. (Fig. 6) in view of Weiss et al. is the same as claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY D FIELDS whose telephone number is (571)272-3871. The examiner can normally be reached IFP M-F 8am-4:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/COURTNEY D FIELDS/Examiner, Art Unit 2436 March 21, 2026
/FATOUMATA TRAORE/Primary Examiner, Art Unit 2436