CTFR 18/946,048 CTFR 95331 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. DETAILED ACTION Response to Amendment In the amendment dated 05/05/2026, the following occurred: Claims 1, 8 and 15 have been amended; and claims 7, 14 and 20 have been cancelled. Claims 1-6, 8-13 and 15-19 are pending and have been examined. Priority Acknowledgement is made of applicant’s claim to priority under 35 U.S.C. 120, 121, 365(c), or 386(c) and 37 CFR 1.78 for a continuing application, which claims priority to U.S. Application No. 16/918,876 filed 07/01/2020 (Patent No. 12170143), which claims priority to U.S. Provisional Patent Application No. 62/870,528 dated 07/03/2019. Information Disclosure Statement The Information Disclosure Statement(s) (IDS)(s) submitted on 05/05/2026 follow(s) the provisions of 37 CFR 1.97 and has/have been fully considered by the Examiner. 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 obviousness-type 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); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this 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 §§ 706.02(1)(1) -706.02(1)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-l.jsp. Claims 1-6, 8-13 and 15-19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-5, 7-12, 14-19 and 21-22 of prior U.S. Patent No. 12,170,143. Although the claims at issue are not identical, they are not patentably distinct from each other as set forth below . Claims 1, 8 and 15 recite substantially similar limitations to claims 1, 8 and 15 of the Patented parent case. The subject matter in the instant application amounts to claims which are generally similar in scope. The limitations in the instant application are addressed in different writing styles. For example, the instant claim 1 limitation of “determine a need of the user based upon the one or more pattern disruptions, the need (i) determined to address the detected one or more pattern disruptions, and (ii) addressable by one or more caregivers associated with the user” is similar in scope to the parent claim 1 limitation of “determine a need based upon the one or more disruptions of the one or more patterns of behavior of the user; in response to determining the need of the user, identify one or more caregivers to address the determined need of the user. Although the claims at issue not identical, the language of the limitations is functionally equivalent, such that the claims are patentably indistinct. Dependent claims 2-6, 9-13 and 16-19 recite similar limitations to claims 1-5, 7-12, 14-19 and 21-22 of the Patent and are also rejected as being obvious variations of the claims of the Patent. Subject Matter Eligibility - 35 USC § 101 The limitations of canceled claims 7, 14, and 20 are now incorporated into the independent claims 1, 8 and 15. Claims 1, 8 and 15 as amended recite “generate a smart contract for the generated arrangements with the determined third-party service provider; and store the smart contract in a blockchain ledger associated with the user, wherein processing for a hash for the blockchain ledger is distributed over multiple computer devices” (claim 1 being representative). The limitations provide a practical application under subject eligibility analysis step 2A prong 2, since it provides an improvement to the functioning of a computer or to any other technology or technological field (i.e., it provides a technical solution to a technical problem). MPEP § 2106.05(a). The Specification discloses the technical problem and provides the sufficient level of detail of the recited technical solution, as follows: “[0042] … As the blockchain grows, the processing power needed to calculate the hash of the previous blocks grows as well. In these embodiments, the processing of the hash may be distributed over multiple computer devices to improve the speed of processing and/or to not overburden the hashing processor.” The subject matter eligibility of independent claims 1, 8 and 15 also applies to their dependent claims 2-6, 9-13 and 16-19 . 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-23-aia AIA The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21-aia AIA Claims 1-6, 8-13 and 15-19 are r ejected under 35 U.S.C. § 103 as being unpatentable over R ufo et al. (US 2018/0342329 A1; “Rufo” herein) in view of Oduor et al. (US 2018/0060970 A1; “Oduor” herein), Wang (US 2019/0122760 A1), and Tovey et al. (US 2019/0325502 A1; “Tovey” herein). R e. Claim 1, Rufo teaches a computer system for matching consumers to providers (Fig. 4 teaches an overarching system) , the computer system comprising at least one processor (HAPPIE home unit 103 system core 121) in communication with at least one memory device (local database 108) and one or more sensors associated with a vehicle of a user (sensors 177, 144, 112-113) ([0122] teaches an automobile sensor 177 connected to the HAPPIE system core 121 is provided in the garage to detect the presence of an automobile or other vehicle… An automobile interface 155, connected to the HAPPIE system core 121, is preferably provided for data communication with the resident's automobile or other vehicle.) , the at least one processor configured to: generate […] historical vehicle telematics data collected by the one or more sensors […] ([0146] teaches the automobile interface 155 is provided to receive data from the automobile sensor (current vehicle telematics data), e.g., a wireless device… The HAPPIE home unit 103 is able to maintain the automobile’s trip log, parked location, and records concerning engine diagnostics using the automobile interface 155 (historical vehicle telematics data)… The wireless device… may communicate the automobile’s location and/or when the automobile is parked to the HAPPIE home unit 103. See also [0280].) ; […] detect one or more pattern disruptions […] of behavior of the user ([0120] teaches data from the motion sensors is used to determine patterns of movement by the resident… When the resident deviates significantly from his or her established patterns of movement (detecting pattern disruptions), the HAPPIE home unit 103 makes an intelligent determination of whether a response may be warranted, e.g., in the case of significant inactivity, the HAPPIE home unit 103 may trigger an alert to the caregiver portal 101 requesting investigation.) ; determine a need of the user based upon the one or more pattern disruptions, the need determined to address the detected one or more pattern disruptions, and (ii) addressable by one or more caregivers associated with the user ([0120] teaches making an intelligent determination of whether a response, e.g., an alert requesting an investigation, may be warranted (determine a need) when patterns of movement deviate significantly from established patterns (to address the detected pattern disruptions). [0120], [0191], [0255] teach triggering and sending the alert to the caregiver portal 101, then relaying the alert to a caregiver device 178-180. [0256], [0260]-[0261] teach the alerts provide actionable (addressable) information to tell the caregiver of something requiring attention or action and are linked to behavior that needs to be taken (the determined need).) ; […]; automatically generate arrangements with the determined third-party service provider ([0146], [0280] teach the HAPPIE home unit 103 uses the received data in order to automatically schedule automobile service and maintenance (generate arrangements), determine whether the resident is at home, track trips.) ; […] for the generated arrangements with the determined third-party service provider (see previous citations) ; and […], wherein processing of […] is distributed over multiple computer devices (Rufo at Abstract teaches the home automation system has a distributed computational architecture providing a CPU associated with each video camera, processing being performed by each such CPU.) . Rufo may not teach generate a plurality of driving patterns of behavior of the user from historical vehicle telematics data collected by the one or more sensors including a good driving pattern for the user; or in response to receiving current vehicle telematics data associated with the user, detect one or more pattern disruptions of the plurality of driving patterns of behavior of the user. Oduor teaches generate a plurality of driving patterns of behavior of the user from historical vehicle telematics data collected by the one or more sensors including a good driving pattern for the user (Fig. 1, [0065]-[0066] teach sensor data is recorded by in-vehicle sensor 110… the sensor data is labeled with context variables from context data source 120—e.g., metadata… the sensor data is processed by a maneuver detection system 200 in order to detect maneuvers / driver behavior and metadata from the raw sensor data (vehicle telematics data). [0009] teaches retrieving from the driver maneuver database relevant historical driver maneuver data (necessarily generated), the relevant historical driver maneuver data comprising tagged historical metadata. [0009] also teaches an aggregate subject driver score that is updated after a single incident is scored according to relevant historical driver maneuver data, as discussed below. The Examiner interprets the historical driver maneuver data as having good and bad driver behaviors that previously affected the aggregated subject driver score.) ; and in response to receiving current vehicle telematics data associated with the user, detecting one or more patterns… of the plurality of driving patterns of behavior of the user (Fig. 1, [0065]-[0066] teach the sensor data is processed by a maneuver detection system 200 in order to detect maneuvers / driver behavior and metadata from the raw sensor data (current vehicle telematics data). [0009] teaches recording, by an in-vehicle sensor, a subject driver maneuver data and tagging the subject driver maneuver data with subject metadata (detecting a current driving pattern in response); and calculating a single-incident driver score by scaling the subject driver maneuver data according to the relevant historical driver maneuver data and tagged historical metadata (detect a driving pattern of the plurality of driving patterns).) Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to have modified the HAPPIE home automation system of Rufo to acquire, process, record, analyze and manipulate in-vehicle sensor data and to use this information as part of a system and method for context-based driver monitoring as taught by Oduor, with the motivation of improving driver monitoring and driver behavior (e.g., rewarding good driving behavior) (see Oduor at Abstract and para. 0007, 0053). Rufo/Oduor may not teach in response to determining that none of the one or more caregivers is available to address the determined need of the user, determine a third-party service provider that is able to meet the determined need for the user; or transmit the generated arrangements to a computer device associated with the determined third-party service provider. Wang teaches in response to determining that none of the one or more caregivers is available to address the determined need of the user, determine a third-party service provider that is able to meet the determined need for the user (Fig. 6 at steps 640-650 teaches identifying caregiver availability prior to assigning caregivers. See also [0061], time limitations. Fig. 7A teaches determining no favorite caregiver is available and assignable, e.g., step 716=No. Fig. 7A teaches subsequently determining a preferred caregiver is available and assignable, e.g., step 732=Yes.) ; automatically generate arrangements with the determined third-party service provider (Fig. 7A at step 736 teaches assigning the preferred caregiver to service request ‘X’; Fig. 6A at step 670 teaches sending the pre-scheduled assignments to caregivers for approval. Fig. 4A & [0131] teaches sending the service request to the preferred caregiver, who accepts the request; and scheduling the caregiver.) ; and transmit the generated arrangements to a computer device associated with the determined third-party service provider (Fig. 4A & [0131] teach scheduling the caregiver; and Fig. 1, [0028], [0074] teach transmitting, by the server to a computing device of the preferred caregiver, a dispatch notification which includes one or more assigned service requests.) Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to have modified the HAPPIE home automation system of Rufo/Oduor to assign and schedule an available caregiver and to use this information as part of a method and system for customized scheduling of home health care services as taught by Wang, with the motivation of improving care systems by streamlining processes, increasing caregiver utilization, improving efficiency over standard practices of dispatching randomly for prescheduled services, and limiting manual dispatching/scheduling (see Wang at para. 0007, 0127 and 0143). Rufo/Oduor/Wang may not teach generate a smart contract ; store the smart contract in a blockchain ledger associated with the user ; or a hash for the blockchain ledger. Tovey teaches generate a smart contract (Fig. 5 & [0054] teach a blockchain may be used to secure digital documents, e.g., digital representation of a contractual relationship (necessarily generated).) ; store the smart contract in a blockchain ledger associated with the user (see Fig. 5, e.g., “Owner 1”. [0041] teaches the rules in a blockchain may comprise clauses of a smart contract (necessarily stored) that is enforced by a peer-to-peer network. See also Fig. 9.) ; and a hash for the blockchain ledger (see Fig. 5 & [0037], teaching “hash”. [0054] teaches the blockchain may include peer-to-peer network timestamped (processed) records of actions, which are activities through which the digital content is used by hashing them (the records) into an ongoing chain of hash-based proof-of-work to form a record that cannot be changed in accord with that timestamp without redoing the proof-of-work.) Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date to have modified the HAPPIE home automation system of Rufo/Oduor/Wang to generate and store hashed digital documents in a blockchain and to use this information as part of systems and methods for automatically ordering a product item via a wearable technology as taught by Tovey, with the motivation of improving the delivery of an urgent need as well as improving the security of a system (see Tovey at Abstract and para. 0037). Re. Claim 2, Rufo/Oduor/Wang/Tovey teaches computer system of claim 1, wherein the at least one processor is further configured to: receive registration data from the user (Rufo Fig. 42, [0102], [0418] teaches storing information about a senior user and caregiver, necessarily received. Rufo [0175] for storing names and contact information for caregivers. Oduor [0018] teaches storing the subject driver maneuver data in the memory along with relationship data that links the subject driver maneuver data to a vehicle identifier (also registration data).) ; and generate the plurality of driving patterns of behavior of the user by analyzing the registration data (Rufo [0160], [0238], [0280]-[0283], [0260] teaches the system uses artificial intelligence to model patterns of the user based on the received types of information (necessarily analyzed). See also Oduor Fig. 1, [0009], [0065]-[0066] (generating driving patterns).) Re. Claim 3, Rufo/Oduor/Wang/Tovey teaches the computer system of claim 1, wherein the at least one processor is further configured to continuously receive user data from the one or more sensors (Rufo Fig. 3, [0107]-[0109], [0120], [0127], [0160] teaches the system monitors (continuously receives) data from a variety of different sensors. Rufo [0122] teaches a vehicle sensor 177 and an automobile interface 155 connected to the HAPPIE system core 121 for data communication with, and to obtain diagnostic and service information from, the resident’s automobile. Oduor Fig. 1 [0018], [0065]-[0066] also teaches an in-vehicle sensor.) , wherein the user data includes the historical vehicle telematics data, and wherein the historical vehicle telematics data includes movement data (Oduor Fig. 1, [0065]-[0066] teaches the sensor data is processed by a maneuver detection system 200 in order to detect maneuvers / driver behavior and metadata from the raw sensor data (historical vehicle telematics data). Oduor [0009] teaches retrieving from the driver maneuver database relevant historical driver maneuver data, the relevant historical driver maneuver data comprising tagged historical metadata. Oduor [0043], [0065] teaches the sensor data may include GPS coordinates and telekinetic data; and subject driver maneuver data is data for a vehicle's actions as it maneuvers in response to a road hazard (movement data).) Re. Claim 4, Rufo/Oduor/Wang/Tovey teaches computer system of claim 1, wherein the one or more pattern disruptions include a negative driving pattern for the user (see claim 1 prior art rejection. Oduor [0009], [0043], [0054] teaches the subject driver maneuver data is data for a vehicle's actions as it maneuvers in response to a road hazard, e.g., harsh breaks, swerving, sharp turns, acceleration, etc. The Examiner interprets, for a single-incident, the in-vehicle sensor records a series of particularly bad responses to a road hazard that ultimately affect the single-incident score and the aggregate score.) Re. Claim 5, Rufo/Oduor/Wang/Tovey teaches computer system of claim 1, wherein the at least one processor is further configured to: receive schedule information from the one or more caregivers (Wang Fig. 6 steps 640-650 teaches identifying caregiver availability prior to assigning caregivers. Wang [0061] teaches personal limitations regarding when a caregiver provides services, e.g., time limitations (schedule information) based on a caregiver’s reluctance to provide one or more services within certain time periods… caregivers can set limitations for time and day of week / month / year (necessarily received).) ; and determine availability of the one or more caregivers based on the received schedule information (Wang Fig. 6 steps 640-650 teaches identifying caregiver availability prior to assigning caregivers. Wang Fig. 7A teaches determining whether a favorite caregiver is available and assignable to a service request, e.g., Yes at step 716 . See also Wang [0051], “Services”.) Re. Claim 6, Rufo/Oduor/Wang/Tovey teaches computer system of claim 1, wherein the at least one processor is further configured to identify the one or more caregivers to address the determined need of the user (see claim 1 prior art rejection. Rufo [0120], [0191], [0255] teach triggering and sending the alert to the caregiver portal 101, then relaying the alert to a caregiver device 178-180 (necessarily identifying). [0256], [0260]-[0261] teach the alerts provide actionable information to tell the caregiver of something requiring attention or action and are linked to behavior that needs to be taken (the determined need). The Examiner notes that “to address…” is an intended result of “identifying…”, which is not required for the claim to be met.) Re. Claims 8 & 15 , the subject matter of claims 8 and 15 are essentially defined in terms of a process and a manufacture, which are technically corresponding to system claim 1. Since claims 8 and 15 are analogous to claim 1, they are similarly analyzed and rejected in a manner consistent with the rejection of claim 1. Further, Rufo, Wang, and Oduor each teach at least one non-transitory computer-readable media (see Rufo Fig. 4, [0461]; Wang [0071], [0092], [0097]; Oduor [0027], [0069].) Re. Claims 9 & 16, the subject matter of claims 9 and 16 are essentially defined in terms of a process and a manufacture, which are technically corresponding to system claim 2. Since claims 9 and 16 are analogous to claim 2, they are similarly analyzed and rejected in a manner consistent with the rejection of claim 2. Re. Claims 10 & 17, the subject matter of claims 10 and 17 are essentially defined in terms of a process and a manufacture, which are technically corresponding to system claim 3. Since claims 10 and 17 are analogous to claim 3, they are similarly analyzed and rejected in a manner consistent with the rejection of claim 3. Re. Claim 11, the subject matter of claim 11 is essentially defined in terms of a process, which are technically corresponding to system claim 4. Since claim 11 is analogous to claim 4, it is similarly analyzed and rejected in a manner consistent with the rejection of claim 4. Re. Claims 12 & 18, the subject matter of claims 12 and 18 are essentially defined in terms of a process and a manufacture, which are technically corresponding to system claim 5. Since claims 12 and 18 are analogous to claim 5, they are similarly analyzed and rejected in a manner consistent with the rejection of claim 5. Re. Claims 13 & 19, the subject matter of claims 13 and 19 are essentially defined in terms of a process and a manufacture, which are technically corresponding to system claim 6. Since claims 13 and 19 are analogous to claim 6, they are similarly analyzed and rejected in a manner consistent with the rejection of claim 6 . Response to Arguments Double Patenting The double patenting rejection of the claim set is respectfully maintained. Rejection under 35 U.S.C. §103 Regarding the rejection of Claims 1-20, the Applicant has cancelled Claims 7, 14 and 20, rendering the rejection of those claims moot. Regarding the remaining claims 1-6, 8-13 and 15-19, the Examiner has considered the Applicant’s arguments but does not find them persuasive for at least the following reasons: Re. “Applicant respectfully submits that no combination of Rufo, Oduor, Wang, and Tovey describes or suggests the computer system of Claim 1. More specifically, no combination of Rufo, Oduor, Wang, and Tovey describes or suggests…” (Remarks, pg. 10): The Examiner respectfully disagrees and submits the basis of rejection as necessitated by amendment. Given the broadest reasonable interpretation in light of the specification, Rufo teaches or renders obvious the claims as drafted. For example, Rufo at para. 0120 teaches making an intelligent determination of whether a response, e.g., an alert requesting an investigation, may be warranted when patterns of movement deviate significantly from established patterns (“determine a need of the user based upon the one or more pattern disruptions”) to address the detected pattern disruptions. Determining that a caregiver’s investigation is needed determines a need that will address the detected pattern disruptions. Rufo at para. 0120, 0191, 0255 teaches triggering and sending the alert to the caregiver portal 101, then relaying the alert to a caregiver device 178-180. Rufo at para. 0256, 0260-0261 teaches the alerts provide actionable information to tell the caregiver of something requiring attention or action (“addressable by one or more caregivers associated with the user”) and are linked to behavior that needs to be taken. Re. “the Examiner relies on Wang for allegedly describing these features” (Remarks, pg. 10): The Examiner respectfully submits the basis of rejection as necessitated by amendment. Given the BRI in light of the specification, Wang renders obvious the limitations shown in the basis of rejection (i.e., Wang maps to “in response to determining that none of the one or more caregivers is available to address the determined need of the user, determine a third-party service provider that is able to meet the determined need for the user” and “transmit the generated arrangements to a computer device associated with the determined third-party service provider” as required). Regarding the rejection of claims 2-6, 8-13 and 15-19, the Applicant has not offered any or any additional arguments with respect to these claims other than to reiterate the argument(s) present for the claim(s) from which they depend or are analogous to. As such, the rejection of these claims is also respectfully maintained. Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure : Olsen et al. (US 2020/0074382 A1) for teaching optimization of patient care team based on correlation of patient characteristics and care provider characteristics (see Abstract). THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jessica M Webb whose telephone number is (469)295-9173. The examiner can normally be reached Mon-Thurs 9:30am-3:30pm CST. 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, Robert Morgan can be reached on (571) 272-6773. 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. /J.M.W./Examiner, Art Unit 3683 /CHRISTOPHER L GILLIGAN/Primary Examiner, Art Unit 3683 Application/Control Number: 18/946,048 Page 2 Art Unit: 3683 Application/Control Number: 18/946,048 Page 3 Art Unit: 3683 Application/Control Number: 18/946,048 Page 4 Art Unit: 3683 Application/Control Number: 18/946,048 Page 5 Art Unit: 3683 Application/Control Number: 18/946,048 Page 6 Art Unit: 3683 Application/Control Number: 18/946,048 Page 7 Art Unit: 3683 Application/Control Number: 18/946,048 Page 8 Art Unit: 3683 Application/Control Number: 18/946,048 Page 9 Art Unit: 3683 Application/Control Number: 18/946,048 Page 10 Art Unit: 3683 Application/Control Number: 18/946,048 Page 11 Art Unit: 3683 Application/Control Number: 18/946,048 Page 12 Art Unit: 3683 Application/Control Number: 18/946,048 Page 13 Art Unit: 3683 Application/Control Number: 18/946,048 Page 14 Art Unit: 3683 Application/Control Number: 18/946,048 Page 17 Art Unit: 3683 Application/Control Number: 18/946,048 Page 18 Art Unit: 3683 Application/Control Number: 18/946,048 Page 19 Art Unit: 3683
Prosecution Insights