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
Continuation
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/29/2025 has been entered.
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 therefore, subject to the conditions and requirements of this title.
1. Claims 1 – 6, 8 – 15, 21 – 22 and 24 – 27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
The independent claims are directed toward the abstract idea in the form of managing a reservation status (temporary vs. regular) based on the provision of verification data (healthcare information) – that is a method of organizing human activity.
The Examiner further asserts Applicant does not have other limitations in the claim that integrate that abstract idea into a practical application that improves computer functionality or other technology. The claims recite only well-understood, routine, conventional computer components and activities for implementing that workflow – accordingly, the claim is not statutory. The Examiner’s analysis for representative claim 1 is as follows. A similar analysis is applied to claim 12.
PNG
media_image1.png
538
914
media_image1.png
Greyscale
(Pertaining to claim 1) One or more storage media storing instructions which, when executed by one or more processors of a client device, cause:
locking a location reservation function in an application that executes on the client device;
prior to unlocking the location reservation function, in response to receiving user input that selects the location reservation function, transmitting, over a computer network, a location reservation request that has a status of a temporary request;
after transmitting the location reservation request, receiving confirmation data that indicates that a user of the client device has a temporary reservation for a first location and that includes an invitation to provide healthcare information of the user in order to convert the temporary reservation into a regular reservation;
based on receiving the healthcare information at the client device, unlocking the location reservation function and causing the healthcare information to be transmitted over a second computer network, which causes the temporary reservation to be converted into the regular reservation.
What is claimed?
Claim 1 is directed to managing a reservation status (temporary vs. regular) for access to a location based on provision and verification of healthcare information, implemented via a client device and computer networks
STEP 1: YES.
STEP 2A Prong One: YES, the abstract idea are limitations (ii) – (iv).
These steps fall within two recognized groupings of abstract ideas identified in MPEP § 2106.04(a)(2):
Certain methods of organizing human activity – specifically:
Limitation (i) implements a business rule that restricts user access to the reservation function until a condition is satisfied (healthcare information is provided). This restriction reflects a commercial or access-control decision about who is authorized to perform an action and when.
Limitation (iii) and (iv) implement a conditional approval workflow: the temporary reservation is eligible for conversion to regular status only if the user provides healthcare information. This is a commercial or legal interaction and method of managing personal behavior (requiring verification before granting access), which is expressly identified in MPEP § 2106.04(a)(2) as an abstract idea.
Presentation and organization of information / mental processes – specifically:
Limitations (iii) and (iv) implement the logic of:
Observation – receiving the healthcare information from the user
Evaluation – assessing whether the healthcare information satisfies the requirement for conversion (implicit in the conditional “based on receiving”).
Judgement and action – deciding to unlock the function and transmit the healthcare information to effect the conversion.
These steps (observation, evaluation, judgement) are the hallmarks of a mental process and fall within the grouping expressly identified in MPEP § 2106.04(a)(2). These limitations, taken together, describe the reservation/approval policy itself, independent of any particular computer implementation. A human gatekeeper could perform this same workflow with pen, paper and a telephone: receive a reservation request, inform the user it is provisional and healthcare verification is needed, wait for the user to provide healthcare information, verify receipt, and covert the status.
STEP 2A Prong Two: No
In claim 1, the additional elements beyond the abstract reservation/access-control workflow are:
A "location reservation function in an application that executes on the client device” (from i);
“in response to user input selecting the location reservation function” (from ii);
Transmission and reception of data over a first and second computer network (from ii, iii and iv); and
The generic "locking" and "unlocking" of a location reservation function as a result of updating the reservation status (from i and iv).
The claims do not recite any particularized improvement to the functioning of a computer, network, or other technology. For example:
No improvement to internal computer architecture or operation – the client device simply receives instructions to lock a function, transmit data, receive data, and unlock a function – standard operations of any networked computing device.
No improvement to network protocols or communication – the claim merely describes transmitting data over a computer network at a high level of generality without specifying any technical improvement to network operation, routing, bandwidth efficiency, latency reduction or security.
Generic lock/unlock mechanism – the “locking” and “unlocking” of the reservation function is described functionally. The function is unavailable until a condition is met without specifying any novel technical mechanism - the lock/unlock is merely the software enforcement of the business rule.
No novel data structure or transformation – the claim does not recite a particular data structure, encoding scheme, or algorithm for storing, transforming, or processing reservation or healthcare data. Data is simply transmitted, received, and converted using generic operations.
When considered as a whole, the claim thus uses generic computer components as tools to automate the abstract reservation and approval workflow, without imposing any meaningful limit on the judicial exception or integrating it into a technological improvement.
The only “transformation” recited is unlocking a software function (from i and iv) and converting a reservation status from temporary to regular (from iv). These are changes in abstract business states, not transformations of a particular article or dataset in a technical sense. A change in business status does not constitute the kind of transformation completed in cases like Diamond v. Chakrabarty or State Street Bank.
The additional elements do not integrate the judicial exception into a practical application.
Accordingly, under Step 2A, Prong Two, claim 1 remains directed to the abstract idea identified above.
STEP 2B: NO
2B.1 Additional Elements Identified
Beyond the abstract idea discussed above, claim 1 recites the following additional elements:
(i) “location reservation function” implemented in an “application” executing on the client device
(ii) “in response to user input selecting the location reservation function”; transmission “over a computer network”
(iii) reception “over a computer network”
(iv) the use of a “second computer network” for transmission of healthcare information; the triggering of the conversion based on reception of healthcare information
2B.2 Well-Understood, Routine, Conventional Activity
The computer-related elements recited above are well-understood, routine, and conventional activities for networked computer systems for reservations, access control, and data transmission. Courts and the MPEP consistently recognize these as routine computer functions that, when claimed at a high level of generality, do not supply an inventive concept.
The "locking" and "unlocking" of a reservation function, and the assignment of "temporary" vs. "regular" reservation statuses based on additional information, likewise reflect conventional reservation and access-control practices in computerized systems. Similar mechanisms for temporary reservations, approval-pending status, and status changes upon receipt of required information (e.g., payment, identification, or other credentials) are widely used in reservation, ticketing, and access-control software, as evidenced by existing reservation and access-control patents and systems.
These elements, whether viewed individually or in combination, merely implement the abstract reservation and credential-verification workflow on generic computing infrastructure, in a manner that is consistent with well-understood, routine, conventional usage in the field. The ordered combination of these steps adds nothing that is not already present in the abstract idea itself. The sequence (1) hold reservation, (2) request information, (3) receive information, (4) grant access – the conventional sequence of the business practice, not a non-conventional arrangement of computer technology. Merely claiming the manipulation of data in a logical order to achieve a business result does not amount to an inventive concept.
2B.3 No Improvement to Computer Functioning or Other Technology
The claims do not:
Change how a computer, client device, or network operates at a technical level (for example, by introducing a new memory architecture, network protocol, or scheduler), unlike claims in Enfish, McRO, or Bascom that were found to improve computer functionality.
Provide a particular technical solution to a computer-centric security problem (e.g., software license tampering, low-level BIOS modifications), unlike cases finding eligibility for specific technical improvements in software security.
Instead, the claims merely implement a business-level policy (conditional location reservation based on healthcare information) using routine computer components.
2B.4 Absence of Other Meaningful Limitations
The claim does not recite:
Any specific algorithm for determining which healthcare information is required or how it is evaluated;
Any particular data structure, encoding, or transformation of the healthcare or reservation information beyond generic storage and transmission; or
Any non-conventional arrangement of computer components.
As such, the additional elements are no more than insignificant extra-solution activity and mere instructions to apply the abstract idea using conventional computer technology, which do not provide an inventive concept under Step 2B.
Conclusion:
Accordingly, claim 1 does not include an inventive concept that is sufficient to transform the abstract idea into a patent-eligible application. The same reasoning applies to independent claim 12 and the remaining claims, which recite similar limitations in different statutory forms.
The claim is not patent-eligible (Step 2B: NO) and should be rejected under 35 U.S.C. 101.
Any amendment to the claims should be commensurate with its corresponding disclosure.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1, 8, 4, 9, 11, 12, 14, 22 and 24 – 27 are rejected under 35 U.S.C. 103 as being unpatentable over Romeo (US Pub. No. 2023/0138516 A1) in view of Furukawa (US Patent. No. 6079863).
Per claim 1, Romeo (US Pub. No. 2023/0138516 A1) suggests one or more storage media storing instructions which, when executed by one or more processors, cause: locking (reads on the schedule may be locked or flagged, see Romeo para 0067) a location reservation function (reads on the schedule for the healthcare facility, see Romeo para 0067) in an application (reads on the schedule appears on the physician’s application, see Romeo para 0067) that executes on the client device (reads on the front desk/user location/client computing device, see Romeo para 0050, 0060, 0066 – 0068); prior to unlocking (reads on until schedule approval, see Romeo para 0067) the location (reads on facilities/rooms in the healthcare facility, see Romeo para 0004 and 0065) reservation function (reads on the appointment/scheduled appointment gatekeeping function, see Romeo para 0004, 0005, 0065 and 0067), in response to receiving user input (reads on the patient arrives and checks in, see Romeo para 0065 – 0066) that selects (reads on the schedule is displayed and the attendant opens entry, see Romeo para 0065 – 0066) the location (reads on facilities/rooms in the healthcare facility, see Romeo para 0004 and 0065) reservation function (reads on the appointment/scheduled appointment gatekeeping function, see Romeo para 0004, 0005, 0065 and 0067), transmitting (reads on uploading which obviously if not necessarily requires a network, see Romeo para 0066 and 0068), over a computer network (see Romeo para 0068), a location reservation request (reads on the patient checking in/appointment request itself, see Romeo para 0065 and 0067) that has a status of a temporary request (reads on it is marked as locked/flagged until approval by the front desk, see Romeo para 0067. The Examiner asserts “until approval” to be a temporary condition because once approved it is no longer locked – the status changes); after (reads on after the patient checks in, see Romeo Figure 5 blocks 189 – 193 and para 0065 – 0066. The Examiner asserts the aspects of the workflow starting at block 189 are the “after transmitting” actions) transmitting the location reservation request (reads on the patient checking in/appointment request itself, see Romeo para 0065 and 0067), receiving confirmation data (reads on information such as the exemplary paperwork needed to be prepared by the patient prior to the appointment, insurance information, an indication of the schedule being locked/flagged/temporary until approval, and other information, see Romeo para 0066 – 0067) that indicates that a user of the client device has a temporary reservation (reads on it is marked as locked/flagged until approval by the front desk, see Romeo para 0067. The Examiner asserts “until approval” to be a temporary condition because once approved it is no longer locked – the status changes) for a first location (reads on facilities/rooms in the healthcare facility, see Romeo para 0004 and 0065) and that includes an invitation (reads on the system asks patient to provide information, see Romeo para 0031 and 0066) to provide (reads on the obtained/required from the patient, see Romeo para 0066) healthcare information of the user (reads on information such as the exemplary paperwork needed to be prepared by the patient prior to the appointment, insurance information, and other information, see Romeo para 0066 – 0067) in order to convert the (reads on the healthcare information is requested in order to turn the temporary/pending appointment/reservation into an approved/regular appointment, see Romeo para 0067) temporary reservation (reads on it is marked as locked/flagged until approval by the front desk, see Romeo para 0067. The Examiner asserts “until approval” to be a temporary condition because once approved it is no longer locked – the status changes) into a regular reservation (reads on an approved/regular appointment, see Romeo para 0067); based on receiving (reads on when the information is completed the appointment is approved, see Romeo para 0067) the healthcare information (reads on information such as the exemplary paperwork needed to be prepared by the patient prior to the appointment, insurance information, and other information, see Romeo para 0066 – 0067) at the client device (reads on the front desk/user location/client computing device, see Romeo para 0050, 0060, 0066 – 0068), unlocking (reads on changing from unapproved/locked/flagged to approved, see Romeo para 0067. The Examiner asserts before the schedule is locked/flagged and when the information is completed the scheduled appointment is approved/unlocked which changes state from locked to approved) the location (reads on facilities/rooms in the healthcare facility, see Romeo para 0004 and 0065) reservation function (reads on the appointment/scheduled appointment gatekeeping function, see Romeo para 0004, 0005, 0065 and 0067) and causing (reads on the unlocking triggers transmission of the updated/additional information obtained from the patient during check-in to be uploaded to central data repository, see Romeo para 0067 – 0068 and Figure 5 blocks 193 – 195) the healthcare information (reads on information such as the exemplary paperwork needed to be prepared by the patient prior to the appointment, insurance information, and other information, see Romeo para 0066 – 0067) to be transmitted (reads on uploaded from source/client device to destination/central depository, see Romeo para 0068) over a second computer network (reads on the obvious if not necessary network of the central depository that requires data to be uploaded to, see Romeo para 0068), which causes (reads on the unlocking triggers transmission of the updated/additional information obtained from the patient during check-in to be uploaded to central data repository, see Romeo para 0067 – 0068 and Figure 5 blocks 193 – 195) the temporary reservation (reads on it is marked as locked/flagged until approval by the front desk, see Romeo para 0067. The Examiner asserts “until approval” to be a temporary condition because once approved it is no longer locked – the status changes) to be converted into the regular reservation (reads on an approved/regular appointment, see Romeo para 0067). The prior art of record is silent on explicitly stating unlocking.
[0004] The one or more applications can be configured to receive this information and use it in the management of the healthcare practice. For example, patient-scheduling information, patient billing information, and patient electronic health records can be retrieved from the respective storage locations and deliver to the applications in a form and format that usable by the applications. This information can be used to develop a patient schedule for the healthcare practice. The schedule can be built as a daily, weekly, or biweekly schedule, or can be built to a different timescale. The schedule can include an identification of appointment times and patients corresponding to each appointment time. Where multiple physicians or other practitioners are involved in the healthcare practice, the schedule can also indicate which physician or physicians are scheduled to see which of patients. Likewise, other resources needed for the schedule appointments can be identified for each appointment. For example, wherein appointment requires laboratory or other tests, those tests can be identified and associated with the appointment. Where special facilities, such as an operating room, for example, are required, those facilities can also be flagged and associated with a schedule appointment.
[0060] At operation 155, application 73 builds a schedule. The schedule can be a master schedule for the healthcare facility, individual schedules for healthcare facility resources (e.g. physicians, test equipment, treatment rooms, etc.) or both. Accordingly, the schedule can be built by an individual application 73 running on a particular client computing device, or it can be built by a centralized application (e.g., an application 73 running as part of workflow management 48). In some embodiments, the schedule can be a scheduled listing of patients to be seen at the healthcare facility and the schedule times of their appointments. The schedule can be generated so as to display on the client computing devices for review or approval by healthcare practitioners.
[0065] FIG. 5 is an operational flow diagram illustrating an example process performed by an application to facilitate patient check-in to the healthcare facility. At operation 185 a patient arrives at and checks in to the healthcare facility. For example, the patient may sign in at a front desk and provide the front desk attendant with his or her name or identification. As another example, a kiosk may be provided to allow self check-in. Application 73 provides the schedule to the front desk attendant at operation 186. For example, the schedule can be displayed on a display screen of a client computing device for the front desk. The attendant can consult the schedule to locate the patient checking in.
[0066] The reception-desk attendant can open the appropriate schedule entry to view additional patient information that may be pertinent to the check-in process. At operation 189 this information is presented to the attendant. This information can include, for example, information such as a paperwork that will need to be prepared by the patient prior to the appointment, insurance information that may be required from the patient, and other information. If additional information is required from the patient, this information can be requested of an obtained from the patient. The attendant can enter the updated information into the application. For example, the attendant can enter new or updated insurance information, and indication that appropriate copayments were made, and so on. This information is received by the application to update patient records. This is indicated by operation 191.
[0067] When the information is completed, at operation 193 the scheduled appointment is approved so the patient can be seen. In some embodiments, requiring approval of the appointment at one or more steps along the appointment process can serve as a gatekeeping function to manage patient flow. For example, the schedule may be locked or flagged for certain resource applications until approval at or prior gatekeeping step is given. As a further example, the schedule appearing on a physician's application may be marked with a flag, highlighted, or otherwise noted as being locked until approval by the front desk is provided. As yet a further example, the schedule appearing on a test operator's application may be locked until the physician has seen the patient and approved the patient's condition for the test.
[0068] Operation 195 any updated or additional information obtained from the patient during the check-in process can be stored locally by the client computing device, and uploaded to central data repository 71 to update the main record database. This upload to central data repository 71 can be done in real time or near real-time, or can be done in a batch mode at periodic (e.g. daily) Intervals.
PNG
media_image2.png
920
580
media_image2.png
Greyscale
Furukawa (US Patent. No. 6079863) is relied upon to teach prior to unlocking (reads on pending state to decide approval, see Furukawa col. 1 lines 25 – 29) the location reservation function (reads on making a request for reservation of facilities, see Furukawa claim 18 and col. 5 lines 40 – 53) in response to receiving user input that selects the location reservation function (reads on the user logs into the facility reservation system types in data/facility id which is at least an inherent user issuing a request for reservation command that is received by the system, see Furukawa Figures 4 and 6), transmitting (reads on transmits a registration request, see Furukawa col. 3 line 66 – col. 4 line 19), over a computer network (see Furukawa Figure 1 block 90), a location reservation request (reads on a request for reservation of facilities, see Furukawa claim 1, 3, 18 and col. 3 line 66 – col. 4 line 19) that has a status of a temporary request (reads on setting the request for reservation to 0/pending, see Furukawa claim 3 and col. 5 line 54 – col. 6 line 13).
[col. 1 lines 11 – 29]
A schedule control system for controlling facilities such as a board room, an automobile and a stadium by using an electronic computer is known. For the schedule control system, there are available a system in which on receipt of a request for facility reservation, if the request for reservation overlaps an already registered schedule the request for reservation is rejected, and a system in which the request for reservation which overlaps the already registered schedule is permitted such as the conventional technique disclosed in Japanese Patent Laid-Open Application No. 5-165835. In addition, there are available a system in which on receipt of a request for reservation, it is decided by an electronic computer without the need for any operation of the manager whether the reservation is registered or rejected, and a system in which a schedule, reservation of which has been requested, is once caused to be in a temporarily registered (pending) state to decide approval or non-approval (rejection) by operation of the system manager.
[col. 3 lines 54 – 65 ]
When a command for inquiring the reservation schedule from the input device 12 of client 1 has been inputted after the user log-in, the processor 10 transmits a request for inquiry of the reservation schedule to the server 3 through the network 90. The processor 30 of the server 3 refers to the reservation schedule data 33 and reservation forbidden schedule data 34 to fetch the reservation schedule and reservation forbidden schedule of a designated date, and sorts both according to start time to transmit to the client 1 through the network 90. The processor 10 displays the reservation schedule and reservation forbidden schedule received on the display 11.
[col. 3 line 66 – col. 4 line 19]
When a command and data for registering the reservation schedule are inputted from the input device 12 of the client 1, the processor 10 transmits a registration request of the reservation schedule to the server 3. If at the designated date and time span, forbidden reservation is not registered in the reservation forbidden schedule data 34, or it is not registered as an approved reservation in the reservation schedule data 33, temporary registration is performed in the reservation schedule data 33. When a command and data for approving the reservation schedule are inputted from the input device 22 of the client 2, the processor 20 transmits a request to update the reservation schedule to the server 3. The processor 30 fetches the reservation schedule on the designated date by referring to the reservation schedule data 33 to transmit it to the client 2. The processor 20 displays the reservation schedule data received on the display 21. When information of approval or non-approval of the schedule is inputted from the input device 22, the processor 20 transmits this information to the server 3. The processor 30 sets approval or non-approval to the schedule designated on the reservation schedule data 33.
[col. 4 line 63 – col. 5 line 10]
FIG. 4 is a flowchart illustrating a flow of processing by the processor 30 of the server 3 on receipt of a request for inquiry about the reservation schedule from client 1. First, the processor 30 receives a log-in request from the client 1, and checks the user ID entered by the user by referring to the user log-in data 31 (Step 41). If the user ID has been registered, the processor 30 receives a request to inquire of a reservation schedule with the date and facility ID designated from the client 1 (Step 42). Thereafter, the processor 30 checks whether or not the designated date is a date on the calendar (Step 43). For the date, a period consisting of plural, continuous dates may be designated. If the date is correct, the reservation schedule data 33 is retrieved according to the date 331 and the facility ID 335 to obtain the corresponding reservation schedule data (Step 44).
[col. 5 lines 40 – 53]
FIG. 6 is a flowchart illustrating a flow of processing by the processor 30 on receipt of a request for a reservation schedule from the client 1. After checking on the user ID at the request of log-in, the processor 30 receives a request for reservation of a schedule with the date, time span, facility ID and utilization object designated from the client 1 (Step 52) to check whether or not the specified date is a date on the calendar (Step 53). If the date is correct, the processor 30 retrieves the reservation forbidden schedule data 34 according to the date 341, day-of-week 342, start time 343, end time 344 and facility ID 345 (Step 54), and determines whether or not there is a reservation forbidden schedule on the specified date and time span for the facility ID designated (Step 55).
[col. 5 line 54 – col. 6 line 13]
A reservation forbidden schedule overlapping the specified time span on the designated date, a reservation forbidden schedule overlapping the specified time span on the same day of the week as the designated date, or a reservation forbidden schedule overlapping daily specified time span are all corresponding reservation forbidden schedules. If there is no corresponding reservation forbidden schedule (NO in Step 55), the processor 30 retrieves the reservation schedule data 33 according to the date 331, start time 333, end time 334 and facility ID 335 (Step 56) to determine whether or not a segment 332 overlapping the specified date and time span for the designated facility ID has a reservation of 1 (approved) (Step 57). If there is no approved reservation at the corresponding time span (NO in Step 57), the processor 30 prepares a record for reservation schedule from the received data to register in the reservation schedule data 33 (Step 58). At this time, the processor 30 sets the segment 332 to 0 (pending). However if the processor 30 determines that there is a reservation forbidden schedule at the corresponding time span (YES in Step 55), an error message is transmitted to client 1 (Step 59) indicating that the request for reservation schedule can not be satisfied. Similarly, if the processor 30 determines that there are no corresponding reservation forbidden schedules (NO in Step 55) and that there is an approved reservation (YES in Step 57), an error message is transmitted to the client 1 (Step 60) indicating that the request for reservation schedule can not be satisfied.
1. A reservation control method for reserving times for use of a plurality of facilities, comprising the steps of:
storing a date and a time span on which each of said facilities are to be used as a reservation schedule;
controlling reservations of said facilities based on said reservation schedule;
setting a time schedule, in which use of at least one of said facilities is forbidden, as a reservation forbidden schedule; and
forbidding reservations for said facilities where said reservations overlap said reservation forbidden schedule.
3. A reservation control method according to claim 2, further comprising the steps of:
temporarily storing a request for reservation, which does not overlap said reservation forbidden schedule and a reservation schedule approved by said manager, as a reservation schedule; and
updating the temporarily stored reservation schedule with a status of approval or non-approval in accordance with instructions from said manager.
18. A reservation control system for reserving times for use of a plurality of facilities, comprising:
a storage which stores a date and a time span on which each of said facilities are to be used as a reservation schedule and a time schedule in which use of at least one of said facilities is forbidden as a reservation forbidden schedule; and
a processor which controls reservations of said facilities based on said reservation schedule, sets a time schedule, in which use of at least one of said facilities is forbidden, as said reservation forbidden schedule, and forbids reservations for said facilities where said reservations overlap said reservation for bidden schedule.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the approval-based gatekeeping system teachings of the prior art of record (see Romeo para 0051 and 0067) by integrating the explicit forbidden schedule state management teachings of Furukawa (see Furukawa col. 5 line 54 – col. 6 line 33) to realize the instant limitations and achieve the feature of a locked and unlocked location reservation function. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that Romeo explicitly recognizes that facility reservations should be locked until approval and Furukawa directly addresses Romeo’s shortcoming by providing detailed technical implementation of the exact locked/unlocked state machine that Romeo describes only conceptually. The motivation to do so is to adopt Furukawa’s specific technical approach (segment-based states with automatic enforcement) to implement Romeo’s conceptual approval-based locking, recognizing that Furukawa solves the precise implementation problem that Romeo identifies but does not fully specify. The motivation to combine is applied to all claims under this heading.
Per claim 4, the prior art of record further suggests while the location reservation function (reads on the combination of making a request for reservation of facilities and making a request for reservation of facilities, see Furukawa claim 18 and col. 5 lines 40 – 53 and see Furukawa claim 18 and col. 5 lines 40 – 53) is in a locked state (reads on the schedule may be locked/pending until approval at a prior gatekeeping step, see Romeo para 0067 and Furukawa col. 4 lines 20 – 30), regular location reservation requests cannot be sent (reads on schedule may be locked until approval, see Romeo para 0067 and Furukawa col. 2 lines 5 – 16) to reserve any physical asset (reads on facilities, see Furukawa col. 1 lines 11 – 28 and Romeo para 0051 and 0060) through the location reservation function (reads on the combination of making a request for reservation of facilities and making a request for reservation of facilities, see Furukawa claim 18 and col. 5 lines 40 – 53 and see Furukawa claim 18 and col. 5 lines 40 – 53); while the location reservation function (reads on the combination of making a request for reservation of facilities and making a request for reservation of facilities, see Furukawa claim 18 and col. 5 lines 40 – 53 and see Furukawa claim 18 and col. 5 lines 40 – 53) is in an unlocked state (reads on the information is completed and the appointment is approved, see Romeo para 0067 and Furukawa col. 4 lines 20 – 30), location reservation requests can be sent to reserve (reads on the appointment is approved/enabled/unlocked, see Romeo para 0067) physical assets (reads on facilities, see Furukawa col. 1 lines 11 – 28 and Romeo para 0051 and 0060).
Per claim 8, the prior art of record further suggests prior to unlocking (reads on the schedule is locked until approval, see Romeo para 0067) the location reservation function (reads on the combination of making a request for reservation of facilities and making a request for reservation of facilities, see Furukawa claim 18 and col. 5 lines 40 – 53 and see Furukawa claim 18 and col. 5 lines 40 – 53), presenting, on a screen of the client device, a list of functions that indicate that (reads on the schedule showing multiple appoints is displayed/appears on the physician’s application which executes on the client computing device, see Romeo para 0050 and 0067) the location reservation function (reads on the combination of making a request for reservation of facilities and making a request for reservation of facilities, see Furukawa claim 18 and col. 5 lines 40 – 53 and see Furukawa claim 18 and col. 5 lines 40 – 53) and one or more other functions are in a locked state (reads on the schedule entries are visually marked/flagged/highlighted to show they are locked, see Romeo para 0067); in response to unlocking the location reservation function, updating the list to indicate that the location reservation function is in an unlocked state (reads on the combination of when the appointment is approved/unlocked the system updates the status from pending to approved, see Romeo para 0067 and Furukawa col. 6 lines 14 – 33).
Per claim 9, the prior art of record further suggests in response to receiving second user input (reads on requesting and receiving additional information, see Romeo para 0067) that selects a check occupancy function that is separate from (reads on retrieving and displaying existing reservation schedule data which is distinct from making a new reservation, see Furukawa claim 25) the location reservation function (reads on the combination of making a request for reservation of facilities and making a request for reservation of facilities, see Furukawa claim 18 and col. 5 lines 40 – 53 and see Furukawa claim 18 and col. 5 lines 40 – 53), transmitting, over the computer network, to a physical access management system, a check occupancy request (reads on the combination of Furukawa transmitting a request to the server/database and Romeo transmitting schedule information to the front desk/access management, see Romeo para 0066 and Furukawa claim 25).
Per claim 11, the prior art of record further suggests in response to determining that a user of the client device attempts to use a locked function (reads on when a patient checks in and the schedule is locked the system has detected that a user attempts to use/check into a locked function/locked schedule, see Romeo para 0065 and 0067), causing prompt data to be presented on a screen of the client device (reads on when information is required from the patient it can be requested/prompted for which is presented to the attendant’s application/displayed on screen, see Romeo para 0067), wherein the prompt data prompts the user to take a picture of a health card (reads on the combination of insurance information/health card is required from patient/prompt to provide and the prompting of the user to upload a photo identification, see Romeo para 0067 and Eberting para 0058).
Claims 12, 14, 22, 24, 25 are analyzed with respect to claims 1, 8, 4, 9, 11 respectively.
Per claim 26, the prior art of record further suggests wherein the instructions, when executed by the one or more processors, further cause:
in response to receiving (reads on receiving scheduling/reservation requests, see Furukawa col. 6 lines 14 – 33 and col. 5 lines 40 – 52), at a server system (reads on server 3 which controls scheduling of the utilization of facility, see Furukawa col. 3 lines 1 – 8), a second location reservation request (reads on request for reservation of a schedule with facility ID specifying which facility/treatment room/test facility, see Romeo para 0031 – 0032 and Furukawa col. 4 lines 20 – 30 and col. 5 lines 39 – 53) that has the status of the temporary request (reads on has pending status, see Furukawa col. 1 lines 11 – 29, col. 4 lines 20 – 30 and col. 5 line 54 – col. 6 line 13) for a second location (reads on second unique facility 335, Furukawa col. 4 lines 20 – 30 and col. 5 line 54 – col. 6 line 13), causing, to be transmitted to a second client device (reads on transmitted to client 1/notifies the user at their terminal, see Furukawa col. 2 lines 49 – 54, col. 5 lines 5 – 9 and col. 5 lines 41 – 43), second confirmation data (reads on the result of temporary registration + displayed schedule/appointment information, see Romeo para 0053 and Furukawa col. 6 lines 14 – 33) that indicates that a second user of (reads on different user ID 336/different healthcare practitioner/physician, see Romeo para 0039, 0050 and Furukawa col. 4 lines 20 – 30 and col. 6 lines 14 – 33) the second client device (reads on second/client 1 terminal/ another healthcare practitioner’s client computing device, see Romeo para 0037 and Furukawa col. 3 lines 19 – 44) has a second temporary reservation (reads on reservation record registered in the reservation schedule data 33 with segment 332 to 0 pending, see Furukawa col. 5 line 54 – col. 6 line 33 and col. 2lines 28 – 37) for the second location (reads on second unique facility 335, Furukawa col. 4 lines 20 – 30 and col. 5 line 54 – col. 6 line 13) and that includes a second invitation to provide valid healthcare information (reads on application prompts/allows healthcare worker to enter diagnosis, treatment, prescription information, see Romeo para 0006, 0054 – 0055)
of the second user (reads on different user ID 336/different healthcare practitioner/physician, see Romeo para 0039, 0050 and Furukawa col. 4 lines 20 – 30 and col. 6 lines 14 – 33); in response to receiving (reads on receiving scheduling/reservation requests, see Furukawa col. 6 lines 14 – 33 and col. 5 lines 40 – 52), at the server system (reads on server 3 which controls scheduling of the utilization of facility, see Furukawa col. 3 lines 1 – 8), from a third client device (reads on client 2/distinct third user input device, see Romeo para 0013 and 0016), a third location reservation request (reads on another request for reservation with a different or same facility ID, see Furukawa col. 5 lines 40 – col. 6 line 33) that has a status of a regular request (reads on segment 332 is approved/confirmed status, see Furukawa col. 2 lines 28 – 37, col. 4 lines 20 – 30 and col. 6 lines 13 – 33) for the second location (reads on second unique facility 335, Furukawa col. 4 lines 20 – 30 and col. 5 line 54 – col. 6 line 13), causing, to be transmitted to the third client device, third confirmation data (reads on notified to client 2/manager’s terminal of result/approval/non-approval, see Furukawa col. 3 lines 19 – 45 and col. 6 lines 14 – 33) that indicates that a third user (reads on another distinct user ID 336 associated with the approved/regular reservation, see Furukawa col. 4 lines 20 – 30 and col. 6 lines 14 – 33) of the third client device (reads on client 2/distinct third user input device, see Romeo para 0013 and 0016) has a regular reservation (reads on a reservation record with segment 332/approval, see Furukawa col. 5 line 54 – col. 6 line 33), for the second location (reads on second unique facility 335, Furukawa col. 4 lines 20 – 30 and col. 5 line 54 – col. 6 line 13), that supersedes (reads on approved reservation which excludes pending/overlapping requests/has the same effect as reservation forbidden schedule. The Examiner further asserts supersession is shown by storing user ID 336 in same facility/location record, see Furukawa col. 3 lines 9 – 18, col. 4 lines 20 – 30, and col. 6 lines 13 – 48) the second temporary reservation (reads on reservation record registered in the reservation schedule data 33 with segment 332 to 0 pending, see Furukawa col. 5 line 54 – col. 6 line 33 and col. 2lines 28 – 37) for the second user of the second client device (reads on different user ID 336/different healthcare practitioner/physician, see Romeo para 0039, 0050 and Furukawa col. 4 lines 20 – 30 and col. 6 lines 14 – 33).
Per claim 27, the prior art of record further suggests further cause, prior to receiving the healthcare information at the client device (reads on operations 111/receiving data and 113/building schedules occur before operation 117/receiving healthcare information, see Romeo para 0049, 0051 and 0054): in response to receiving, at a server system, from a second client device, a second location reservation request that has the status of the temporary request for the first location (reads on second client sends request for reservation to processor with facility ID 335 and segment 332, see Furukawa col. 5 line 39 – col. 6 line 13), based on the temporary reservation for the user of the client device, causing, to be transmitted to the second client device, data that indicates that the second user of the second client device is unable to have a second temporary reservation for the first location (reads on system checks existing reservations at facility ID if overlap is found it transmits error message to client 1 indicating that the request cannot be satisfied indicating inability to create second temporary reservation, see Furukawa col. 1 lines 11 – 28 and col. 5 lines 39 – col. 6 line 48).
Claims 2, 3, 5, 6, 10, 13, 15, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Romeo in view of Furukawa in view of Eberting (US Pub. No. 20220215950 A1).
Per claim 2, the prior art of record suggests the storage media of claim 1 and a remote server system (reads on the central data repository, see Romeo para 0068); wherein unlocking the location reservation function is performed in response to receiving the information (reads on when the information/credential is received/completed then the appointment is approved, see Romeo para 0067). The prior art of record is silent on explicitly stating receiving, from a remote server system, a smart badge that is associated with the healthcare information; wherein unlocking the location reservation function is performed in response to receiving the smart badge.
Eberting (US Pub. No. 20220215950 A1) suggests receiving (reads on the code generation subsystem generates the QR code and necessarily sends/transmits it to the user, see Eberting para 0070 and 0074), from a remote server system (reads on the code generation subsystem, see Eberting para 0074), a smart badge (reads on the QR code that is presented for scanning to gain facility access or share health credentials is functionally a smart badge, see Eberting para 0012, 0051, 0071 and 0074) that is associated with the healthcare information (reads on vaccination/healthcare credentials, see Eberting para 0012 and 0071 – 0074); wherein unlocking in response to receiving (reads on when the QR code/smart badge is presented/received the system validates it and if it satisfies requirements a confirmation is provided/access is granted, see Eberting para 0052 and 0070) the smart badge (reads on the QR code that is presented for scanning to gain facility access or share health credentials is functionally a smart badge, see Eberting para 0012, 0051, 0071 and 0074).
[0012] FIG. 9 illustrates an example GUI for a user to share vaccination credentials (or any other health credential) as a photo, via an app, via email, as a printed PDF, or as QR code, according to one embodiment.
[0051] According to various embodiments, the user may add dependents (e.g., children) and validate and share their vaccination records as well. According to some embodiments, a user may present a QR code to be scanned by an individual, a government, an organization, an employer, a country, a travel provider, a company, a medical professional, a school, a facility, an entertainment venue, or other scanning entity. The scanning entity may request verification that the user has obtained a particular vaccine, specific test result, temperature reading, self-certification of no symptoms, or the like.
[0070] FIG. 8 illustrates series of graphical user interfaces, including a QR code interface 801 that can be used by the user to share personal health information, the details of one or more health credentials, and/or just the existence of one or more health credentials. The graphical user interface may further include a confirmation screen 802 on the user's device and/or the recipient's device indicates that the health credential satisfies predefined requirements. The graphical user interface may further include a screen indicating a failure to satisfy the recipients predefined requirements for health credentials, at 803. For example, the user may have a first does of a Covid-19 vaccine, but the receipt requires both doses of a Covid-19 vaccine. As another example, the user may have received a negative Covid-19 antigen test, but the receipt requires a negative PCR Covid-19 test. The graphical user interface may further include a screen, at 804, in which additional details of the user's health credentials along with a photo for identification purposes. In some embodiments, some details of the user's personal information may be redacted.
[0074] The third-party verification subsystem 1092 may be used to contact the first entity to verify the vaccination status of the user and contact the second entity to verify the test status of the user. The code generation subsystem 1088 may be used to generate a single OR code that can