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
This office action is in response to the application filed 6/21/2023 in which Claims 1-28 are pending.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 9/20/2024 and 11/6/2024 were filed after the mailing date of the application on 6/21/2023. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 5, 7-12, 15, 21-23, 26, 28, 29 are rejected under 35 U.S.C. 103 as being unpatentable over Australian Patent Publication 2012/222859 to Dunn in view of U.S. Patent Publication 2018/00285434 to Shibashi et al (“Shibashi”).
As to Claim 1, Dunn teaches a local server located at a premises, the premises having at least one unit, the premises having at least one electronic lock, the premises having at least one workstation, the premises having at least one encoder, the local server comprising a memory and a processor, the memory having stored thereon configuration data for the premises (management module may be provided in a single server [local server located at a premises, premises having at least one unit] …configuration data from an electronic lock 202 is provided to the management module 210, see pg. 10, lines 10-13; the management module includes a management database [memory]…the management module also includes an access code generator [encoder]…based upon configuration data (stored in the management database), see pg. 10, lines 20, 25, 27; the interface also provides a management interface [workstation] to allow management 20 such as an owner, manager or staff of the tourist accommodation to access the management module, see pg. 11, lines 18-20), and
for each of the at least one booking: creating the at least one booking based on the configuration data and based on inputs received from a given one of the at least one workstation, including storing booking data into the memory, the booking data comprising an access period at the premises (The management module also includes a booking module for receiving and storing a booking request from a guest (user). The booking request is for a specific room (and thus lock) for a specified time period (booking time period), see pg. 10, lines 28-31; The system also provides an interface [workstation] for allowing users to interface with the management module. The interface includes an end user interface which allows end users 204 (ie guests) to search for available rooms, browse available rooms, view property details on available rooms (eg number of beds, hotel facilities, etc), and make booking requests to stay in an available room [creating booking based on inputs received from a workstation] for a desired time period. The end user interface can also be used to provide booking confirmation information to the end user including the access code determined for their room, see pg. 11, lines 10-17); and
encoding at least one access device via at least one of said at least one encoders, including granting the at least one access device access, for the access period, to at least one of the at least one unit (The management module includes a management database for storing information relating to the rooms (locations) at the tourist accommodation site (eg hotel) such as information relating to bookings (current and future), lock configuration files for each of the locks, and access logs for the locks. Access to the management data base is controlled to prevent unauthorised access. The management module also includes an access code generator for determining one or more time based access codes for each of the electronic locks [encoding at least one access device via an encoder] based upon configuration data (stored in the management database) associated with each of respective electronic locks. The management module also includes a booking module for receiving and storing a booking request from a guest (user). The booking request is for a specific room (and thus lock) for a specified time period (booking time period). Upon receipt of a booking request the booking module communicates with the access code generator to determine an access code for the desired time period [granting the access device access for the access period to at least one of the at least one unit], see pg. 10, lines 20-33);
Dunn does not expressly disclose instructions executable by the processor to: monitor a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity; when detecting the interruption, enable local creation of at least one booking and when detecting the connection, disable local creation of at least one booking.
Shibashi teaches instructions executable by the processor to: monitor a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity (in steps 100 and 1010, the local computers associated with one of the in-network healthcare facilities check the status of the connection between the local servers of the healthcare facility and the cloud server on the cloud to determine if the connection is normal, see ¶ 0071; if the result of the check in step 1010 is NO, a message is displayed in Step 102 to the user indicating that the connection between the healthcare facility and the cloud is disconnected, see ¶ 0074);
when detecting the interruption, enable local creation of at least one booking (in the event that a connection between one of the in-network healthcare facilities and the cloud is disconnected and the local servers at the disconnected facility switch to working off the local repository, a restriction is placed on the disconnected facility with respect to the editing that can be performed on the local repository. The local servers at the disconnected facilities are restricted to only the addition of new local data to the local repository [enable local creation of at least one booking] and prohibited from the editing and updating of existing local data, see ¶ 0029) and when detecting the connection, disable local creation of at least one booking (when the connection between the disconnected healthcare facility is reestablished with the cloud (101), the local computers (111) and local servers (107) of the reconnected healthcare facility may be configured by the application to transmit to the cloud (101) all of the medical images and data stored in the local repository taken or updated during the time of disconnection [disable local creation of at least one booking]. Such medical images and data may then be stored in the cloud repository (105) as new remote data, see ¶ 0045).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Dunn with Shibashi to teach instructions executable by the processor to: monitor a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity; when detecting the interruption, enable local creation of at least one booking and when detecting the connection, disable local creation of at least one booking. The suggestion/motivation would have been in order to prevent a potential conflict that may occur at different in-network healthcare facilities update information in the respective local data (see ¶ 0030).
As to Claim 5, Dunn and Shibashi depending on Claim 1, Shibashi teaches wherein the instructions are further executable to, when detecting the interruption, enable consultation of the booking data via the at least one workstation (in the event that a connection between one of the in-network healthcare facilities and the cloud is disconnected and the local servers at the disconnected facility switch to working off the local repository, a restriction is placed on the disconnected facility with respect to the editing that can be performed on the local repository. The local servers at the disconnected facilities are restricted to only the addition of new local data to the local repository and prohibited from the editing and updating of existing local data, see ¶ 0029; where a connection between one of the in-network healthcare facilities and the cloud (101) is disconnected. In this state, the application may automatically configure the local computers (111) and local servers (107) at the disconnected healthcare facility to access the local data stored in the local repository (109). In one or more embodiments, the disconnected healthcare facility continues to store into the local repository (109) medical images and data taken or updated during the time of disconnection [enable consultation of the booking data via the workstation], see ¶ 0044).
As to Claim 7, Dunn and Shibashi depending on Claim 5, Shibashi teaches wherein the instructions are further executable to, when detecting the interruption, enable modification of the booking data via the at least one workstation (the disconnected healthcare facility continues to store into the local repository (109) medical images and data taken or updated during the time of disconnection, see ¶ 0029).
As to Claim 8, Dunn and Shibashi depending on Claim 1, Shibashi teaches wherein the instructions are further executable to, when detecting the connection, communicating the booking data to the cloud server via a telecommunications network (the in-network healthcare facilities may transmit locally-obtained medical images and data to the cloud (101) to be stored as remote data in the cloud repository (105) accessible to other in-network healthcare facilities. In one or more embodiments, the in-network healthcare facilities may retrieve medical images and data from the cloud (101) to be stored as local data in their respective local repositories (109), see ¶ 0040; when the connection between the disconnected healthcare facility is reestablished with the cloud (101), the local computers (111) and local servers (107) of the reconnected healthcare facility may be configured by the application to transmit to the cloud (101) all of the medical images and data stored in the local repository [communicating booking data to the cloud server via a telecommunications network] taken or updated during the time of disconnection [disable local creation of at least one booking]. Such medical images and data may then be stored in the cloud repository (105) as new remote data, see ¶ 0045).
As to Claim 9, Dunn and Shibashi depending on Claim 8, Shibashi teaches wherein the instructions are further executable to delete the booking data from the local server subsequently to said communicating the booking data to the cloud server (a conflict may occur when local data from the local servers of the in-network healthcare facilities are being uploaded to the cloud server (e.g., during medical data synchronization between the respective local servers and the cloud server). The conflict may occur when different users at different in-network healthcare facilities attempt to simultaneously update the same portion of the patient information of the same remote data by editing or updating the information locally in the corresponding local data. This may prevent the application from determining which of the updated patient information is correct when the cloud server tries to update the remote data using the information from the two received edited local data, see ¶ 0084; replace pre-existing locally-stored data that corresponds to the updated data with the updated data, see ¶ 0086; When the local computers and servers of the in-network facilities receive the updated data, the respective local computers and servers will either add the updated data to the respective local repositories if the updated data did not previously exist, or replace pre-existing locally-stored data that corresponds to the updated data with the updated data, see ¶ 0087).
As to Claim 10, Dunn and Shibashi depending on Claim 8, Dunn teaches wherein said creating includes, for each one of the at least one booking, storing key data in association with corresponding booking data in the memory (The management module includes a management database for storing information relating to the rooms (locations) at the tourist accommodation site (eg hotel) such as information relating to bookings (current and future), lock configuration files for each of the locks, and access logs for the locks. Access to the management data base is controlled to prevent unauthorised access. The management module also includes an access code generator for determining one or more time based access codes for each of the electronic locks [encoding at least one access device via an encoder] based upon configuration data (stored in the management database) associated with each of respective electronic locks, see pg. 10, lines 20-28); and wherein the instructions are further executable by the processor to, when detecting the connection, communicating the key data to the cloud server via the telecommunications network (The management module also includes an access code distribution module for sending the access code to a guest or user of the system. The access code may be provided via an interface 220 or via an alternative communication means 232 directly to the 5 guest or via an alternative communication means 234 directly to the owner or manager. Such alternative communication means may be long range communication means such as email or SMS messages over a telecommunications network. In one preferred embodiment the access code is delivered by an application on a Smartphone, see pg. 11, lines 1-9; The end user interface can also be used to provide booking confirmation information to the end user including the access code determined for their room, see pg. 11, lines 10-17).
As to Claim 11, Dunn and Shibashi depending on Claim 8, Dunn teaches
wherein the key data includes an identifier of the at least one access device, an identifier of a staff member logged into the local server and responsible for the encoding, and date information at which the encoding was performed (the lock includes a clock, a processor and associated memory in which instructions are stored for generating time based access codes which can be compared or verified against an entered access code (and the current time) to determine whether to allow entry based upon the current time received from the clock. The access code (or PIN number) is generated based upon a user level, unit number start and end date, see Col. 8, lines 4-9; The interface also provides a management interface to allow management 206 such as an owner, manager or staff of the tourist 20 accommodation to access the management module. Different levels of access can be given to different management according to their roles (eg a hotel management or owner will be given greater access or control then a reservation or maintenance staff member). The management interface can be used for viewing and modifying information relating to the rooms and to 25 determine access codes for one or more users, see pg. 11, lines 18-25).
As to Claim 12, Dunn and Shibashi depending on Claim 1, Dunn teaches
wherein said granting further includes granting the at least one access device access, for the access period, to at least one of a floor, a pool, a gym, a food area, a conference area, and a terrace ( manage access to accommodation 20 such as hotels, apartments, holiday houses, caravan parks, rental houses, sporting facilities such as tennis courts, ovals, basketball courts, homes, businesses, sheds, secure storage facilities, etc. These locations (or sites, of facilities) may be single locations (eg single house or facility), or there may be several independently bookable rooms or facilities at a site (or related sites), see pg. 7, lines 19-24).
As to Claim 15, Dunn and Shibashi depending on Claim 1, Shibashi teaches wherein the instructions are further executable to copy cloud booking data stemming from previous bookings from the cloud server to the memory, including updating the cloud booking data in the memory to reflect changes in the cloud booking data at the cloud server, said storing booking data including forming offline booking data including adding the booking data to the cloud booking data in the memory (when the local computers and servers have re-accessed the cloud repository, the cloud repository is synchronized, i.e., updated with data stored in the local repository during the time of reconnection along with new data that was generated after the reconnection with the cloud server. In the event a conflict has occurred during the disconnection (e.g., when more than one user at different in-network healthcare facilities attempts to simultaneously update the patient information associated with the same remote data on the remote server), the conflict may be resolved automatically by the application or manually by the user through a GUI provided by the application, see ¶ 0083; the local computers and servers of the disconnected healthcare facility will receive data from the cloud server updated by the other in-network healthcare facilities during the time of disconnection and either add the updated data to the local repository if the updated data did not previously exist, or replace pre-existing locally-stored data that corresponds to the updated data with the updated data, see ¶ 0086; n response to the cloud server being updated in Step 1070, the local computers and servers of the other in-network facilities will receive either all or part of the updated data from the cloud server. When the local computers and servers of the in-network facilities receive the updated data, the respective local computers and servers will either add the updated data to the respective local repositories if the updated data did not previously exist, or replace pre-existing locally-stored data that corresponds to the updated data with the updated data, see ¶ 0087).
As to Claim 21, Dunn teaches a method of encoding access devices for controlling access to at least one unit located at a premises, the premises having at least one workstation and at least one encoder for encoding the at least one access device (management module may be provided in a single server [premises having at least one unit] …configuration data from an electronic lock 202 is provided to the management module 210, see pg. 10, lines 10-13; the management module includes a management database …the management module also includes an access code generator [encoder]…based upon configuration data (stored in the management database), see pg. 10, lines 20, 25, 27; the interface also provides a management interface [workstation] to allow management 20 such as an owner, manager or staff of the tourist accommodation to access the management module, see pg. 11, lines 18-20), and
for each of the at least one booking: creating the at least one booking based on the configuration data and based on inputs received from a given one of the at least one workstation, including storing booking data into the memory, the booking data comprising an access period at the premises (The management module also includes a booking module for receiving and storing a booking request from a guest (user). The booking request is for a specific room (and thus lock) for a specified time period (booking time period), see pg. 10, lines 28-31; The system also provides an interface [workstation] for allowing users to interface with the management module. The interface includes an end user interface which allows end users 204 (ie guests) to search for available rooms, browse available rooms, view property details on available rooms (eg number of beds, hotel facilities, etc), and make booking requests to stay in an available room [creating booking based on inputs received from a workstation] for a desired time period. The end user interface can also be used to provide booking confirmation information to the end user including the access code determined for their room, see pg. 11, lines 10-17); and
encoding at least one access device via at least one of said at least one encoders, including granting the at least one access device access, for the access period, to at least one of the at least one unit (The management module includes a management database for storing information relating to the rooms (locations) at the tourist accommodation site (eg hotel) such as information relating to bookings (current and future), lock configuration files for each of the locks, and access logs for the locks. Access to the management data base is controlled to prevent unauthorised access. The management module also includes an access code generator for determining one or more time based access codes for each of the electronic locks [encoding at least one access device via an encoder] based upon configuration data (stored in the management database) associated with each of respective electronic locks. The management module also includes a booking module for receiving and storing a booking request from a guest (user). The booking request is for a specific room (and thus lock) for a specified time period (booking time period). Upon receipt of a booking request the booking module communicates with the access code generator to determine an access code for the desired time period [granting the access device access for the access period to at least one of the at least one unit], see pg. 10, lines 20-33);
Dunn does not expressly disclose the method comprising: at the premises, monitoring a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity; when detecting the interruption, enabling local creation of at least one booking and when detecting the connection, disabling the local creation of at least one booking.
Shibashi teaches the method comprising: at the premises, monitoring a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity (in steps 100 and 1010, the local computers associated with one of the in-network healthcare facilities check the status of the connection between the local servers of the healthcare facility and the cloud server on the cloud to determine if the connection is normal, see ¶ 0071; if the result of the check in step 1010 is NO, a message is displayed in Step 102 to the user indicating that the connection between the healthcare facility and the cloud is disconnected, see ¶ 0074);
when detecting the interruption, enabling local creation of at least one booking (in the event that a connection between one of the in-network healthcare facilities and the cloud is disconnected and the local servers at the disconnected facility switch to working off the local repository, a restriction is placed on the disconnected facility with respect to the editing that can be performed on the local repository. The local servers at the disconnected facilities are restricted to only the addition of new local data to the local repository [enable local creation of at least one booking] and prohibited from the editing and updating of existing local data, see ¶ 0029) and when detecting the connection, disabling the local creation of at least one booking (when the connection between the disconnected healthcare facility is reestablished with the cloud (101), the local computers (111) and local servers (107) of the reconnected healthcare facility may be configured by the application to transmit to the cloud (101) all of the medical images and data stored in the local repository taken or updated during the time of disconnection [disable local creation of at least one booking]. Such medical images and data may then be stored in the cloud repository (105) as new remote data, see ¶ 0045).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Dunn with Shibashi to teach the method comprising: at the premises, monitoring a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity; when detecting the interruption, enabling local creation of at least one booking and when detecting the connection, disabling the local creation of at least one booking. The suggestion/motivation would have been in order to prevent a potential conflict that may occur at different in-network healthcare facilities update information in the respective local data (see ¶ 0030).
As to Claim 22, Dunn and Shibashi depending on Claim 21, Dunn teaches wherein said creating includes, for each one of the at least one booking, storing key data in association with corresponding booking data in the memory (The management module includes a management database for storing information relating to the rooms (locations) at the tourist accommodation site (eg hotel) such as information relating to bookings (current and future), lock configuration files for each of the locks, and access logs for the locks. Access to the management data base is controlled to prevent unauthorised access. The management module also includes an access code generator for determining one or more time based access codes for each of the electronic locks [encoding at least one access device via an encoder] based upon configuration data (stored in the management database) associated with each of respective electronic locks, see pg. 10, lines 20-28); further comprising, when detecting the connection, communicating the key data and the booking data to the cloud server via the telecommunications network (The management module also includes an access code distribution module for sending the access code to a guest or user of the system. The access code may be provided via an interface 220 or via an alternative communication means 232 directly to the 5 guest or via an alternative communication means 234 directly to the owner or manager. Such alternative communication means may be long range communication means such as email or SMS messages over a telecommunications network. In one preferred embodiment the access code is delivered by an application on a Smartphone, see pg. 11, lines 1-9; The end user interface can also be used to provide booking confirmation information to the end user including the access code determined for their room, see pg. 11, lines 10-17).
As to Claim 23, Dunn teaches a method of releasing access credentials for providing access to units controlled by electronic locks located at a premises, the premises having a workstation, the local server having a memory and configuration data stored in the memory (management module may be provided in a single server…configuration data from an electronic lock 202 is provided to the management module 210, see pg. 10, lines 10-13; the management module [local server] includes a management database …the management module also includes an access code generator…based upon configuration data (stored in the management database), see pg. 10, lines 20, 25, 27; the interface also provides a management interface [workstation] to allow management 20 such as an owner, manager or staff of the tourist accommodation to access the management module, see pg. 11, lines 18-20), and
for each of the bookings: creating the at least one booking based on the configuration data and based on inputs received from the workstation, the booking data including an access period at one or more units (The management module also includes a booking module for receiving and storing a booking request from a guest (user). The booking request is for a specific room (and thus lock) for a specified time period (booking time period), see pg. 10, lines 28-31; The system also provides an interface [workstation] for allowing users to interface with the management module. The interface includes an end user interface which allows end users 204 (ie guests) to search for available rooms, browse available rooms, view property details on available rooms (eg number of beds, hotel facilities, etc), and make booking requests to stay in an available room [creating booking based on inputs received from a workstation] for a desired time period. The end user interface can also be used to provide booking confirmation information to the end user including the access code determined for their room, see pg. 11, lines 10-17); and
releasing access credentials, including granting access, for the access period, to the one or more of the units controlled by one or more of the electronic locks (The management module includes a management database for storing information relating to the rooms (locations) at the tourist accommodation site (eg hotel) such as information relating to bookings (current and future), lock configuration files for each of the locks, and access logs for the locks. Access to the management data base is controlled to prevent unauthorised access. The management module also includes an access code generator for determining one or more time based access codes for each of the electronic locks [encoding at least one access device via an encoder] based upon configuration data (stored in the management database) associated with each of respective electronic locks. The management module also includes a booking module for receiving and storing a booking request from a guest (user). The booking request is for a specific room (and thus lock) for a specified time period (booking time period). Upon receipt of a booking request the booking module communicates with the access code generator to determine an access code for the desired time period [granting the access device access for the access period to at least one of the at least one unit], see pg. 10, lines 20-33);
Dunn does not expressly disclose the method comprising: at the premises, monitoring connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity; when detecting the interruption, enabling local creation of bookings by a local server and when detecting the connection, disabling the local creation of at least one booking.
Shibashi teaches the method comprising: at the premises, monitoring a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity (in steps 100 and 1010, the local computers associated with one of the in-network healthcare facilities check the status of the connection between the local servers of the healthcare facility and the cloud server on the cloud to determine if the connection is normal, see ¶ 0071; if the result of the check in step 1010 is NO, a message is displayed in Step 102 to the user indicating that the connection between the healthcare facility and the cloud is disconnected, see ¶ 0074);
when detecting the interruption, enabling local creation of at least one booking (in the event that a connection between one of the in-network healthcare facilities and the cloud is disconnected and the local servers at the disconnected facility switch to working off the local repository, a restriction is placed on the disconnected facility with respect to the editing that can be performed on the local repository. The local servers at the disconnected facilities are restricted to only the addition of new local data to the local repository [enable local creation of at least one booking] and prohibited from the editing and updating of existing local data, see ¶ 0029) and when detecting the connection, disabling the local creation of at least one booking (when the connection between the disconnected healthcare facility is reestablished with the cloud (101), the local computers (111) and local servers (107) of the reconnected healthcare facility may be configured by the application to transmit to the cloud (101) all of the medical images and data stored in the local repository taken or updated during the time of disconnection [disable local creation of at least one booking]. Such medical images and data may then be stored in the cloud repository (105) as new remote data, see ¶ 0045).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Dunn with Shibashi to teach the method comprising: at the premises, monitoring a connectivity to a cloud server to detect an interruption in the connectivity and to detect a connection in the connectivity; when detecting the interruption, enabling local creation of at least one booking and when detecting the connection, disabling the local creation of at least one booking. The suggestion/motivation would have been in order to prevent a potential conflict that may occur at different in-network healthcare facilities update information in the respective local data (see ¶ 0030).
As to Claim 26, Dunn and Shibashi depending on Claim 23, Shibashi teaches further comprising a cloud server releasing access credentials over a telecommunications network prior to detecting the interruption in the connectivity (the in-network healthcare facilities may transmit locally-obtained medical images and data to the cloud (101) to be stored as remote data in the cloud repository (105) accessible to other in-network healthcare facilities, see ¶ 0040).
As to Claim 28, Dunn and Shibashi depending on Claim 26, Shibashi teaches copying cloud booking data associated to the encoding by the cloud server to the memory of the local server, including updating the cloud booking data in the memory to reflect changes in the cloud booking data at the cloud server, said storing booking data including adding the booking data to the cloud booking data in the memory to form offline booking data (when the local computers and servers have re-accessed the cloud repository, the cloud repository is synchronized, i.e., updated with data stored in the local repository during the time of reconnection along with new data that was generated after the reconnection with the cloud server. In the event a conflict has occurred during the disconnection (e.g., when more than one user at different in-network healthcare facilities attempts to simultaneously update the patient information associated with the same remote data on the remote server), the conflict may be resolved automatically by the application or manually by the user through a GUI provided by the application, see ¶ 0083; the local computers and servers of the disconnected healthcare facility will receive data from the cloud server updated by the other in-network healthcare facilities during the time of disconnection and either add the updated data to the local repository if the updated data did not previously exist, or replace pre-existing locally-stored data that corresponds to the updated data with the updated data, see ¶ 0086; n response to the cloud server being updated in Step 1070, the local computers and servers of the other in-network facilities will receive either all or part of the updated data from the cloud server. When the local computers and servers of the in-network facilities receive the updated data, the respective local computers and servers will either add the updated data to the respective local repositories if the updated data did not previously exist, or replace pre-existing locally-stored data that corresponds to the updated data with the updated data, see ¶ 0087).
As to Claim 29, Dunn and Shibashi depending on Claim 28, Shibashi teaches when detecting the connection, the local server uploading the offline booking data to the cloud server (the cloud server (103) is configured to receive the medical images and data transmitted from the local servers (107) and store the medical images and data in the cloud repository (105) as remote data [offline booking data], see ¶ 0036; when the connection between the disconnected healthcare facility is reestablished with the cloud (101), the local computers (111) and local servers (107) of the reconnected healthcare facility may be configured by the application to transmit to the cloud (101) all of the medical images and data stored in the local repository taken or updated during the time of disconnection. Such medical images and data may then be stored in the cloud repository (105) as new remote data. As the cloud (101) is being updated with the medical images and data from the reconnected healthcare facility, the application stored in the local computers (111) of the other in-network facilities may automatically update their respective local repositories (109) with the new remote data, see ¶ 0045).
Claim(s) 2-4, 13, 14, 16-19, 24, 25, 27 are rejected under 35 U.S.C. 103 as being unpatentable over Australian Patent Publication 2012/222859 to Dunn in view of U.S. Patent Publication 2018/00285434 to Shibashi et al (“Shibashi”) in further view of U.S. Patent 8,730,004 to Elfstrom et al (“Elfstrom”).
As to Claim 2, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose wherein the at least one workstation includes a plurality of workstations and wherein the at least one encoder includes a plurality of encoders, wherein the instructions are executable to repeat the creating and encoding for a plurality of bookings based on the configuration data and inputs from different ones of the plurality of workstations, including adding the booking data generated by the creation of each one of the plurality of bookings to a table in the memory, and repeating the encoding for each one of the plurality of bookings via different ones of the plurality of encoders, the different ones of the plurality of encoders associated to different ones of the plurality of workstations.
Elfstrom teaches wherein the at least one workstation includes a plurality of workstations and wherein the at least one encoder includes a plurality of encoders (access control modules 116, on the other hand, are usually provided to secure various assets within the multi-room facility…access control modules 116 [plurality of encoders] may be provided at access points [plurality of workstations] to various physical assets, see Col. 4, lines 30-34),
wherein the instructions are executable to repeat the creating and encoding for a plurality of bookings based on the configuration data and inputs from different ones of the plurality of workstations, including adding the booking data generated by the creation of each one of the plurality of bookings to a table in the memory (guest reservations for one or more assets (e.g., rooms 112a-N, services, and the like) [plurality of workstations] in the multi-room facility are confirmed at the central access control logic 132 [creating and encoding for a plurality of bookings based on the configuration data and inputs from different ones of the plurality of workstations]. This reservation information may be maintained in the database 140 and may be retrieved by the access control logic 132 or may have been written to the database 140 by the access control logic 132 [adding the booking data generated by the creation of each one of the plurality of bookings to a table in the memory], see Col. 10, lines 30-35; Once generated, the access control logic 132 causes the message(s) to be transmitted to one or more authorized access control modules 116 within the secure access system 100 (step 412). In some embodiments messages are transmitted to all access control modules 116 within the secure access system 100, see Col. 10, lines 50-55), and
repeating the encoding for each one of the plurality of bookings via different ones of the plurality of encoders, the different ones of the plurality of encoders associated to different ones of the plurality of workstations (Once generated, the access control logic 132 causes the message(s) to be transmitted to one or more authorized access control modules 116 within the secure access system 100 (step 412). In some embodiments messages are transmitted to all access control modules 116 within the secure access system 100 [encoding each of the plurality of bookings via different ones of the plurality of encoders, different encoders associated with different workstations]. In other embodiments, messages are only transmitted to access control modules 116 having a check-in module 220. In other embodiments, only a subset of access control modules 116 having a check-in module 220 receive a message enabling non-front desk check-in, see Col. 10, lines 50-59).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Dunn and Shibashi with Elfstrom to teach wherein the at least one workstation includes a plurality of workstations and wherein the at least one encoder includes a plurality of encoders, wherein the instructions are executable to repeat the creating and encoding for a plurality of bookings based on the configuration data and inputs from different ones of the plurality of workstations, including adding the booking data generated by the creation of each one of the plurality of bookings to a table in the memory, and repeating the encoding for each one of the plurality of bookings via different ones of the plurality of encoders, the different ones of the plurality of encoders associated to different ones of the plurality of workstations. The suggestion/motivation would have been in order for reservation information to be maintained in the database and retrieved by the access control logic (see Col. 10, lines 32-34).
As to Claim 3, Dunn, Shibashi and Elfstrom depending on Claim 2, Elfstrom teaches including, for a first one of the plurality of bookings, creating the table and including the corresponding booking data as a first line of the table (This reservation information may be maintained in the database 140 and may be retrieved by the access control logic 132 or may have been written to the database 140 by the access control logic 132 [adding the booking data generated by the creation of each one of the plurality of bookings to a table in the memory], see Col. 10, lines 30-35).
As to Claim 4, Dunn, Shibashi and Elfstrom depending on Claim 2, Elfstrom teaches wherein the encoding includes determining which one of the plurality of encoders to send an encoding command to based on association data, the association data associating different ones of the plurality of encoders to different ones of the plurality of workstations, the association data forming part of the configuration data workstations (guest reservations for one or more assets (e.g., rooms 112a-N, services, and the like) [plurality of workstations] in the multi-room facility are confirmed at the central access control logic 132 [creating and encoding for a plurality of bookings based on the configuration data and inputs from different ones of the plurality of workstations]. This reservation information may be maintained in the database 140 and may be retrieved by the access control logic 132 or may have been written to the database 140 by the access control logic 132 [adding the booking data generated by the creation of each one of the plurality of bookings to a table in the memory], see Col. 10, lines 30-35; Once generated, the access control logic 132 causes the message(s) to be transmitted to one or more authorized access control modules 116 within the secure access system 100 (step 412). In some embodiments messages are transmitted to all access control modules 116 within the secure access system 100 [encoding each of the plurality of bookings via different ones of the plurality of encoders, different encoders associated with different workstations]. In other embodiments, messages are only transmitted to access control modules 116 having a check-in module 220. In other embodiments, only a subset of access control modules 116 having a check-in module 220 receive a message enabling non-front desk check-in, see Col. 10, lines 50-59).
As to Claim 13, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose wherein said enabling the local creation of at least one booking further includes receiving a login request from the given one of the at least one workstation over a local area network, authenticating the login request against the configuration data, and granting access to the creating and encoding contingent upon the authenticating the login request. Elfstrom teaches wherein said enabling the local creation of at least one booking further includes receiving a login request from the given one of the at least one workstation over a local area network, authenticating the login request against the configuration data, and granting access to the creating and encoding contingent upon the authenticating the login request (the access control logic 132 may be adapted to respond to requests generated by the access control modules 116 and credential programming system 128…the access control logic 132 may be adapted to provide instructions to the access control modules 116 and credential programming system 128, thereby allowing these devices to administer some or all of the secure access system 100… it is generally preferred by owners and operators of the multi-room facility to maintain a certain level of security over the credential programming system 128 since it has the capability of writing access data to credentials which could potentially allow a holder of the credential to access any asset within the multi-room facility. Without some level of control over the credential programming system 128, there could be an increased risk that guests would write access data to their credentials that exceeds the access permissions which would otherwise be provided to the guest [granting access to the creating and encoding contingent upon the authenticating the login request]. For this reason almost all current multi-room facilities require a guest to check-in at the front desk 118 so that the guest can obtain an access credential that has access data properly and accurately written thereto, see Col. 3, line 66 – Col. 4, lines 29).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Dunn and Shibashi with Elfstrom to teach wherein said enabling the local creation of at least one booking further includes receiving a login request from the given one of the at least one workstation over a local area network, authenticating the login request against the configuration data, and granting access to the creating and encoding contingent upon the authenticating the login request. The suggestion/motivation would have been in order maintain a certain level of security over the credential programming system (see Col. 4, lines 17-18).
As to Claim 14, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose for each one of the at least one booking receiving a confirmation of a success of the encoding from the given one of the at least one encoder via a local area network, and communicating the confirmation of the success of the encoding to the given one of the at least one workstation via the local area network. Elfstrom teaches for each one of the at least one booking receiving a confirmation of a success of the encoding from the given one of the at least one encoder via a local area network, and communicating the confirmation of the success of the encoding to the given one of the at least one workstation via the local area