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. Detail action Claims 1-15 and 17-21 are pending and being considered. Claims 4, 6, 9, 14, 19 and 21 are amended. Claims 16 and 22 have been cancelled. Priority Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Specification The specification filed on September 29 , 20 23 is accepted. Drawings The drawings filed on September 29, 2023 are accepted. Information Disclosure Statement The information disclosure statement (IDS) submitted on 11/29/2023 was filed after the mailing date of the application no. 18/565437. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1 1 -1 5 and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because the claims do not include at least one hardware element in the bodies as required by MPEP 2106(I). Claim 1 1 recites the system comprises a verification management center and a container cluster , and the container cluster comprises a master node and a plurality of slave nodes . The examiner notes that master node and slave node is not exclusively a piece of hardware it may be a server in blockchain network such as physical server or virtual server ". Dependent claims 1 2-1 5 and 17-20 are also rejected under 35 USC 101, because they do not cure the deficiencies of independent claims 1 1. 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. Claims 1 -8, 10-15 , 17, 18, 20 and 21 are rejected under 35 U.S.C. 103 a s being unpatentable over ZHOU et al (hereinafter ZHOU ) (US 20190004868 ) in view of Ruggiero et al (hereinafter Ruggiero ) (US 8769537 ) . Regarding claim 1 ZHOU teaches a method for performing service verification on a plurality of parties in federated computation based on a container cluster (ZHOU [0004] teaches a system and method for distributed graphics processing unit (GPU) computation. The system and method of an example embodiment relate to graphic data processing using distributed GPUs based on container -enabled systems, or CPUs based on container -enabled systems); wherein the container cluster comprises a master node and a plurality of slave nodes respectively deployed in a plurality of participants (ZHOU on [0004-0005] teaches the system of an example embodiment includes a master node, a load balancing node, and multiple slave nodes configured with multiple GPUs being mounted on distributed container s) ; and the method comprises: sending, by a verification management center, a task establishment request to the master node in response to a service verification request of a user ( ZHOU Fig 3 and text on [0034] teaches an initial operation, a user at a user node 141 (i.e., verification management center) issues a user task service request (i.e., task establishment request) to the master node 110 via a data communication. In response to the user task service request, the master node 110 can query one or more slave nodes 130 to determine the resource usage or availability on the slave nodes 130 ) ; wherein the task establishment request indicates at least a target service that is to be verified and that is used by a target participant ( ZHOU on [0034] teaches the master node 110 can determine the number of slave node 130 resources needed and available to service the user task request . The nature of the user task service request can be determined from the user task service request itself. In an example embodiment, the user node 141 can encode into the user task service request information indicative of the distributed processing container name, a number of request ed distributed containers, whether the task is a CPU intensive task or a GPU intensive task, a quantity of the GPU resources needed to service the request , and other information describing details of the user task service . See on [0032] teaches the slave system management module 210 can also be configured to assign user tasks to and start corresponding services on particular slave nodes 130 and the GPUs 132 and processing container thereon ) ; creating, by the master node, a verification task of the target service for a target slave node in the target participant based on the task establishment request ( ZHOU on [0034] teaches In response to the user task service request , the master node 110 can query one or more slave nodes 130 to determine the resource usage or availability (i.e., a verification task of the target service) on the slave nodes 130. In particular, the master node 110 can query the usage or availability of the GPU(s) on each of the slave nodes 130. In response to the query from the master node 110, each of the slave nodes 130 can return information indicative of the resource usage or availability on the slave nodes 130. As a result, the master node 110 can determine the GPU availability on the plurality of slave nodes 130. Based on this information and the nature of the user task service request , the master node 110 can determine the number of slave node 130 resources needed and available to service the user task request ) ; verifying, by the target slave node, a target service of the target participant in response to the verification task, to obtain a service verification result ( ZHOU on [0034] teaches the master node 110 can assign the user task service request to one or more available slave nodes 130 and one or more of the GPUs 132. The master node 110 can also start a service on the one or more GPUs 132 using a distributed processing container for the user task request. Once the master node 110 starts the service on the one or more GPUs 132 using the distributed processing container, the distributed processing container can return to the master node 110 a URL (i.e., verification result) corresponding to the GPUs 132 and the user task service request) ; and providing, by the target slave node, the service verification result for the verification management center ( ZHOU on [0035] teaches the load balancing node 120 can also generate an overall unique URL that corresponds to the plurality of load balanced slave nodes 130 and GPUs 132. This unique URL can be sent from the load balancing node 120 to the master node 110. The overall unique URL can be forwarded from the master node 110 to the user node 141 that originated the user task service request. The user node 141 can use the overall unique URL to subsequently request a status of the user task service request from the master node 110 ). ZHOU fails to explicitly teach sending task establishment request in to a service verification request, however Ruggiero from analogous art teaches sending, by a verification management center, a task establishment request to the master node in response to a service verification request of a user (Ruggiero Fig 4 and text on [col 7 line 10-25 and col 7 line 50-60 ] teaches parent job runtime object comprises instructions for the master server for coordinating job execution in response to a job request made by a user) . T hus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Ruggiero into the teaching of ZHOU by sending task establishment request for executing a task in response to service request from user . One would be motivated to do so in order to e xecute task based on user requesting service ( Ruggiero [ col 1 line 5-30 ] ). Regarding claim 11 ZHOU teaches a system for performing service verification on a plurality of parties in federated computation based on a container cluster (ZHOU [0004] teaches a system and method for distributed graphics processing unit (GPU) computation. The system and method of an example embodiment relate to graphic data processing using distributed GPUs based on container -enabled systems, or CPUs based on container -enabled systems); wherein the system comprises a verification management center and a container cluster, and the container cluster comprises a master node and a plurality of slave nodes respectively deployed in a plurality of participants (ZHOU on [0004-0005] teaches the system of an example embodiment includes a master node, a load balancing node, and multiple slave nodes configured with multiple GPUs being mounted on distributed container s) ; wherein the verification management center is configured to send a task establishment request to the master node in response to a service verification request of a user ( ZHOU Fig 3 and text on [0034] teaches an initial operation, a user at a user node 141 (i.e., verification management center) issues a user task service request (i.e., task establishment request) to the master node 110 via a data communication. In response to the user task service request, the master node 110 can query one or more slave nodes 130 to determine the resource usage or availability on the slave nodes 130 ); wherein the task establishment request indicates at least a target service that is to be verified and that is used by a target participant ( ZHOU on [0034] teaches the master node 110 can determine the number of slave node 130 resources needed and available to service the user task request . The nature of the user task service request can be determined from the user task service request itself. In an example embodiment, the user node 141 can encode into the user task service request information indicative of the distributed processing container name, a number of request ed distributed containers, whether the task is a CPU intensive task or a GPU intensive task, a quantity of the GPU resources needed to service the request , and other information describing details of the user task service. See on [0032] teaches the slave system management module 210 can also be configured to assign user tasks to and start corresponding services on particular slave nodes 130 and the GPUs 132 and processing container thereon ) ; the master node is configured to create a verification task of the target service for a target slave node in the target participant based on the task establishment request ( ZHOU on [0034] teaches In response to the user task service request , the master node 110 can query one or more slave nodes 130 to determine the resource usage or availability (i.e., a verification task of the target service) on the slave nodes 130. In particular, the master node 110 can query the usage or availability of the GPU(s) on each of the slave nodes 130. In response to the query from the master node 110, each of the slave nodes 130 can return information indicative of the resource usage or availability on the slave nodes 130. As a result, the master node 110 can determine the GPU availability on the plurality of slave nodes 130. Based on this information and the nature of the user task service request , the master node 110 can determine the number of slave node 130 resources needed and available to service the user task request ) ; the target slave node is configured to verify a target service of the target participant in response to the verification task, to obtain a service verification result ( ZHOU on [0034] teaches the master node 110 can assign the user task service request to one or more available slave nodes 130 and one or more of the GPUs 132. The master node 110 can also start a service on the one or more GPUs 132 using a distributed processing container for the user task request. Once the master node 110 starts the service on the one or more GPUs 132 using the distributed processing container, the distributed processing container can return to the master node 110 a URL (i.e., verification result) corresponding to the GPUs 132 and the user task service request) ; and the target slave node is further configured to provide the service verification result for the verification management center ( ZHOU on [0035] teaches the load balancing node 120 can also generate an overall unique URL that corresponds to the plurality of load balanced slave nodes 130 and GPUs 132. This unique URL can be sent from the load balancing node 120 to the master node 110. The overall unique URL can be forwarded from the master node 110 to the user node 141 that originated the user task service request. The user node 141 can use the overall unique URL to subsequently request a status of the user task service request from the master node 110 ). ZHOU fails to explicitly teach sending task establishment request in to a service verification request, however Ruggiero from analogous art teaches sending, by a verification management center, a task establishment request to the master node in response to a service verification request of a user (Ruggiero Fig 4 and text on [col 7 line 10-25 and col 7 line 50-60 ] teaches parent job runtime object comprises instructions for the master server for coordinating job execution in response to a job request made by a user) . T hus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Ruggiero into the teaching of ZHOU by sending task establishment request for executing a task in response to service request from user. One would be motivated to do so in order to execute task based on user requesting service ( Ruggiero [ col 1 line 5-30 ] ). Regarding claim 2 and 12 the combination of ZHOU and Ruggiero teaches all the limitations of claims 1 and 11, Ruggiero further teaches wherein the task establishment request indicates at least a unique identifier of data to be verified; and the creating a verification task of the target service for a target slave node in the target participant comprises: adding the unique identifier of the data to be verified to a configuration parameter of the verification task as a verification basis (Ruggiero Fig 4 and text on [col 15 line 40-45] teaches each instance the calculation writes down a unique ID of the instance (e.g., in the case of persisted instances), or the computed instance (e.g., in the case of calculated instances) . See on [col 17 line 53-56] teaches calculations operate on mathematical sets of instances where membership in the set is determined by the unique ID assigned to each instance). T hus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Ruggiero into the teaching of ZHOU by adding the unique identifier of the data to be verified to a configuration parameter of the verification task as a verification basis . One would be motivated to do so in order to execute task based on user requesting service ( Ruggiero [ col 1 line 5-30 ] ). Regarding claim 3 and 13 the combination of ZHOU and Ruggiero teaches all the limitations of claims 1 and 11, ZHOU further teaches wherein the verifying, by the target slave node a target service of the target participant in response to the verification task comprises: listening for, by a container management component in the target slave node, the verification task, and when obtaining the verification task through listening, starting a verification module in the target slave node, and verifying the target service by using the verification module ( ZHOU on [0034] teaches the master node 110 can assign the user task service request to one or more available slave nodes 130 and one or more of the GPUs 132. The master node 110 can also start a service on the one or more GPUs 132 using a distributed processing container for the user task request. Once the master node 110 starts the service on the one or more GPUs 132 using the distributed processing container, the distributed processing container can return to the master node 110 a URL corresponding to the GPUs 132 and the user task service request) . Regarding claim 4 and 14 the combination of ZHOU and Ruggiero teaches all the limitations of claims 3 and 13, Ruggiero further teaches wherein the verifying the target service by using the verification module comprises: invoking an interface of the target service by using the verification module, to obtain a verification result of data to be verified; and upon determining that the verification result satisfies a predetermined condition, determining that the service verification result is a verification success (Ruggiero Fig 7 block 700, 702, 704, 706 and text on [col 10 line 60-67 and col 11 line 1-30] teaches If it is determined that the job includes a method that does not output a set, control passes to 708. In 702, it is determined whether each method output type is compatible with the following method input type. In some embodiments, determining whether each method output type is compatible with the following method input type comprises determining the method selected for each operation in the job that requires a method (e.g., each CALC, UPDT, and AGGR operation), querying the method for its input and output type, and comparing the output type of each method with the input type of the method in the following operation. In some embodiments, the methods must match exactly. Further teaches determining whether every method input parameter is defined comprises determining the method selected for each operation in the job that requires a method (e.g., each CALC, UPDT, and AGGR operation), querying the method for its input parameters, and checking that those input parameters are defined (e.g., in step 602 of FIG. 6). If it is determined that every method input parameter is defined, control passes to 706. If it is determined that the job includes a method with an input parameter that is not defined, control passes to 708. In 706, the process returns success, and ends). T hus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Ruggiero into the teaching of ZHOU by d etermining that the verification result satisfies a predetermined condition . One would be motivated to do so in order to validate whether the task have been successfully executed ( Ruggiero [ col 1 line 5-30 ] ). Regarding claim 5 and 15 the combination of ZHOU and Ruggiero teaches all the limitations of claims 4 and 14, Ruggiero further teaches wherein the verification result comprises a quantity of fields comprised in the data to be verified and/or data types of at least a part of fields (Ruggiero Fig 7 block 700, 702, 704, 706 and text on [col 10 line 60-67 and col 11 line 1-30] teaches If it is determined that the job includes a method that does not output a set, control passes to 708. In 702, it is determined whether each method output type is compatible with the following method input type. In some embodiments, determining whether each method output type is compatible with the following method input type comprises determining the method selected for each operation in the job that requires a method (e.g., each CALC, UPDT, and AGGR operation), querying the method for its input and output type, and comparing the output type of each method with the input type of the method in the following operation. In some embodiments, the methods must match exactly. Further teaches determining whether every method input parameter is defined comprises determining the method selected for each operation in the job that requires a method (e.g., each CALC, UPDT, and AGGR operation), querying the method for its input parameters, and checking that those input parameters are defined (e.g., in step 602 of FIG. 6). If it is determined that every method input parameter is defined, control passes to 706. If it is determined that the job includes a method with an input parameter that is not defined, control passes to 708. In 706, the process returns success, and ends). T hus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Ruggiero into the teaching of ZHOU by d etermining that the verification result satisfies a predetermined condition . One would be motivated to do so in order to validate whether the task have been successfully executed ( Ruggiero [ col 1 line 5-30 ] ). Regarding claim 6 the combination of ZHOU and Ruggiero teaches all the limitations of claims 4, Ruggiero further teaches upon determining that the invoking of the interface of the target service fails, determining that the service verification result is a verification failure; or upon determining that the verification result does not satisfy the predetermined condition, determining that the service verification result is a verification failure (Ruggiero Fig 7 block 708 and text on [col 11 line 1-30] teaches determining whether every method input parameter is defined comprises determining the method selected for each operation in the job that requires a method (e.g., each CALC, UPDT, and AGGR operation), querying the method for its input parameters, and checking that those input parameters are defined (e.g., in step 602 of FIG. 6). If it is determined that every method input parameter is defined, control passes to 706. If it is determined that the job includes a method with an input parameter that is not defined, control passes to 708. In 706, the process returns success, and ends . The process returning success indicates that the job is allowed to run. In 708, the process returns failure, and ends. The process returning failure indicates that the job is not allowed to run ). Regarding claim 7 and 17 the combination of ZHOU and Ruggiero teaches all the limitations of claims 1 and 11, ZHOU further teaches after the sending a task establishment request to the master node, further comprising: initializing, by the verification management center, a task state of the verification task; and updating, by the verification management center, the task state based on the service verification result after receiving the service verification result (ZHOU on [0032] teaches the slave system management module 210 can be configured to handle a user task request to start a user task service, stop service, or query a user task service stat us. See on [0035 -0036 ] teaches the overall unique URL can be forwarded from the master node 110 to the user node 141 that originated user task service request. The user node 141 can use the overall unique URL to subsequently request a stat us of the user task service request from the master node 110) . Regarding claim 8 and 18 the combination of ZHOU and Ruggiero teaches all the limitations of claims 7 and 17, ZHOU further teaches wherein before the providing, by the target slave node, the service verification result for the verification management center, the method further comprises: receiving, by the verification management center, a task start notification sent by the target slave node after starting to verify the target service; and updating, by the verification management center, the initialized task state based on the task start notification to obtain an intermediate state; and the updating the task state based on the service verification result comprises: updating the intermediate state based on the service verification result (ZHOU on [0032] teaches the slave system management module 210 can be configured to handle a user task request to start a user task service, stop service, or query a user task service stat us. See on [0035 -0036 ] teaches the overall unique URL can be forwarded from the master node 110 to the user node 141 that originated user task service request. The user node 141 can use the overall unique URL to subsequently request a stat us of the user task service request from the master node 110) . Regarding claim 10 and 20 the combination of ZHOU and Ruggiero teaches all the limitations of claims 1 and 11, ZHOU further teaches wherein the target service comprises at least one of a storage service, an audit service, and a preprocessing service of local feature data ( ZHOU on [0034] teaches the master node 110 can determine the number of slave node 130 resources needed and available to service the user task request . The nature of the user task service request can be determined from the user task service request itself. In an example embodiment, the user node 141 can encode into the user task service request information indicative of the distributed processing container name, a number of request ed distributed containers, whether the task is a CPU intensive task or a GPU intensive task, a quantity of the GPU resources needed to service the request , and other information describing details of the user task service. See on [0032] teaches the slave system management module 210 can also be configured to assign user tasks to and start corresponding services on particular slave nodes 130 and the GPUs 132 and processing container thereon ) . Regarding claim 21 ZHOU teaches a non-transitory computer-readable storage medium, comprising instructions stored therein that, when executed by a processor of a computing device, cause the processor to: (ZHOU on [0040] teaches non-transitory storage medium for storing instructions executed by a processor); send, by a verification management center, a task establishment request to the master node in response to a service verification request of a user ( ZHOU Fig 3 and text on [0034] teaches an initial operation, a user at a user node 141 (i.e., verification management center) issues a user task service request (i.e., task establishment request) to the master node 110 via a data communication. In response to the user task service request, the master node 110 can query one or more slave nodes 130 to determine the resource usage or availability on the slave nodes 130 ); wherein the task establishment request indicates at least a target service that is to be verified and that is used by a target participant ( ZHOU on [0034] teaches the master node 110 can determine the number of slave node 130 resources needed and available to service the user task request . The nature of the user task service request can be determined from the user task service request itself. In an example embodiment, the user node 141 can encode into the user task service request information indicative of the distributed processing container name, a number of request ed distributed containers, whether the task is a CPU intensive task or a GPU intensive task, a quantity of the GPU resources needed to service the request , and other information describing details of the user task service. See on [0032] teaches the slave system management module 210 can also be configured to assign user tasks to and start corresponding services on particular slave nodes 130 and the GPUs 132 and processing container thereon ) ; create, by the master node, a verification task of the target service for a target slave node in the target participant based on the task establishment request ( ZHOU on [0034] teaches In response to the user task service request , the master node 110 can query one or more slave nodes 130 to determine the resource usage or availability (i.e., a verification task of the target service) on the slave nodes 130. In particular, the master node 110 can query the usage or availability of the GPU(s) on each of the slave nodes 130. In response to the query from the master node 110, each of the slave nodes 130 can return information indicative of the resource usage or availability on the slave nodes 130. As a result, the master node 110 can determine the GPU availability on the plurality of slave nodes 130. Based on this information and the nature of the user task service request , the master node 110 can determine the number of slave node 130 resources needed and available to service the user task request ) ; verify, by the target slave node, a target service of the target participant in response to the verification task, to obtain a service verification result ( ZHOU on [0034] teaches the master node 110 can assign the user task service request to one or more available slave nodes 130 and one or more of the GPUs 132. The master node 110 can also start a service on the one or more GPUs 132 using a distributed processing container for the user task request. Once the master node 110 starts the service on the one or more GPUs 132 using the distributed processing container, the distributed processing container can return to the master node 110 a URL (i.e., verification result) corresponding to the GPUs 132 and the user task service request) ; and provide, by the target slave node, the service verification result for the verification management center ( ZHOU on [0035] teaches the load balancing node 120 can also generate an overall unique URL that corresponds to the plurality of load balanced slave nodes 130 and GPUs 132. This unique URL can be sent from the load balancing node 120 to the master node 110. The overall unique URL can be forwarded from the master node 110 to the user node 141 that originated the user task service request. The user node 141 can use the overall unique URL to subsequently request a status of the user task service request from the master node 110 ). ZHOU fails to explicitly teach sending task establishment request in to a service verification request, however Ruggiero from analogous art teaches send, by a verification management center, a task establishment request to the master node in response to a service verification request of a user (Ruggiero Fig 4 and text on [col 7 line 10-25 and col 7 line 50-60 ] teaches parent job runtime object comprises instructions for the master server for coordinating job execution in response to a job request made by a user) . T hus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Ruggiero into the teaching of ZHOU by sending task establishment request for executing a task in response to service request from user. One would be motivated to do so in order to execute task based on user requesting service ( Ruggiero [ col 1 line 5-30 ] ). Claims 9 and 19 are rejected under 35 U.S.C. 103 a s being unpatentable over ZHOU et al (hereinafter ZHOU) (US 20190004868) in view of Ruggiero et al (hereinafter Ruggiero) (US 8769537). Regarding claim 9 and 19 the combination of ZHOU and Ruggiero teaches all the limitations of claims 7 and 17, the combination fails to explicitly teach after the initializing, by the verification management center, a task state of the verification task, further comprising: upon determining that that the service verification result is not received after a timeout time threshold is reached, updating, by the verification management center, the task state to a failure , however Nickel from analogous art teaches after the initializing, by the verification management center, a task state of the verification task, further comprising: upon determining that that the service verification result is not received after a timeout time threshold is reached, updating, by the verification management center, the task state to a failure (Nickel on [0070] teaches a slave failure may be indicated if master computer 102 sends a message to a particular slave computer but receives no response within some pre-determined interval of time. In another situation, master computer 102 may detect a slave failure if it does not receive periodic performance statistics or computational results within a pre-determined interval of time) . T hus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Nickel into the combined teaching of ZHOU and Ruggiero by d etermining that that the service verification result is not received after a timeout time threshold and updating the task state to a failure . One would be motivated to do so in order to detect task failure ( Nickel [ 0070 ] ). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. WANG (US 20230222075) is directed towards method for searching for an interrupted device including connecting the slave devices to a master device through a connection device, where the connection device includes at least two ports; receiving, by the slave devices, task process information sent by the master device, where the task process information includes: task process information recorded by the master device and the corresponding slave devices when executing tasks; and in response to interruption of receiving task process information sent by the master device, finding an interrupted slave device according to the interrupted task process information. Morris (US 20180136979) is directed towards operating environments that make efficient use of resources by assigning a task, included in work to be performed as tasks, to an environment capable of performing the task. The assigning is based on a resource utilized in performing tasks. Any inquiry concerning this communication or earlier communications from the examiner should be directed to FILLIN "Examiner name" \* MERGEFORMAT MOEEN KHAN whose telephone number is FILLIN "Phone number" \* MERGEFORMAT (571)272-3522 . The examiner can normally be reached FILLIN "Work Schedule?" \* MERGEFORMAT 7AM-5PM EST M-TH Alternate Fridays . 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, FILLIN "SPE Name?" \* MERGEFORMAT Shewaye Gelagay can be reached at FILLIN "SPE Phone?" \* MERGEFORMAT (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. /MOEEN KHAN/ Primary Examiner, Art Unit 2436