DETAILED ACTION
Claims 1-12 and 14-21 rejected under 35 USC § 101.
Claims 1-12 and 14-21 rejected under 35 USC § 103.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-12 and 14-21 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 8, and 12
[Step 1] Claims 1, 8, and 12 recite a method, system, and/or medium for performing a process comprising steps of (1) detecting a mobile device entry geographical triggering event and (2) generating a preparation request in response to the triggering event.
[Step 2A – Prong One] The process recited in claims 1, 8, and 12 are directed to an abstract idea. The recited limitations (1) and (2) are a process that, under its broadest reasonable interpretation, covers mental processes including "observations, evaluations, judgments, and opinions" that "can be performed in the human mind, or by a human using a pen and paper" MPEP 2106.04(a)(III). The step of (1) is accomplished by a human visually detecting a mobile device, i.e. geographically within their vision, and the step of (2) is accomplished by a human writing down a preparation request. The claim does not require that the request be received or processed. The request is “to run serverless functions,” but the method does not actually run any serverless functions. The request is “to be provided” to a control system, but the method does not actually provide it or run a command based on it. The scope of the method is merely generating the request— accordingly, the scope encompasses mental processes of manually writing a request on pen and paper when a human visually perceives a mobile device.
[Step 2A – Prong Two] Claims 1, 8, and 12 do not recite additional elements that integrate the judicial exception into a practical application. The additional elements recited include computer hardware (e.g. processor and memory); these additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d). Further, the claim limitations attempt to cover any solution for generating a preparation request, without providing a particular solution or way to achieve a desired outcome. See MPEP 2106.05(f)(1).
[Step 2B] Claims 1, 8, and 12 do not recite a combination of elements that amount to significantly more than the judicial exception itself. The broadest reasonable interpretation of the process comprising limitations (1) and (2) is a mental process. The additional elements recited are merely instructions to implement the mental process on a computer. Accordingly, these limitations are not enough to qualify as "significantly more" when recited with a judicial exception (i.e. the mental process). MPEP 2106.05(A). Further, these claim limitations fail to improve the functioning of the computer itself, because "a claim whose entire scope can be performed mentally, cannot be said to improve computer technology." See MPEP 2106.05(a)(I).
Claims 2-5, 7, 9-12, 14-15, and 20-21
These dependent claims merely further define the parameters and/or intended use of the request. The request is “to be provided to a control system,” “for making elevator calls,” wherein the API is a “lighting system related API,” and wherein the request is “a request to run the serverless functions … during a predefined time.” The claims do not require any computation to derive these parameters or intended uses. These steps are recited without any functions specific to computer technology, thus the broadest reasonable interpretation of the step includes the mental process of a human writing any arbitrary preparation request for these intended uses with pen and paper.
Claims 6 and 16-19
A “usage pattern based triggering event” may be determined mentally by a human user. Humans can arbitrarily observe behavior, determine usage patterns, and predict future behavior. A human can mentally predict an upcoming geographical triggering event (e.g., John usually comes back to the office at noon), and could write a preparation request in response to the prediction based on usage patterns. These steps are recited without any functions specific to computer technology, thus the broadest reasonable interpretation of the step includes the mental process of a human writing any arbitrary preparation request based on mental usage pattern prediction with pen and paper.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6, 8-12, 14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson, II et al., U.S. PG-Publication No. 2019/0028552 A1 (hereinafter JOHNSON), in view of Koivisto et al., U.S. PG-Publication No. 2018/0208430 A1 (hereinafter KOIVISTO), further in view of Chapman et al., U.S. PG-Publication No. 2017/0349402 A1 (hereinafter CHAPMAN).
Claim 1
JOHNSON discloses a method for preparing a[n] … application programming interface (API) for operation. ¶ 0105: API 604 provides an interface for interacting with the function router and repository “in order to manage and access functions and function routing data.” ¶ 0106: API 604 may include an API service for “creating, publishing, maintaining, monitoring, securing, and/or managing APIs,” such as AMAZON API GATEWAY. ¶ 0142: The runtime “loads the specific function code and prepares it for execution,” “creates the API endpoint or interface for the function,” and returns the API endpoint for the “now-ready function.”
JOHNSON discloses generating, by [a] mobile user device, to the … API … a preparation request to run serverless functions in the … API. ¶ 0041: Client endpoints communicating with the cloud may include “a smartphone,” GPS device, smart wearable, smart-lighting system, smart home, or smart building. ¶ 0110: The same APIs are “used by a client to interact with the function router.” ¶ 0168: For clients “flagged as mobile,” location may be “passed when the client makes a request to the function router.” ¶ 0036: The function-delivery network receives job requests for “FaaS and serverless applications” and routes them to execution environments to “increase performance and decrease latency.” ¶ 0109: The functions, code, API 604, repository, and database may be deployed and configured using the SERVERLESS.COM framework. ¶ 0142: In response to the original client request, the router causes the runtime to fetch the function code, load it, “prepare[] it for execution,” and return the endpoint for the “now-ready function.” ¶ 0143: The router responds to the “original client request” with the prepared API endpoint address; the client then calls the function API “for future requests to execute that function.”
JOHNSON does not expressly disclose that the prepared API is a building system related application programming interface (API); detecting, by a mobile user device, a geographical triggering event representing an entry of the mobile user device into a predefined area; and generating, in response to detecting the geographical triggering event a preparation request to run serverless functions in the building related API.
KOIVISTO discloses a building system related API. ¶ 0004: A mobile device sends service requests to an elevator system through an API manager that provides “a common programming interface for all elevator related applications.” ¶ 0016: The API provides “a programmable interface for the mobile application” so that it may “send a command or a request to the elevator system.” ¶ 0019: The “mobile device 100 sends a request to the cloud 110 through an API provided at the cloud 113,” after which the cloud transmits the verified request to the building control system.
KOIVISTO discloses generating, by a mobile user device, to the building system related API … a … request … in the building system related API. ¶ 0017: The mobile application accesses resources through API 107, and its commands and requests must conform to that API; the API manager then communicates with the cloud. ¶ 0021: The mobile application accesses the API manager through the API; the elevator call is sent to the cloud and ultimately transmitted to the destination elevator system.
KOIVISTO discloses the generating is in response to detecting [a] geographical triggering event. ¶ 0015: “When the person arrives at the building or vicinity of the building,” the mobile application approximates the distance and estimated arrival time and sends information to the elevator system.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the serverless API-preparation method of JOHNSON to incorporate the mobile-to-cloud building elevator API taught by KOIVISTO. One of ordinary skill in the art would be motivated to integrate the mobile-to-cloud building elevator API into JOHNSON, with a reasonable expectation of success, in order to provide a common programming interface through which elevator-related mobile applications may transmit trusted service requests to an elevator system, as taught by KOIVISTO ¶ 0004.
JOHNSON-KOIVISTO does not expressly disclose detecting, by a mobile user device, a geographical triggering event representing an entry of the mobile user device into a predefined area.
CHAPMAN discloses detecting, by a mobile user device, a geographical triggering event representing an entry of the mobile user device into a predefined area. ¶ 0028: Each geofence is a virtual parameter around a geographic location or “a predefined set of boundaries,” including a radius around an elevator, lobby, elevator bank or property. Detection may use GPS, RFID, NFC, proximity systems, or BLE beacons. ¶ 0029: When a user device “enters or exits” one of the geofences, the intelligent building system and/or user device “reactively perform operations.” ¶ 0030: GPS-enabled mobile devices may themselves “detect[] and process[] broadcasted signals” from the elevator subsystem or geofence environment. ¶ 0035: A geofence beacon signal is “detected and processed” by the mobile device, and the device “then issue[s] commands to the elevator sub-system.”
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the mobile building-API and serverless-preparation method of JOHNSON-KOIVISTO, with a reasonable expectation of success, in order to arrange elevator service in advance so that the elevator is waiting when the user arrives, thereby avoiding delay caused by waiting for the elevator, as taught by CHAPMAN, ¶ 0031.
Claim 2
JOHNSON discloses further comprising generating, by the mobile user device or at least one second mobile user device, at least one control request to the … API. ¶ 0041: Client endpoints communicating with the cloud may include a “smartphone,” GPS device, or smart wearable. ¶ 0143: After the original preparation request makes the function/API ready, “the client calls the specific function API of the execution endpoint for future requests to execute that function.” ¶ 0260: The client may continue invoking the function at the selected endpoint in “future function execution requests” until the function or endpoint becomes unavailable or an expiration period lapses.
JOHNSON does not expressly disclose a building system related API to be provided to a control system.
KOIVISTO discloses a building system related API to be provided to a control system. ¶ 0016: The mobile API provides a programmable interface so the mobile application may “send a command or a request to the elevator system.” ¶ 0019: The mobile device sends a request through cloud API 113; after processing, “the cloud transmits the request to the building,” where elevator control system 113 receives or checks it. ¶ 0021: The mobile application sends an elevator call through the API to the cloud; the cloud then “transmits the call to the destination elevator system,” which may process or execute the call.
Claim 3
KOIVISTO discloses wherein the building system related API is an elevator call API used for making elevator calls. ¶ 0004: The API manager provides “a common programming interface for all elevator related applications” executing on the mobile device and permits those applications to send service requests to the elevator system. ¶ 0016: The API provides a programmable interface through which the mobile application may “send a command or a request to the elevator system.” ¶ 0021: The mobile application places “an elevator call,” accesses the API manager “through the API,” and sends the elevator call through the cloud to the destination elevator system.
Claim 4
KOIVISTO discloses further comprising generating, by the mobile user device or at least one second mobile user device, an elevator call request to the elevator call API. ¶ 0015: Mobile device 100 sends commands to the building’s elevator system; a person arriving at the building may “send an elevator call in advance.” ¶ 0016: The mobile API supplies a programmable interface through which the mobile application sends “a command or a request to the elevator system.” ¶ 0021: The mobile application places “an elevator call” and “access[es] the API-manager through the API”; the call is then sent to the elevator cloud.
KOIVISTO discloses the request to be provided to an elevator control system for generating an elevator call. ¶ 0019: The mobile device sends the request through cloud API 113; the cloud transmits the request to the building, where elevator control system 114 receives or checks it. ¶ 0021: The cloud “transmits the call to the destination elevator system,” which may “execute the call directly after receiving the call.”
Claim 6
CHAPMAN discloses wherein the detected geographical triggering event is a geofencing based triggering event, a Bluetooth beacon based triggering event, wireless access point based triggering event, an access control based triggering event, or a usage pattern based triggering event. ¶ 0028: A geo-fence is a “virtual perimeter” dynamically generated around a geographic location or established using “a predefined set of boundaries.” Geo-fences may be detected and monitored using GPS, RFID, NFC, proximity systems, or BLE beacons. ¶ 0029: When a user device “enters of exits” any of the geo-fences, the intelligent building system and/or user device may “reactively perform operations.” ¶ 0031: When GPS detects that a mobile device has “crossed the geo-fence 112 by moving from position A to position B,” the elevator subsystem may automatically initiate an elevator call. ¶ 0035: Beacons broadcast a signal that is “detected and processed” by the user device, after which the user device issues commands to the elevator subsystem. ¶ 0040: The proximity system may use beacons employing “Bluetooth low energy (BLE) technology to detect the presence of a user device and interact with the user device.”
Claim 8
Claim 8 is rejected utilizing the rationale for Claim 1; the claim is directed to a system performing the method.
Claim 9
CHAPMAN discloses further comprising at least one second mobile user device. ¶ 0029: The intelligent building system includes “a plurality of user devices 122, 124, 126” with each device depicted at different positions in the building system. ¶ 0032: The intelligent building system may “detect when multiple users entered the geo-fence environment” and use the associated devices and source floors to coordinate elevator service. ¶ 0048. Applications localized on user devices 122, 124, and 126 are launched and initialized when those devices are within the geo-fence environment.
Claim 10
KOIVISTO discloses wherein the at least one … mobile user device is configured to generate at least one control request to the building system related API to be provided to the control system. ¶ 0016: The API and API manager provide a programmable interface through which a mobile application “may send a command or a request to the elevator system.” ¶ 0019: The mobile device “sends a request to the cloud 110 through an API provided at the cloud 113.” After processing, the cloud transmits the request to the building, where control system 114 handles or executes it. ¶ 0001: It is “normal that one person owns and uses more than one device,” and those devices execute applications capable of sending instructions to external systems that control other devices.
KOIVISTO does not expressly disclose wherein the at least one second mobile user device is configured to generate at least one control request.
CHAPMAN discloses wherein the at least one second mobile user device is configured to generate at least one control request. ¶ 0030: One or more of the “plurality of user devices 122, 124, 126” may detect and process signals and “issue commands to the elevator sub-system.” ¶ 0035: Beacons broadcast signals that are detected and processed by “one or more of the plurality of user devices 122, 124, 126.” Those devices then “issue commands to the elevator sub-system.”
Claim 11
Claim 11 is rejected utilizing the rationale for Claims 3+4; the claim is directed to a system performing the method.
Claim 12
Claim 12 is rejected utilizing the rationale for Claim 1; the claim is directed to a medium storing instructions corresponding to the method.
Claim 14
Claim 14 is rejected utilizing the rationale for Claims 2+3; the claim is directed to a combination of previously recited dependent claims.
Claim 16
Claim 16 is rejected utilizing the rationale for Claims 2+6; the claim is directed to a combination of previously recited dependent claims.
Claim 17
Claim 17 is rejected utilizing the rationale for Claims 3+6; the claim is directed to a combination of previously recited dependent claims.
Claim 18
Claim 18 is rejected utilizing the rationale for Claims 4+6; the claim is directed to a combination of previously recited dependent claims.
Claims 5, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over JOHNSON, in view of KOIVISTO, further in view of CHAPMAN, further in view of Alexander, U.S. Patent No. 11,188,376 B1 (hereinafter ALEXANDER).
Claim 5
ALEXANDER discloses wherein the building system related API is a lighting system related API, a heating, ventilation, and air conditioning (HVAC) system API, a building management system (BMS) API, or an infotainment system API. col.1, ll. 10-24: Smart thermostats remotely communicate with a web server, allowing an end user to receive current thermostat data and “control the thermostat through a companion application” on a mobile device or through a web application. col. 12, ll. 21-31: A “RESTful application programming interface (API)” exposes commands used to deploy and configure virtual machines. col. 13 ll.3-16: Serverless environments execute short-lived code, including AWS Lambdas, with virtual machines launched “on demand, in response to some triggering event.” col. 13, ll.34-42: The smart devices may include “a smart thermostat” and “a smart lighting system,” with each device associated with its own virtual machine “to perform various tasks related to the device.” col. 17, ll.49-67; col.18, ll.1-10: A smart thermostat sends an MQTT message containing current temperature data. The ingress controller uses a URI to identify the appropriate application, sends the request to a Lambda orchestrator, and launches a virtual machine executing “a Lambda to process temperature data.”
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the serverless building-system API of JOHNSON-KOIVISTO-CHAPMAN to incorporate the smart-thermostat temperature processing service taught by ALEXANDER. One of ordinary skill in the art would be motivated to integrate ALEXANER’s smart-thermostat service into JOHNSON-KOIVISTO-CHAPMAN, with a reasonable expectation of success, in order to eliminate the need for an application developer to provide initialization and watchdog services or otherwise manage the lifecycle of the thermostat-processing service, while enabling the computing system to launch the appropriate service automatically in response to an incoming workload, a benefit expressly identified by ALEXANDER (col. 18, ll.11-23).
Claim 15
Claim 15 is rejected utilizing the rationale for Claims 2+5; the claim is directed to a combination of previously recited dependent claims.
Claim 19
Claim 19 is rejected utilizing the rationale for Claims 5+6; the claim is directed to a combination of previously recited dependent claims.
Claims 7, 20, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over JOHNSON, in view of KOIVISTO, further in view of CHAPMAN, further in view of Zhang et al., U.S. PG-Publication No. 2019/0075154 A1 (hereinafter ZHANG).
Claim 7
ZHANG discloses wherein the preparation request comprises a request to run the serverless functions in the building system related API during a predefined time.¶ 0087: The function-execution engine implements an API containing “a call to request the instantiation of a cloud function.” Instantiation allocates a container, loads the function image, and places the function in a state ready for execution.” ¶ 0088: The management API includes a function that may “set the maximum hold time” and thereby adjust “the length of time that a particular cloud function remains instantiated.” ¶ 0079: A maximum hold time determines when the execution engine frees the resources of a previously instantiated function. The relevant interval is measured from “receiving the request to instantiate the cloud function,” and the resources are freed when that interval exceeds the maximum hold time. ¶ 0099: A hold time for maintaining the cloud-hosted-function instantiation is determined, including by a predefined function that calculates and outputs the hold time. ¶¶ 0100-0102: After instantiation, the function is maintained for the determined hold time; when the hold time elapses without execution, the instantiation may be removed.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the preparation request of the serverless building system API of JOHNSON-KOIVISTO-CHAPMAN to incorporate the maximum hold time control taught by ZHANG. One of ordinary skill in the art would be motivated to integrate ZHANG’s maximum hold time control into JOHNSON-KOIVISTO-CHAPMAN, with a reasonable expectation of success, in order to retain the latency reduction obtained by maintaining an instantiated function in anticipation of a later execution request while preventing computing resources from being tied up indefinitely by functions that are never invoked, as taught by ZHANG (¶¶ 0030, 0079).
Claim 20
Claim 20 is rejected utilizing the rationale for Claims 2+7; the claim is directed to a combination of previously recited dependent claims.
Claim 21
Claim 21 is rejected utilizing the rationale for Claims 3+7; the claim is directed to a combination of previously recited dependent claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Khanna et al., U.S. PG-Publication No. 2022/0166670 A1; KHANNA discloses predicting serverless requests from historical usage patterns and prewarming containers based on the predicted request time, workload, runtime and execution duration. The system determines a warm interval or grace period during which the serverless runtime remains active, thereby reducing cold-start delay while avoiding unnecessary resource use (¶¶ 0013, 0015, 0029, 0032).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 9-5:30 CT.
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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 August 11, 2026
Prosecution Insights