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 .
DETAILED ACTION
Status of Claims
Claims 1-20 filed 11/13/2024 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 12/05/2024, 02/24/2025, 03/11/2025, 04/10/2025, 05/14/2025, 07/18/2025, 09/26/2025 and 10/14/2025 follow(s) the provisions of 37 CFR 1.97 and has/have been fully considered by the Examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory 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-20 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 (and broader) 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 or broader in scope. The limitations in the instant application are addressed in different writing styles, which also makes the claims at issue not identical; however, the language of the limitations is functionally equivalent, such that the claims are similar/patentably indistinct.
Dependent claims 2-7, 9-14 and 16-20 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.
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-20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1, 8 and 15 are rejected under 35 U.S.C. §101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 (YES)
Claims 1, 8 and 15 fall into at least one of the statutory categories (i.e., machine, process, or manufacture).
Step 2A1 (YES)
The limitations of 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; 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; determine a need of the user based upon the one or more pattern disruptions, the determined need addressable by one or more caregivers associated with the user; 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; automatically generate arrangements with the determined third-party service provider; and transmit the generated arrangements to the determined third-party service provider, as drafted, is a process that under the broadest reasonable interpretation (BRI) covers a method of organizing human activity (i.e., managing personal behavior or relationships or interactions between people including following rules or instructions) but for the recitation of generic computer component language (discussed below in 2A2). That is, other than reciting the generic computer component language, the claimed invention amounts to managing personal behavior or relationships or interactions between people. For example, but for the generic computer component language, the claims encompass a person generating, receiving, detecting, transmitting data and making determinations. The Examiner notes that certain “method[s] of organizing human activity” includes a person’s interaction with a computer (see MPEP § 2106.04(a)(2)(II)). If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or relationships or interactions between people but for the recitation of generic computer component language, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. See additionally MPEP § 2106. Accordingly, the claims recite an abstract idea.
Step 2A2 (NO)
The judicial exception, the above-identified abstract idea, is not integrated into a practical application. In particular, the claims recite the additional elements of a computer system comprising at least one processor and at least one memory device / non-transitory computer-readable medium that implement the identified abstract idea. The additional elements aforementioned are not described by the applicant and are recited at a high-level of generality (i.e., a generic computer or computer component performing a generic computer or computer component function that facilitates the identified abstract idea) such that these amount no more than mere instructions to apply the exception using a generic computer component (see Specification, e.g., at 0135-0136). See MPEP § 2106.04(d)(I). Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The claims further recite the additional elements of one or more sensors associated with a vehicle of a user and a computer device associated with the third-party service provider as collecting, transmitting or outputting data. The additional elements are recited at a high-level of generality (i.e., each as a general means of collecting, transmitting or outputting data) and each amounts to a location from which data is received or to which data is transmitted or outputted, each of which represents an extra-solution activity (e.g., mere data gathering and data output). MPEP § 2106.04(d)(I) indicates that extra-solution data gathering and data output activity cannot provide a practical application. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claims are directed to an abstract idea.
Step 2B (NO)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a computer system comprising at least one processor and at least one memory device / non-transitory computer-readable medium to perform the identified abstract idea amount no more than mere instructions to apply the exception using a generic computer or generic computer component. Mere instructions to apply an exception using generic computer(s) and/or generic computer component(s) cannot provide an inventive concept (“significantly more”). See MPEP § 2106.05(f).
Also discussed above with respect to integration of the abstract idea into a practical application, the additional elements of one or more sensors associated with a vehicle of a user and a computer device associated with the third-party service provider (i.e., each a device that collects, transmits or outputs data) are each considered extra-solution activity. This has been re-evaluated under the “significantly more” analysis and determined to be well-understood, routine, conventional activity in the field. MPEP 2106.05(d)(II) indicates that receiving, transmitting or outputting data over a network has been held by the courts to be well-understood, routine, conventional activity (citing TLI Communications, Symantec, OIP Techs., and buySAFE). See also MPEP 2106.05(g) (citing Cybersource, Mayo, OIP Techs.) Well-understood, routine, conventional activity cannot provide an inventive concept (“significantly more”). As such, the claims are not patent eligible.
Dependent claims 2-6, 9-13 and 16-19, when analyzed as a whole, are similarly rejected under 35 U.S.C. §101 because the additional limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea without significantly more. The claims, when considered alone or as an ordered combination, either (1) merely further define the abstract idea, (2) do not further limit the claim to a practical application, or (3) do not provide an inventive concept such that the claims are subject matter eligible.
Claim(s) 4, 9, 11-13 merely further describe(s) the abstract idea (e.g. receiving, analyzing, generating data; the pattern disruption(s); making a determination based on received information; identifying data). See analysis, supra.
Claim(s) 2-3, 5-6, 10, 16-19 merely further describe(s) the additional element(s) of the processor (e.g., receiving or continuously receiving data, generating data, analyzing data, making a determination based on received information, identifying data) and the sensor(s) (e.g., general mean(s) for transmitting data). See analysis, supra.
Note: 35 USC § 101
Re. Claims 7, 14, and 20, the claims 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 7 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.”
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.
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.
Claims 1-6, 8-13 and 15-19 are rejected under 35 U.S.C. § 103 as being unpatentable over Rufo et al. (US 2018/0342329 A1; “Rufo” herein) in view of Oduor et al. (US 2018/0060970 A1; “Oduor” herein) and Wang (US 2019/0122760 A1).
Re. 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 determined need addressable by one or more caregivers associated with the user ([0120] teach 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. [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 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.); and
[…].
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).
Re. Claim 2, Rufo/Oduor/Wang 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 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 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 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 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.
Claims 7, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Rufo in view of Oduor, Wang and Tovey et al. (US 2019/0325502 A1; “Tovey” herein).
Re. Claim 7, Rufo/Oduor/Wang teaches computer system of claim 1, wherein the at least one processor is further configured to: […] for the generated arrangements with the determined third-party service provider (see claim 1 prior art rejection); and […], wherein processing for […] 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/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.); or
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. Claims 14 and 20, the subject matter of claims 14 and 20 are essentially defined in terms of a process and a manufacture, each of which is technically corresponding to system claim 7. Since claims 14 and 20 are analogous to claim 7, they are similarly analyzed and rejected in a manner consistent with the rejection of claim 7.
Conclusion
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).
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-Fri 9:00am-1:00pm 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