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 amendment filed 2/17/2026 in which Claims 1-28 are pending.
Response to Arguments
Applicant's arguments filed 2/17/2026 have been fully considered but they are not persuasive. Applicant argues that Shibashi 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. Examiner disagrees and points to Shibashi’s teaching that in the event that a connection between one of the in-network healthcare facilities and the cloud is disconnected, the local servers at the disconnected facilities are restricted to only the addition of new local data to the local repository (see ¶ 0029), and further, in Steps 1040 and 1045, once the application has been restarted, the local computers of the disconnected healthcare facilities perform a check to determine if there is a normal connection between the local servers and the cloud server…If the result of the check is YES, a message is displayed in Step 1050 to the users indicating that the connection between the healthcare facility and the cloud has been reestablished, and that the local computers and servers are switching access back to the remote repository…In Step 1060, when the message is displayed to the users, the users are prompted to make a determination if the users want to continue to work locally off the local repository. The local computers and servers will automatically re-access the cloud server if a response by the users is not detected by the time a countdown timer on the message runs out…Once the pre-set time period has expired, the user would be prompted with another display message to reconnect to the cloud. This time, the user would not be able to choose to continue to work locally off the local repository…If the result of the check is NO, the local computers and servers are configured to re-access the cloud repository in Step 1065 (see ¶ 0077-0082). Examiner construes that while the connection between the local server and cloud server is lost, the system can create new local data to be added to the local repository and while the connection between the local server and cloud server is working, the system receives data from the cloud repository and user is given an option to switch to a cloud repository or remain on the local computers, if users choose to work locally, the system disables local creation after expiration of a timer.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Dunn teaches a management module that comprises a booking module and an access code generator where 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. Shibashi teaches creating local data at a local repository when the connection between the local server and cloud server is interrupted and when the connection between the local server and cloud server is re-established, data is created at the cloud repository. Dunn is related to the local server receiving a booking request to encode a lock and Shibashi is related to record creation at a local server or a cloud server based on the status of a network connection.
In response to applicant's argument that Shibashi and Dunn is nonanalogous art, it has been held that a prior art reference must either be in the field of the inventor’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the inventor was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). In this case, Dunn teaches a management module that comprises a booking module and an access code generator where 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. Shibashi teaches creating local data at a local repository when the connection between the local server and cloud server is interrupted and when the connection between the local server and cloud server is re-established, data is created at the cloud repository. Dunn is related to the local server receiving a booking request to encode a lock and Shibashi is related to record creation at a local server or a cloud server based on the status of a network connection.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
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 network (After the access data has been encoded on the credential 136, the access control module 116 confirms the accuracy of the access data by requesting that the credential 136 provide the access data back to the access control module 116 (step 524). If the access data received from the credential 136 matches the data that was supposed to be written by the access control module 116, then the access control module 116 confirms successful encoding, see Col. 12, lines 37-44).
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 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. 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 16, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose wherein said encoding includes encoding the at least one access device at a level which is different from when the at least one access device is encoded via the cloud server. Elfstrom teaches wherein said encoding includes encoding the at least one access device at a level which is different from when the at least one access device is encoded via the cloud server (if the credential 136 has only been programmed with the minimal amount of access data 320, or has no access data 320 at all, see Col. 9, lines 65-67; determining access privileges for the credential 136 (or more specifically a holder of the credential 136) based on the received access data (step 532), see Col. 12, lines 8-9).
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 encoding includes encoding the at least one access device at a level which is different from when the at least one access device is encoded via the cloud server. 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 17, Dunn, Shibashi and Elfstrom depending on Claim 16, Elfstrom teaches wherein said access credentials released by the local server are first level access credentials, said access credentials released by the cloud server are second level access credentials, the second level access credentials being different from the first level access credentials, wherein presenting one of the first level access credentials at one of the electronic locks blocks the access at this one of the electronic locks for one of the second level access credentials (If no match is found between the information provided by the credential 136 and information maintained in the list 224, then the access control module 116 continues immediately by requesting access data, if such data has not already been obtained from the credential 136, and determining access privileges for the credential 136 (or more specifically a holder of the credential 136) based on the received access data (step 532). Based on this step, the access control module 116 will make a determination as to whether or not the holder of the credential 136 is permitted to access any assets controlled by the access control module 116. If permissions are confirmed, then the access control module 116 will release or otherwise make available such assets to the holder of the credential 136. If permission are not confirmed, then the access control module 116 may either do nothing or provide a failed access attempt message to the holder of the access credential 136 [presenting one of the first level access credentials at one of the electronic locks blocks the access at this one of the electronic locks for one of the second level access credentials] (e.g., by beeping, flashing, or providing some other indicia that can be perceived by the holder), see Col. 12, lines 4-21).
As to Claim 18, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose wherein the at least one access device comprises at least one keycard. Elfstrom teaches wherein the at least one access device comprises at least one keycard (the access credential 136 may comprise a mag-stripe card. In still other embodiments, the access credential 136 may comprise a keyfob, see Col. 10, lines 23-24).
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 access device comprises at least one keycard. The suggestion/motivation would have been in order for the access credential to be provided in any type of form factor (see Col. 10, lines 16-17).
As to Claim 19, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose wherein the at least one access device comprises at least one mobile credential. Elfstrom teaches wherein the at least one access device comprises at least one mobile credential (the access credential may comprise an RFID card or device having similar functionality like a mobile phone, PDA, ebook reader, portable music player, or the like, see Col. 10, lines 19-22).
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 access device comprises at least one mobile credential. The suggestion/motivation would have been in order for the access credential to be provided in any type of form factor (see Col. 10, lines 16-17).
As to Claim 24, Dunn and Shibashi depending on Claim 23, Dunn and Shibashi do not expressly disclose wherein said releasing access credentials includes commanding an encoder located at the premises to encode one or more keycards with the access credentials. Elfstrom teaches wherein said releasing access credentials includes commanding an encoder located at the premises to encode one or more keycards with the access credentials (Access control modules 116 with reading and writing capabilities generally include an RF antenna for exchanging RF messages with access credentials 136 during read operations and a separate RF antenna for transmitting RF messages which encode access credentials 136 during write operations, see Col. 5, lines 9-16).
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 releasing access credentials includes commanding an encoder located at the premises to encode one or more keycards with the access credentials. The suggestion/motivation would have been in order for the access credential to be provided in any type of form factor (see Col. 10, lines 16-17).
As to Claim 25, Dunn and Shibashi depending on Claim 23, Dunn and Shibashi do not expressly disclose wherein said releasing access credentials includes transmitting the access credentials to a customer device. Elfstrom teaches wherein said releasing access credentials includes transmitting the access credentials to a customer device (Access control modules 116 with reading and writing capabilities generally include an RF antenna for exchanging RF messages with access credentials 136 during read operations and a separate RF antenna for transmitting RF messages which encode access credentials 136 during write operations, see Col. 5, lines 9-16).
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 releasing access credentials includes transmitting the access credentials to a customer device. The suggestion/motivation would have been in order for the access credential to be provided in any type of form factor (see Col. 10, lines 16-17).
As to Claim 27, Dunn and Shibashi depending on Claim 26, Dunn and Shibashi do not expressly disclose wherein said access credentials released by the local server are first level access credentials, said access credentials released by the cloud server are second level access credentials, the second level access credentials being different from the first level access credentials, wherein presenting one of the first level access credentials at one of the electronic locks blocks the access at this one of the electronic locks for one of the second level access credentials. Elfstrom teaches wherein said access credentials released by the local server are first level access credentials, said access credentials released by the cloud server are second level access credentials, the second level access credentials being different from the first level access credentials, wherein presenting one of the first level access credentials at one of the electronic locks blocks the access at this one of the electronic locks for one of the second level access credentials (If no match is found between the information provided by the credential 136 and information maintained in the list 224, then the access control module 116 continues immediately by requesting access data, if such data has not already been obtained from the credential 136, and determining access privileges for the credential 136 (or more specifically a holder of the credential 136) based on the received access data (step 532). Based on this step, the access control module 116 will make a determination as to whether or not the holder of the credential 136 is permitted to access any assets controlled by the access control module 116. If permissions are confirmed, then the access control module 116 will release or otherwise make available such assets to the holder of the credential 136. If permission are not confirmed, then the access control module 116 may either do nothing or provide a failed access attempt message to the holder of the access credential 136 [presenting one of the first level access credentials at one of the electronic locks blocks the access at this one of the electronic locks for one of the second level access credentials] (e.g., by beeping, flashing, or providing some other indicia that can be perceived by the holder), see Col. 12, lines 4-21).
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 access credentials released by the local server are first level access credentials, said access credentials released by the cloud server are second level access credentials, the second level access credentials being different from the first level access credentials, wherein presenting one of the first level access credentials at one of the electronic locks blocks the access at this one of the electronic locks for one of the second level access credentials. 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).
Claim(s) 6 is 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 Publication 2020/0145397 to Wu et al (“Wu”).
As to Claim 6, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose wherein the instructions are further executable to, when detecting the interruption, enable the encoding of at least one replacement access device via the at least one encoder. Wu teaches wherein the instructions are further executable to, when detecting the interruption, enable the encoding of at least one replacement access device via the at least one encoder (the cloud platform 11 proceeds a procedure after determining or detecting an abnormal connection condition, and that the connection management module 115 transmits the credential adjustment massage M1 to the service management module 111. Then, the service management module 111 generates the second connection credential C2 according to the secret key K1 [encoder], and indicates the DCCS module 113 and the connection management module 115 to replace the first connection credential C1 with the second connection credential C2 [replacement access device], see ¶ 0034).
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 Wu to teach wherein the instructions are further executable to, when detecting the interruption, enable the encoding of at least one replacement access device via the at least one encoder. The suggestion/motivation would have been in order to for the interrupted connection to trigger the service management module to generate the second connection credential (see ¶ 0035).
Claim(s) 20 is 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 10,891,810 to Sylwan et al (“Sylwan”).
As to Claim 20, Dunn and Shibashi depending on Claim 1, Dunn and Shibashi do not expressly disclose wherein the instructions are further executable to translate TCP/IP messages received from a PMS server to REST API messages, and to send the REST API messages. Sylwan teaches wherein the instructions are further executable to translate TCP/IP messages received from a PMS server to REST API messages, and to send the REST API messages (All communication between entities here are based on established communication protocols, e.g. IP (Internet Protocol)… the user device 8 sends a booking request 20 to the booking agent 3, e.g. using a web page interface [REST API messages] or using an app on the user device 8. The booking agent 3 interacts 21 with the PMS 4 to confirm availability for the booking, see Col. 4, lines 44-46, 52-55).
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 instructions are further executable to translate TCP/IP messages received from a PMS server to REST API messages, and to send the REST API messages. The suggestion/motivation would have been in order for the access credential to be provided in any type of form factor (see Col. 10, lines 16-17).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EBONI N GILES whose telephone number is (571)270-7453. The examiner can normally be reached Monday - Friday 9 am - 6 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK EDOUARD can be reached at (571)272-7603. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EBONI N GILES/ Examiner, Art Unit 2622
/PATRICK N EDOUARD/ Supervisory Patent Examiner, Art Unit 2622
Prosecution Insights