CTNF 18/488,537 CTNF 91080 DETAILED ACTION This office action is in response to claims filed 17 October 2023. Claims 1-20 are pending. Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Double Patenting 08-33 AIA 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 1, 8, and 15 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 8, and 15 of Patent No.: US 12,348,374 B2 (hereafter Reference Patent) in view of MITKAR et al. Pub. No.: US 2018/0285199 A1 (hereafter MITKAR). Regarding claim 1 of instant application, the following table emphasizes the similarities between it and claim 1 of the Reference Patent: Instant Application Reference Patent 1. A method for managing operation of endpoint devices of edge infrastructure, the method comprising: obtaining, from a requestor, an access request for a service to be provided by an endpoint device of the endpoint devices; obtaining, based on the requestor, a requestor activity profile; obtaining, based on the service, a service activity profile; obtaining, based on the requestor activity profile and the service activity profile, a container definition; and instantiating, using the container definition and to service the access request, a containerized service on the endpoint device to obtain an updated endpoint device that provides the service to the requestor. 1. A method for managing operation of endpoint devices of edge infrastructure, the method comprising: obtaining a container definition for a containerized service requested by a requestor; instantiating a first container based on a first portion of the container definition, the first portion of the container definition being based on a requestor activity profile for the requestor , the requestor activity profile being based on at least two measured activity profiles of users classified as having a same persona, the requestor being one of the users, and the at least two measured activity profiles specify characteristics of the users of corresponding endpoint devices of the endpoint devices used to provide other instances of the containerized service to the users; instantiating a second container hosted by the first container to obtain an instance of the containerized service, the second container being based on a second portion of the container definition; and providing computer implemented services using the containerized service hosted by an endpoint device of the endpoint devices. 7. The method of claim 1, wherein the second portion of the container definition is based on a service activity profile that specifies a second set of limits on use of the endpoint device by at least one application that provides, at least in part, the containerized service. While Claim 1 of the reference patent discusses obtaining both a requestor activity profile and a service activity profile, Claim 1 of the reference patent does not explicitly teach: obtaining, based on the requestor activity profile and the service activity profile , a container definition; However, in analogous art that similarly discusses instantiation of containerized services, MITKAR teaches: obtaining, based on the requestor activity profile and the service activity profile, a container definition ([0310] At block 616, the image generator 304 generates a container image ( i.e., “container definition” ) based at least in part on the retrieved application binaries, configuration data ( i.e., as discussed below in the rejection of claim 1 under 35 U.S.C 102(a)(1), application binaries and configuration data represent application “service activity profile” data ), and the user data ( i.e., “requestor activity profile” data )) ; It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined MITKAR’s teaching of building a container image definition based on application activity data and user activity data, with claim 1 of the reference application’s teaching of instantiating a container image based on either application activity data or user activity data, to realize, with a reasonable expectation of success, a system that obtains both requestor activity and service activity profiles, as in claim 1 of the reference patent, and generates a container image for instantiation based on both, as in MITKAR. A person having ordinary skill would have been motivated to make this combination to instantiate more optimal containerized services that better suit the needs of users based on their activity as well as the activity of the services themselves. Regarding claims 8, and 15, they comprise limitations similar to claim 1, and are therefore rejected for similar rationale. Claim Rejections - 35 USC § 102 07-07-aia AIA 07-07 The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – 07-08-aia AIA (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. 07-15 AIA Claim s 1-2, 8-9, and 15-16 are rejected under 35 U.S.C. 102( a)(1 ) as being anticipated by MITKAR et al. Pub. No.: US 2018/0285199 A1 (hereafter MITKAR, as cited above) . Regarding claim 1, MITKAR teaches: A method for managing operation of endpoint devices of edge infrastructure, the method comprising: obtaining, from a requestor, an access request for a service ([0303] The process 600 begins at block 602 where, for example, the image generator 304 receives a selection of an application to include in a container image ( i.e., a request for an application requests the “services” provided by that application (see [0065] for a list of various “services” provided by applications including email, file system, database, etc.) )) to be provided by an endpoint device of the endpoint devices ([0005] A container may be instantiated or formed on a computing system from a container image) ; obtaining, based on the requestor, a requestor activity profile ([0308] At block 612, the image generator 304 identifies the storage location at the secondary storage system 118 of user data generated by the application selected at the block 602 at the client computing device 102. [0309] At block 614, the media agent 144 retrieves the data from the secondary storage devices 108 corresponding to the storage locations identified at the block 612 ( i.e., retrieving user data indicative of activities performed for the user represents obtaining a “requestor activity profile” )) ; obtaining, based on the service, a service activity profile ([0305] At block 606, the media agent 144 retrieves the application binaries from the secondary storage devices 108 corresponding to the storage locations identified at the block 604. [0306] At block 608, the image generator 304 identifies the storage location at the secondary storage system 118 of configuration data associated with the application selected at the block 602. [0307] At block 610, the media agent 144 retrieves the configuration data from the secondary storage devices 108 corresponding to the storage locations identified at the block 608 ( i.e., retrieving either application binaries representing execution activity of the application, or configuration data of the application representing data associated with the activity of the application, represents obtaining a “service activity profile” )) ; obtaining, based on the requestor activity profile and the service activity profile, a container definition ([0310] At block 616, the image generator 304 generates a container image ( i.e., “container definition” ) based at least in part on the retrieved application binaries, configuration data, and the user data) ; and instantiating, using the container definition and to service the access request, a containerized service on the endpoint device to obtain an updated endpoint device that provides the service to the requestor ([0005] A container may be instantiated or formed on a computing system from a container image ( i.e., instantiating the container on the computing system “updates” the computing system to provide the application to the user requesting the application )) . Regarding claim 2, MITKAR further teaches: the requestor activity profile specifies a first set of limits on use of the endpoint device by the requestor ([0274] Classifying the data may include identifying one or more applications 110, configuration data or information for one or more of the applications 110, data created in response to interaction with the applications 110 (e.g., files, application state information, or other user data that may be created or modified in response to a user's interaction with the applications 110), or any other types of data that may be associated with the one or more applications 110. The user data created in response to interaction with the applications 110 may refer to any type of data that may be created or modified in response to a user's interaction with one or more of the applications 110. Typically, this user data is separate from the files required to install or execute the applications 110. However, in some cases, the user data may include a modified form of a file used to facilitate execution of an application, such as a configuration file or a state saving file. In one example, the user data may include files created by the user or application state information generated or modified in response to a user's interaction with the application 110. For instance, for a word processing application, the configuration data may include a default folder for storing user data, and the user data may refer to one or more documents created by a user using the word processing application. As another example, for a webserver management application, the configuration data may include access control information for users, and the user data may refer to one or more webpages to be served by the webserver managed by the Web server management application ( i.e., user data imposes limits on execution of a container based on user interaction with the application; those limits include what files or documents to use, what webpages to serve by a webserver, etc. )) . Regarding claims 8-9, and 15-16, they comprise limitations similar to those of claims 1-2, and are therefore rejected for similar rationale . Claim Rejections - 35 USC § 103 07-20-aia AIA The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA Claim s 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, as applied to claims 2, 9, and 16 above, and in further view of CHAWLA et al. Patent No.: US 8,555,274 B1 (hereafter CHAWLA) . Regarding claim 3, MITKAR further teaches: the first set of limits comprising… a second limit on use of applications hostable by the endpoint device ([0274] However, in some cases, the user data may include a modified form of a file used to facilitate execution of an application, such as a configuration file or a state saving file. In one example, the user data may include files created by the user or application state information generated or modified in response to a user's interaction with the application 110. For instance, for a word processing application, the configuration data may include a default folder for storing user data, and the user data may refer to one or more documents created by a user using the word processing application. As another example, for a webserver management application, the configuration data may include access control information for users, and the user data may refer to one or more webpages to be served by the webserver managed by the Web server management application ( i.e., user data specifies, or “limits” aspects of execution of at least a word processing application or a webserver application in the examples by specifying documents for the word processing application to use, or webpages for the webserver to serve )) ; a third limit on use of portions of data hostable by the endpoint device ([0274] In some cases, the user data may include a modified form of a file used to facilitate execution of an application, such as a configuration file or a state saving file. In one example, the user data may include files created by the user or application state information generated or modified in response to a user's interaction with the application 110. For instance, for a word processing application, the configuration data may include a default folder for storing user data ( i.e., user data specifies, or “limits” where files created by the user are stored and used )) ; and a fourth limit on distribution, by the requestor, of data hosted by the endpoint device ([0274] As another example, for a webserver management application, the configuration data may include access control information for users, and the user data may refer to one or more webpages to be served by the webserver managed by the Web server management application ( i.e., user data specifies, or “limits” at least the web pages served, or “distributed” to the user )) . While MITKAR discusses provisioning the first set of limits comprising: a first limit on use of hardware resources of the endpoint device However, in analogous art that similarly provisions containers on endpoint devices, CHAWLA teaches: the first set of limits comprising: a first limit on use of hardware resources of the endpoint device ([Column 7, Lines 39] A method of providing a remote virtualized desktop to a user includes describing resource parameters for a user, the resource parameters specifying a maximum resource allocation for all virtual machines provided to a particular user, the resource parameters including at least one of a central processing unit (CPU) usage and a memory usage ( i.e., resource parameters represent a “first limit” on use of CPU or memory resources for a particular user )) . It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined CHAWLA’s teaching of provisioning a container on an endpoint device based on user parameters related to use of hardware resource, with MITKAR’s teaching of provisioning a container on an endpoint device based on user parameters, to realize, with a reason able expectation of success, a system that provisions a container on an endpoint based on user parameters, as in MITKAR, which include parameters related to limits of hardware resource use, as in CHAWLA. A person having ordinary skill would have been motivated to make this combination to ensure that load balancing is achieved, QoS parameters are met, and that resource quotas allocated to each user are not exceeded (CHAWLA Abstract). Regarding claims 10, and 17, they comprise limitations similar to claim 3, and are therefore rejected for similar rationale . 07-21-aia AIA Claim s 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, in view of CHAWLA, as applied to claims 3, 10, and 17 above, and in further view of MEHTA et al. Pub. No.: US 2011/0320307 A1 (hereafter MEHTA) . Regarding claim 4, while MITKAR and CHAWLA discuss execution of applications providing services, they do not explicitly teach: the requestor activity profile is based on at least two measured activity profiles of users classified as having a same persona, and the at least two measured activity profiles specifying characteristics of users of corresponding endpoint devices of the endpoint devices used to provide other instances of the service to the users . However, in analogous art that similarly teaches execution of applications providing services, MEHTA teaches: the requestor activity profile is based on at least two measured activity profiles of users classified as having a same persona ([0045] As shown by arrow 212, device usage data, location data, and/or application data may be provided by the data aggregation server 210 to a model generation server 220. In some implementations, the model generation server 220 may poll data at predetermined intervals (e.g., once per week, once per day, once per hour, or some other interval), or may receive data in real-time. Based at least in part on data provided by the data aggregation server 210, for example, the model generation server 220 may generate multiple user profiles (e.g., similar to the profile generator 130, shown in FIG. 1). In some implementations, the user profiles may be used by the model generation server 220 to build one or more offline models, by detecting patterns relevant to application usage and/or installation history over a population of users ( i.e., application history patterns for a single user identity or “persona “represent at least two activity profiles of applications used by the user identity for users having the same user identity )) , and the at least two measured activity profiles specifying characteristics of users of corresponding endpoint devices of the endpoint devices used to provide other instances of the service to the users ([0061] Application management data is received (404), and location data is received (406). In some implementations, application management data and location data associated with a requesting device (e.g., any of the mobile devices 202A-C) may be provided by the device with a recommendation request. In some implementations, application management data and location data may be retrieved from the model generation server 220 (as shown in FIG. 2) or the profile server 130 (as shown in FIG. 1). For example, profile data associated with device users may be maintained and updated (e.g., during installs, uninstalls, etc.). [0068] Application recommendations are provided to the device user at 418. In some implementations, a subset of the ranked list of recommendations may be initially provided. For example, several (e.g., 5, 10, 50, etc.) recommendations may be initially provided, and a mechanism (e.g., a link) may be provided to the user such that the user may request additional recommendations ( i.e., subsequent instances of application services are provided based on recommendations for applications which are themselves based on measured activity profiles )) . It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined MEHTA’s teaching of user activity profiles representing patterns of application usage for use in recommending subsequent applications, with MITKAR and CHAWLA’s teaching of provisioning containerized applications on endpoint resources, to realize, with a reasonable expectation of success, a system that provisions containerized applications on endpoint resources, as in MITKAR and CHAWLA, based on application recommendations which are themselves based on user activity profiles representing patterns of application usage for user personas, as in MEHTA. A person having ordinary skill would have been motivated to make this combination to make better recommendations for applications to improve user experience. Regarding claims 11, and 18, they comprise limitations similar to claim 4, and are therefore rejected for similar rationale . 07-21-aia AIA Claim s 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, as applied to claims 2, 9, and 16 above, and in further view of SAEKI Pub. No.: US 2023/0236818 A1 (hereafter SAEKI) . Regarding claim 5, while MITKAR discusses provisioning of containers on endpoint devices, MITKAR does not explicitly teach: the service activity profile specifies a second set of limits on use of the endpoint device by at least one application that provides, at least in part, the service . However, in analogous art that similarly provisions containers on endpoint devices, SAEKI teaches: the service activity profile specifies a second set of limits on use of the endpoint device by at least one application that provides, at least in part, the service ([0103] A certain margin of resource usage can be added to the resource usage to calculate a container resource usage limit value ( i.e., “second set of limits on use of an endpoint device” ). The container resource usage limit value can be obtained by statistically processing the resource usage data in the time periods of the feature vectors belonging to the cluster. For example, extreme outliers are excluded, and an arithmetic average is calculated for each of (the CPU, the virtual memory capacity, the storage capacity, and the network bandwidth) of the resource usage data for each feature vector v ( i.e., CPU, memory, and network bandwidth limits represent limits on use of resources of the endpoint device by a container providing a service )) . It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined SAEKI’s teaching of setting usage limit values related to application utilization of container resources including CPU, memory and network bandwidth, with MITKAR’s teaching of provisioning containerized applications on endpoint devices, to realize, with a reasonable expectation of success, a system that provisions containerized applications on endpoint devices, as in MITKAR, according to usage limit values set for application utilization of container resources, as in SAEKI. A person of ordinary skill would have been motivated to make this combination to improve efficiency of cloud resource usage and optimally deploy an application on a container of the cloud (SAEKI [0014]). Regarding claims 12 and 19, they comprise limitations similar to claim 5, and are therefore rejected for similar rationale . 07-21-aia AIA Claim s 6, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, in view of SAEKI, as applied to claims 5, 12, and 19 above, and in further view of BANKA et al. Pub. No.: US 2024/0403139 A1 (hereafter BANKA) . Regarding claim 6, SAEKI further teaches: the second set of limits comprising: a maximum quantity of computing resources of the endpoint device usable to provide the service; a network connectivity limit for the service…and a storage area access limit for the service ([0103] A certain margin of resource usage can be added to the resource usage to calculate a container resource usage limit value ( i.e., “second set of limits on use of an endpoint device” ). The container resource usage limit value can be obtained by statistically processing the resource usage data in the time periods of the feature vectors belonging to the cluster. For example, extreme outliers are excluded, and an arithmetic average is calculated for each of (the CPU ( i.e., “computing resources” ), the virtual memory capacity, the storage capacity ( i.e., virtual and physical “storage area access” ), and the network bandwidth ( i.e., network “connectivity limit” )) of the resource usage data for each feature vector v ( i.e., CPU, memory, and network bandwidth limits represent limits on use of resources of the endpoint device by a container providing a service )) . While MITKAR and SAEKI teaches setting limits for resource consumption by containerized applications, MITKAR and SAEKI does not explicitly teach: the second set of limits comprising… a network reachability limit for the service ; However, in analogous art that similarly discusses provisioning resources to containerized applications based on resource limits, BANKA teaches: the second set of limits comprising…a network reachability limit for the service ([0010] based on such a directive from the analytics system, the scheduler for the container orchestration system may process the network telemetry data, node telemetry data, and/or the application performance data to reprovision a workload to a different worker node. In some examples, the scheduler may determine that current network telemetry data indicates that a minimum bandwidth or minimum latency requirement for a workload can be met by scheduling the workload to a particular node having sufficient network resource availability ( i.e., minimum latency requirement represents a “reachability” limit of a network that is used to provision network resources to a containerized application )) ; It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined BANKA’s teaching of a minimum latency requirement used to provision network resources to a containerized application, with the combination of MITKAR and SAEKI’s teaching of resource limits used to provision resources to containerized applications, to realize, with a reasonable expectation of success, a system that provisions resources to containerized applications based on resource limits, as in MITKAR and SAEKI, which include minimum latency requirement limits, as in BANKA. A person having ordinary skill would have been motivated to make this combination to ensure provisioned containerized applications meet minimum latency requirements. Regarding claims 13, and 20, they comprise limitations similar to claim 6, and are therefore rejected for similar rationale . 07-21-aia AIA Claim s 7, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over MITKAR, in view of SAEKI, in view of BANKA, as applied to claims 6 and 13 above, and in further view of MEHTA (cited above) . Regarding claim 7, while MITKAR, SAEKI, and BANKA discuss execution of applications providing services, they do not explicitly teach: the service activity profile is based on at least two measured activity profiles of users classified as having a same persona, and the at least two measured activity profiles specifying characteristics of applications used to provide other instances of the service . However, in analogous art that similarly teaches execution of applications providing services, MEHTA teaches: the service activity profile is based on at least two measured activity profiles of users classified as having a same persona ([0045] As shown by arrow 212, device usage data, location data, and/or application data may be provided by the data aggregation server 210 to a model generation server 220. In some implementations, the model generation server 220 may poll data at predetermined intervals (e.g., once per week, once per day, once per hour, or some other interval), or may receive data in real-time. Based at least in part on data provided by the data aggregation server 210, for example, the model generation server 220 may generate multiple user profiles (e.g., similar to the profile generator 130, shown in FIG. 1). In some implementations, the user profiles may be used by the model generation server 220 to build one or more offline models, by detecting patterns relevant to application usage and/or installation history over a population of users ( i.e., application history patterns for a single user identity or “persona “represent at least two activity profiles of applications used by the user identity for users having the same user identity )) , and the at least two measured activity profiles specifying characteristics of applications used to provide other instances of the service ([0061] Application management data is received (404), and location data is received (406). In some implementations, application management data and location data associated with a requesting device (e.g., any of the mobile devices 202A-C) may be provided by the device with a recommendation request. In some implementations, application management data and location data may be retrieved from the model generation server 220 (as shown in FIG. 2) or the profile server 130 (as shown in FIG. 1). For example, profile data associated with device users may be maintained and updated (e.g., during installs, uninstalls, etc.). [0068] Application recommendations are provided to the device user at 418. In some implementations, a subset of the ranked list of recommendations may be initially provided. For example, several (e.g., 5, 10, 50, etc.) recommendations may be initially provided, and a mechanism (e.g., a link) may be provided to the user such that the user may request additional recommendations ( i.e., subsequent instances of application services are provided based on recommendations for applications which are themselves based on measured activity profiles specifying characteristics of application patterns )) . It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined MEHTA’s teaching of user activity profiles representing patterns of application usage for use in recommending subsequent applications, with MITKAR, SAEKI, and BANKA’s teaching of provisioning containerized applications on endpoint resources, to realize, with a reasonable expectation of success, a system that provisions containerized applications on endpoint resources, as in MITKAR, SAEKI, and BANKA, based on application recommendations which are themselves based on user activity profiles representing patterns of application usage for user personas, as in MEHTA. A person having ordinary skill would have been motivated to make this combination to make better recommendations for applications to improve user experience. Regarding claim 14, it comprises limitations similar to claim 7, and is therefore rejected for similar rationale. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W AYERS whose telephone number is (571)272-6420. The examiner can normally be reached M-F 8:30-5 PM. 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, Aimee Li can be reached at (571) 272-4169. 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. /MICHAEL W AYERS/Primary Examiner, Art Unit 2195 Application/Control Number: 18/488,537 Page 2 Art Unit: 2195 Application/Control Number: 18/488,537 Page 3 Art Unit: 2195 Application/Control Number: 18/488,537 Page 4 Art Unit: 2195 Application/Control Number: 18/488,537 Page 5 Art Unit: 2195 Application/Control Number: 18/488,537 Page 6 Art Unit: 2195 Application/Control Number: 18/488,537 Page 7 Art Unit: 2195 Application/Control Number: 18/488,537 Page 8 Art Unit: 2195 Application/Control Number: 18/488,537 Page 9 Art Unit: 2195 Application/Control Number: 18/488,537 Page 10 Art Unit: 2195 Application/Control Number: 18/488,537 Page 11 Art Unit: 2195 Application/Control Number: 18/488,537 Page 13 Art Unit: 2195 Application/Control Number: 18/488,537 Page 15 Art Unit: 2195 Application/Control Number: 18/488,537 Page 16 Art Unit: 2195 Application/Control Number: 18/488,537 Page 17 Art Unit: 2195 Application/Control Number: 18/488,537 Page 18 Art Unit: 2195