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 .
The application of Kudoor et al. for a “door lock remote calibration” filed on March 26, 2025 has been examined.
This application is a CON of 18/744,402, filed on June 14, 2024, now US# 12,333,879, which has a priority to U.S. provisional application number 63/594,329, which is filed on October 30, 2023.
Claims 1-20 are pending.
Specification
The disclosure is objected to because of the following informalities: Under cross references to related applications CON status needs to be updated. Serial number 18/744,402, filed on June 14, 2024, now US# 12,333,879.
Claim Construction
The following is a quotation of 35 U.S.C. 112(f).
(f) Element in Claim for a Combination. - An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Use of the word “means” (or “step for”) in a claim with functional language creates a rebuttable presumption that the claim element is to be treated in accordance with 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is invoked is rebutted when the function is recited with sufficient structure, material, or acts within the claim itself to entirely perform the recited function.
Absence of the word “means” (or “step for”) in a claim creates a rebuttable presumption that the claim element is not to be treated in accordance with 35 U.S.C.
112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is not invoked is rebutted when the claim element recites function but fails to recite sufficiently definite structure, material or acts to perform that function.
Claim elements in this application that use the word “means for” (or “step for”) are presumed to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Similarly, claim elements that do not use the word “means” (or “step for”) are presumed not to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
Claim 20 recites limitations that invoke 35 U.S.C. 112(f).
Regarding claim 20, the limitation that recite(s) “means for” is being treated in accordance with 112(f) because the functions of "means for” is modified by the term “initiating calibration” which is a word that serves as a generic placeholder for structure that performs the recited functions.
After a careful analysis, as disclosed in the claim construction above, and a careful review of the specification is found that the disclosure does not provide support for the limitations.
In conclusion, limitations “means for” are considered to invoke 35 U.S.C 112(f).
If applicant wishes to provide further explanation or dispute the examiner's interpretation of the corresponding structure, applicant must identify the corresponding structure with reference to the specification by page and line number, and to the drawing, if any, by reference characters in response to this Office action.
If applicant does not wish to have the claim limitation treated under 35 U.S.C.
112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, applicant may amend the claim so that it will clearly not invoke 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph, or present a sufficient showing that the claim recites sufficient structure, material, or acts for performing the claimed function to preclude application of 35 U.S.C. 112(f) or 35 U.S.C. 112 (pre-AIA ), sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance with 35 U.S.C. §112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
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.
Claims 1-8 and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Zakaria (US# 9,704,318) in view of Kjellsson et al. (Pub. No. US 2016/0353239).
Referring to claim 1, Zakaria et al. disclose a system (i.e. a system for a wireless Internet of the Thing (IoT) lock) (column 2 lines 49 to 64; see Figures 1 to 15) comprising:
an application (i.e. an IoT App, browser or an Web Application) executable on a mobile device (703) (i.e. a user device with installed App or browser), the application to send a request to calibration of a lock (702) (i.e. one of the electronic equipment as a security device such as a door lock opener) for a door (601) of a building in response to an input received via a user interface of the application (i.e. one or more other/alternate I/O devices or sensors 250 may be included on the IoT device 101 based on the particular application for which the IoT device 101 is designed. For example, an environmental sensor may be included to measure temperature, pressure, humidity, etc. A security sensor and/or door lock opener may be included if the IoT device is used as a security device) (column 5 lines 40 to 46; see Figures 1b and 7-9) and (i.e. a calibration module 910 on the IoT hub 710 communicates with an app or browser-based code on the wireless device 703 to calibrate the signal strength measurements. During calibration, the system calibration module 910 and/or calibration app may instruct the user to stand in certain locations outside the door and inside the door (e.g., outside 6 ft outside door 1, 6 ft inside door 1, 6 ft outside door 2, etc). The user may indicate that he/she is in the desired position by selecting a graphic on the user interface. The system calibration app and/or system calibration module 910 will then associate the collected signal strength values 900 with each location within a location database 901 on the IoT hub/device 710) (column 12 lines 35 to 49; see Figures 1b and 9);
a computing environment (110) (i.e. a central IoT Hub), the computing environment (110) to initiate calibration of the lock in response to receipt of the request from the application (i.e. the IoT hub 110 also includes a memory 317 for storing program code and data 305 and hardware logic 301 such as a microcontroller for executing the program code and processing the data. A wide area network (WAN) interface 302 and antenna 310 couple the IoT hub 110 to the cellular service 115) (column 5 line 61 to column 6 lines 58; see Figures 1 to 4a).
However, Zakaria et al. did not explicitly disclose the computing environment remote from the building.
In the same field of endeavor of an electronic lock system, Kjellsson et al. teach the computing environment (108) (i.e. a network server) remote from the building (i.e. a lock 106 of a building) (page 2 paragraph 0027; page 4 paragraph 0045; page 5 paragraph 0053; see Figures 1 and 4) in order to initiate a calibration event using a personal access device.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for having the network server communication between the personal access device remotely from the building and the lock for processing the calibration and setup of the lock remotely taught by Kjellsson et al. in system for implementing the calibration module of the wireless IoT lock of Zakaria because having the network server communication between the personal access device and the lock for processing the calibration would ensure the most efficient way to set up and calibrate the lock of a locking mechanism of the building.
Referring to claim 2, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 1, Zakaria et al. disclose further comprising: a base station (101) (i.e. IoT device) to send, to the lock (702), a command to initiate a calibration operation in response to receipt of an instruction from the computing environment (108) (i.e. The IoT devices 101-105 may be equipped with various types of sensors to collect information about themselves and their surroundings and provide the collected information to the IoT service 120, user devices 135 and/or external Websites 130 via the IoT hub 110. Some of the IoT devices 101-105 may perform a specified function in response to control commands sent through the IoT hub 110. Various specific examples of information collected by the IoT devices 101-105 and control commands are provided below. In one embodiment described below, the IoT device 101 is a user input device designed to record user selections and send the user selections to the IoT service 120 and/or Website) (column 3 lines 20 to 32; see Figures 1 to 4a).
Referring to claim 3, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 2, Zakaria et al. disclose wherein:
the request further includes an identifier of the lock (a secure identifier) (i.e. once the SIM 1501 is programmed, the new IoT device 101 may be provisioned with the IoT Service 120 using the SIM as a secure identifier (e.g., using existing techniques for registering a device using a SIM). Following provisioning, both the IoT hub 110 and the IoT service 120 will securely store a copy of the IoT device's public key to be used when encrypting communication with the IoT device 101) (column 19 lines 27 to 55);
the computing environment (110) is sends the identifier (i.e. the secure identifier) to the base station (101); and the base station (101) identifies the lock based on the identifier (i.e. At 1901, the IoT service encrypts the data/commands using the IoT device public key to create an IoT device packet. It then encrypts the IoT device packet using IoT hub's public key to create the IoT hub packet (e.g., creating an IoT hub wrapper around the IoT device packet). At 1902, the IoT service transmits the IoT hub packet to the IoT hub. At 1903, the IoT hub decrypts the IoT hub packet using the IoT hub's private key to generate the IoT device packet. At 1904 it then transmits the IoT device packet to the IoT device which, at 1905, decrypts the IoT device packet using the IoT device private key to generate the data/commands. At 1906, the IoT device processes the data/commands) (column 19 line 55 to column 22 line 41; see Figures 15 to 19).
Referring to claim 4, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 2, Zakaria et al. disclose wherein the base station (101) is remote from the lock (430) (column 12 line 35 to column 13 line 18; see Figures 4A and 9).
Referring to claim 5, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 4, Zakaria et al. disclose wherein the base station (101/710) is located within the building (column 12 lines 35 to 42; see Figure 7).
Referring to claim 6, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 5, Zakaria et al. disclose wherein:
the application is configured to send another request to lock or unlock the lock in
response to another input received via the user interface (i.e. to operate these systems, the user must open an app on the mobile device and select an open/unlock or close/lock option. In response, a wireless signal is sent to a receiver on or coupled to the wireless lock or garage door which implements the desired operation) (column 11 lines 16 to 26);
the computing environment is configured to send another instruction to lock or unlock the lock in response to receipt of the another request from the application; and
the base station is configured to initiate locking or unlocking of the lock in response to receipt of the another instruction from the computing environment (i.e. one or more other/alternate I/O devices or sensors 250 may be included on the IoT device 101 based on the particular application for which the IoT device 101 is designed. For example, an environmental sensor may be included to measure temperature, pressure, humidity, etc. A security sensor and/or door lock opener may be included if the IoT device is used as a security device) (column 5 lines 40 to 46; see Figures 1b and 7-9) and (i.e. a calibration module 910 on the IoT hub 710 communicates with an app or browser-based code on the wireless device 703 to calibrate the signal strength measurements. During calibration, the system calibration module 910 and/or calibration app may instruct the user to stand in certain locations outside the door and inside the door (e.g., outside 6 ft outside door 1, 6 ft inside door 1, 6 ft outside door 2, etc). The user may indicate that he/she is in the desired position by selecting a graphic on the user interface. The system calibration app and/or system calibration module 910 will then associate the collected signal strength values 900 with each location within a location database 901 on the IoT hub/device 710) (column 12 lines 35 to 49; see Figures 1b and 9).
Referring to claim 7, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 6, Zakaria et al. disclose wherein the base station is further configured to send another
command to the lock to initiate the locking or unlocking of the lock (i.e. The signal strength values 760-761, 750-751 may be evaluated at the IoT hub/device 710 or at the IoT lock 702 (if it has the intelligence to perform this evaluation). The remainder of this discussion will assume that the signal strength evaluation is performed by an IoT hub 710, which may then transmit a lock or unlock command (or no command if already locked/unlocked) to the IoT lock 702 over a wireless communication channel 770 (e.g., BTLE) based on the results of the evaluation. It should be noted, however that the same basic evaluation and result may be performed directly by the IoT lock 702 if it is configured with the logic to perform the evaluation (e.g., where the signal strength values are provided to the IoT lock 702)) (column 12 lines 4 to 16; see Figure 7).
Referring to claim 8, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 2, Zakaria et al. disclose wherein: the application is further configured to send the request to the computing environment via a wide area network (i.e. a wide area network (WAN) interface 302 and antenna 310 couple the IoT hub 110 to the cellular service 115. Alternatively, as mentioned above, the IoT hub 110 may also include a local network interface (not shown) such as a WiFi interface (and WiFi antenna) or Ethernet interface for establishing a local area network communication channel) (column 6 lines 16 to 29; see Figure 3); and
the computing environment is further configured to send instructions to the base station via the wide area network (i.e. a calibration module 910 on the IoT hub 710 communicates with an app or browser-based code on the wireless device 703 to calibrate the signal strength measurements. During calibration, the system calibration module 910 and/or calibration app may instruct the user to stand in certain locations outside the door and inside the door (e.g., outside 6 ft outside door 1, 6 ft inside door 1, 6 ft outside door 2, etc). The user may indicate that he/she is in the desired position by selecting a graphic on the user interface. The system calibration app and/or system calibration module 910 will then associate the collected signal strength values 900 with each location within a location database 901 on the IoT hub/device 710) (column 12 lines 35 to 49; see Figures 1b and 9).
Referring to claim 11, Zakaria et al. in view of Kjellsson et al. and Yoshida disclose the system of claim 1, Zakaria et al. disclose wherein the computing environment is configured to: receive a confirmation of calibration of the lock; and in response to receiving the confirmation, send a notification to the application, the notification causing a verification prompt to appear on the user interface of mobile user device (i.e. one embodiment of the IoT hub 110 and/or IoT service 120 transmits notifications to the end user related to the current status of each piece of electronics equipment. The notifications, which may be text messages and/or app-specific notifications, may then be displayed on the display of the user's mobile device 135. For example, if the user's air conditioner has been on for an extended period of time but the temperature has not changed, the IoT hub 110 and/or IoT service 120 may send the user a notification that the air conditioner is not functioning properly) (column 9 lines 46 to 63; see Figures 4A and 5).
Referring to claim 12, Zakaria et al. in view of Kjellsson et al. and Yoshida disclose the system of claim 1, Zakaria et al. disclose wherein the application is configured to initiate locking or unlocking the lock in response to another input received via the user interface (i.e. current wireless “smart” locks and garage door openers allow an end user to control a lock and/or garage door via a mobile device. To operate these systems, the user must open an app on the mobile device and select an open/unlock or close/lock option. In response, a wireless signal is sent to a receiver on or coupled to the wireless lock or garage door which implements the desired operation) (column 11 lines 16 to 26).
Referring to claims 13-18 and 20, Zakaria et al. in view of Kjellsson et al. disclose a method, although different in scope from the claims 1, 3 and 11-12, the claims 13-18 and 20 contains similar limitations in that the claims 1, 3 and 11-12 already addressed above therefore claims 13-18 and 20 are also rejected for the same obvious reasons given with respect to claims 1, 3 and 11-12.
Referring to claim 19, Zakaria et al. in view of Kjellsson et al. disclose a method, the claim 19 differ from claim 1 is that the claims require the additional limitations of claims 2-3 and 11 already addressed above and Zakaria et al. in view of Kjellsson et al. disclose all limitations to the extent as claimed with respect to claim 2-3 and 11 above and therefore claim 19 is also rejected as being obvious for the same reasons given with respect to claims 2-3 and 11.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Zakaria (US# 9,704,318) in view of Kjellsson et al. (Pub. No. US 2016/0353239) as applied to claim 1 and in view of Yoshida (US# 10,162,576).
Referring to claim 9, Zakaria et al. in view of Kjellsson et al. disclose the system of claim 1, however, Zakaria et al. in view of Kjellsson et al. did not explicitly disclose wherein the computing environment determines a timing for calibration of the lock based on a schedule and, in response, cause a prompt to be presented on a display of the mobile device.
In an analogous art, Yoshida teaches wherein the computing environment determines a timing for calibration of the lock based on a schedule and, in response, cause a prompt to be presented on a display of the mobile device (i.e. a job scheduling window on a display unit or a graphical user interface 104 of an exemplary job management apparatus, which can be hosted, for example, on a server 120, and/or a printer 130, 132, 134 (an exemplary device), and for use with the system as shown in FIG. 1 in accordance with a first exemplary embodiment. In accordance with an exemplary embodiment, for example, the job scheduling window can be hosted on the server 120 and/or the at least one printer 130, 132, 134 via a communication network 140, 142. As shown in FIG. 7, the server 120 and/or the printer 130, 132, 134 has a job scheduling GUI (graphical user interface) 104, 204, 304. In accordance with an exemplary embodiment, the job management program, for example, hosted on the server 120, provides the job scheduling GUI 104, 204, 304, which shows the job schedule, the validation and calibration process schedule, and color reproduction information of each printer 130, 132, 134. The operator can assign a job to a proper printer 130, 132, 134 by seeing the job scheduling GUI 104, 204, 304) (see Figure 7) in order to ensure the most efficient working order of the electronic device.
At the time of the effective filing date of the current application, it would have been obvious to a person of ordinary skill in the art to recognize the need for having a calibration process schedule on the job scheduling graphical user interface (GUI) for the operator can assign the job to proper printer by seeing the job scheduling GUI from the server taught by Yoshida in system for implementing the calibration module of the wireless IoT lock of Zakaria in view of Kjellsson et al. because the operator can assign the job to proper printer by seeing the job scheduling GUI from the server would ensure the most efficient maintenance of the wireless IoT lock.
Referring to claim 10, Zakaria et al. in view of Kjellsson et al. and Yoshida disclose the system of claim 9, Zakaria et al. disclose wherein the user interface receives the input in response to the prompt (i.e. Regardless of how the IoT hubs 110-111 are connected, in one embodiment, the IoT service 120 will logically associate the hubs with the user and combine all of the attached IoT devices 101-105 under a single comprehensive user interface, accessible via a user device with the installed app 135 (and/or a browser-based interface)) (column 4 lines 24to 29; see Figure 1B).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Regarding claims 1-20, although the claims at issue are not identical, they are not patentably distinct from each other because the patent claims include all of the limitations of the instant application claims, respectively. The patent claims also include additional limitations. Hence, the instant application claims are generic to the species of invention covered by the respective patent claims. As such, the instant application claims are anticipated by the patent claims and are therefore not patentably distinct therefrom. (See Eli Lilly and Co. v. Barr Laboratories Inc., 58 USPQ2D 1869, "a later genus claim limitation is anticipated by, and therefore not patentably distinct from, an earlier species claim", In re Goodman, 29 USPQ2d 2010, "Thus, the generic invention is ‘anticipated’ by the species of the patented invention" and the instant “application claims are generic to species of invention covered by the patent claim, and since without terminal disclaimer, extant species claims preclude issuance of generic application claims”).
Regarding claim 1, it is noted that although the conflicting claims are not identical, they are not patentably distinct from each other because claim 1 of the instant application is broader than the claim 1 of U.S. Patent No. 12,333,879. In this case, it is noted that the instant claim is identical to the claim of U.S. Patent No. 12,333,879 except without the limitation "wherein the computing environment is configured to: receive a confirmation of calibration of the lock from the base station; in response to receiving the confirmation, send a notification to the application, the notification causing a verification prompt to appear on the user interface of the user device; receive an indication of incomplete calibration from the application; and cause the base station to reinitiate the calibration of the lock."
The following claims are not identical, but at least one examined application claim is
anticipated by, or would have been obvious over, the reference claims:
Instant Application U.S. Patent No. 12,333,879
1 1
13 10
19 15
20 1
Referring to claims 2-12 and 14-18 are rejected as being dependent upon a rejected Claims 1 and 13 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to the enclosed PTO-892 for details.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAM V NGUYEN whose telephone number is 571-272-3061. The examiner can normally be reached on 8:00AM-5:00PM M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Quan-Zhen Wang can be reached on 571-272-3114. The fax phone numbers for the organization where this application or proceeding is assigned are 571-273-8300 for regular communications.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/NAM V NGUYEN/
Primary Examiner, Art Unit 2685
Prosecution Insights