DETAILED ACTION
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 .
Response to Amendment
Applicant submitted amendments and remarks on January 28, 2026. Therein, Applicant submitted substantive arguments. No claims were amended, added, or cancelled.
The submitted claims are considered below.
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.
Claims 1-10 are rejected under 35 U.S.C. 103 as being unpatentable over Way, et al. (U.S. Patent Application Publication No. 20190110174) in view of Groves, JR. (U.S. Patent Application Publication No. 20140079057) and further in view of Levy, et al. (U.S. Patent Application Publication No. 20160140851).
Regarding claim 1, Way et al. teaches: A computer-implemented method, the method comprising: obtaining, by a computing system comprising one or more computing devices, (Abstract: "obtaining, by a computing system [obtaining, by a computing system] comprising one or more computing devices")
a communication associated with an aircraft via an endpoint of a plurality of endpoints communicatively connected to a vehicle integration interface, (vehicle operations system interface (300), Abstract: "…computer-implemented method for facilitating communication from and to a vehicle [communication]" ; Paragraph [0032]: "…Vehicle API platform […] service provider's system […] communication protocols and connecting to the same endpoints [connected endpoints]" ; Paragraph [0039]: "…air-based autonomous vehicle (e.g., airplane, drone, helicopter, or other aircraft) [aircraft]" ; Paragraph [0076]: "vehicle-operations system interface (300) can include a Vehicle API (304) [vehicle integration interface].")
wherein the communication comprises received telemetry data comprising telemetry data for the aircraft formatted according to a device specific format; (Paragraph [0025]: "…live stream of telemetry data [telemetry data] " ; Paragraph [0029]: "…specific format of the outer envelope of a message with the data inside the message being formatted by the vehicle [device specific format]." ; Paragraph [0039]: "…air-based autonomous vehicle (e.g., airplane, drone, helicopter, or other aircraft) [aircraft]")
and the telemetry data for the aircraft is associated with a respective device type of a plurality of device types: (Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with device type of multiple device types].")
identifying, by the computing system, corresponding to the communication based, at least in part, on the respective device type, (Step (412), Paragraph [0074]: "…format [communication format]" ; Paragraph [0094]: "…computing system [computing system] […] relaying messages from one or more infrastructure endpoints (e.g., command/control messages, etc.) to the vehicle over the one or more channels [communication based on the endpoint]." ; Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with device type of multiple device types].")
generating, by the computing system, formatted telemetry data (Paragraph [0029]: "…Vehicle API platform [computing system] […] specific format [formatted]" ; Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with device type of multiple device types].")
wherein, the formatted telemetry data comprises the telemetry data for the aircraft formatted according to a different format than the device specific format; (Paragraph [0029]: "…For instance, the machine-learned model can allow for the Vehicle API platform to earn how to deal with different types of messages it is not used to seeing. As one example, in some implementations, the Vehicle API platform may be more open-ended and not require a vehicle to have an exact format for messages [formatted telemetry data in different format other than device specific format].")
and initiating, by the computing system, one or more vehicle actions for the aircraft based, at least in part, on the formatted telemetry data (Paragraph [0026]: "…assignment data to a vehicle, such as instructions for a vehicle to offload the data from its computing system [computing system], instructions for a vehicle to report for maintenance, instructions for a vehicle to procure fuel, […] sending emergency commands to a vehicle, for example, instructing the vehicle to immediately stop in an emergency or critical situation. […] sending specific control messages to a vehicle, for example, instructing the vehicle to go to certain coordinates [vehicle actions based on formatted telemetry data].").
Way, et al. does not teach the processes of identifying the device specific format, and based, at least in part, on the telemetry data and the identification of the device specific format associated with the respective device type.
In a similar field of endeavor (telemetry data routing), Groves, JR. teaches: the device specific format (Paragraph [0004]: "The duplication policy may comprise a number of receivers that are to receive the telemetry data (e.g., 8 receivers), one or more telemetry stream types utilized by respective receivers (e.g., respective receivers request telemetry streams formatted according to an sflow format and a syslog format), and/or a number of telemetry streams to create (e.g., 16 total telemetry streams-8 sflow and 8 syslog) [device specific format].")
based, at least in part, on the telemetry data and the identification of the device specific format associated with the respective device type (Paragraph [0022]: "At (208), for respective receivers, a field within the telemetry data is replaced with a receiver ID associated with a receiver to create modified telemetry data, at (210). At (212), a telemetry data stream for the receiver is created based upon the modified telemetry data. At (214), the telemetry data stream may be formatted according to a telemetry stream type, a destination IP address, and/or a destination port mapped to the receiver ID to create a formatted telemetry data stream. At (216), the formatted telemetry data stream is delivered to the receiver [based on telemetry data and identification of device of specific format associated with device type].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify Way, et al. to include the teaching of Groves, JR. based on a reasonable expectation of success and motivation to improve the development of a system to route telemetry data to receivers in-flight (Groves, JR. Paragraph [0003]).
The combination of Way, et al. and Groves, JR. does not teach wherein the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft.
In a similar field of endeavor (communication of aircraft navigation paths), Levy, et al. teaches: wherein the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft (Step (702), Paragraph [0165]: "The server [server - provides device type data] may dynamically select the safest flights paths from the current location of the drone [aircraft] to nearby safe landing locations, for example, when the drone is unable to land in the current zone the server may navigate the drone to nearby zone having a safe landing location. The safe emergency landing paths may be dynamically updated during flight of the drone. In such a manner, a safe contingency plan [contingency plan] may be available for the drone to follow across the flight path." ; Paragraph [0076]: "The infrastructure data may be obtained from an infrastructure database, for example, using a server that retries and/or saves infrastructure data (on the ground and/or in the air) in a local database. The infrastructure database may be updated periodically and/or based on input changes [retries based on contingency flight path for aircraft]." ; Step (202), Paragraph [0077]: "Policy rules, which may be specific to each national and municipal operator, relating infrastructure types to accepted risk levels. The policy rules may be obtained by a policy server (104) accessing, for example, an external authorization policy and rules server (104B), for example, a local server that retrieves and/or keeps track of policies that affect flight zones and/or routes from the remote server [retry policy associated with aircraft contingency flight plan from server].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify the combination of Way, et al. and Groves, JR. to include the teaching of Levy, et al. based on a reasonable expectation of success and motivation to improve the process of the communication of emergency flight guidance data to and from an unmanned aerial vehicle (Levy, et al. Paragraphs [0005] and [0017]).
Regarding claim 2, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 1, and in a further embodiment, teach: The computer-implemented method of the claim 1, further comprising: updating, by the computing system, a vehicle model corresponding to the aircraft based, at least in part, on the formatted telemetry data, (Way, et al. Paragraph [0050]: "…objects that are proximate to the autonomous vehicle (102) […] one or more sensors (104) and/or the map data (118). […] state data that describes a current state of such object. […] estimate of the object's: current location (also referred to as position); current speed; current heading (also referred to together as velocity); current acceleration; current orientation; size/footprint (e.g., as represented by a bounding shape such as a bounding polygon or polyhedron); class (e.g., vehicle versus pedestrian versus bicycle versus other); yaw rate; and/or other state information [vehicle model corresponding to aircraft]." ; Way, et al. Paragraph [0051]: "…perception system (110) […] update the state data for each object at each iteration [vehicle model updates]")
wherein the vehicle model comprises formatted vehicle data for the aircraft formatted according to the different format (Way, et al. Paragraph [0029]: "…Vehicle API platform can learn to be more intelligent about recognizing different types of data from a vehicle (e.g., the data generally looks like vehicle pose data, etc.) and determining how to handle the messages appropriately [vehicle model comprises formatted vehicle data for aircraft formatted by different format]." ; Groves, JR. Paragraph [0027]: "…different receivers may specify different formats of telemetry data (e.g., a first receiver may request telemetry data from a router (X) in an sflow format, while a second receiver may request telemetry data from router (X) in an sflow and netflow format, resulting in the creation of 2 sflow telemetry data streams and 1 netflow telemetry data stream) [vehicle model comprises formatted vehicle data for aircraft formatted by different format].").
Regarding claim 3, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 2, and in a further embodiment, teach: The computer-implemented method of the claim 2, wherein the vehicle model is indicative of a vehicle state for the aircraft, the vehicle state indicative of a location, an energy, a route, a health, or a configuration of the aircraft (Way, et al. Paragraph [0040]: “…to comprehend the surrounding environment by performing various processing techniques on data collected by the sensors (104), and generate an appropriate motion path through such surrounding environment [vehicle state -route].”).
Regarding claim 4, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 3, and in a further embodiment, teach: The computer-implemented method of the claim 3, wherein the telemetry data is indicative of a location update, a route update, a power update, a health update, or a configuration update for the aircraft (Way, et al. Paragraph [0051]: “…perception system (110) can determine state data for each object over a number of iterations. In particular, the perception system (110) can update the state data for each object at each iteration. […] proximate to the autonomous vehicle (102) [location update]”).
Regarding claim 5, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 4, and in a further embodiment, teach: The computer-implemented method of the claim 4, wherein the location update is indicative of a current location of the aircraft, (Way, et al. Paragraph [0048]: "…location (e.g., in three-dimensional space relative to the autonomous vehicle (102)) of points that correspond to objects within the surrounding environment of the autonomous vehicle (102) [current location of aircraft].")
and wherein updating the vehicle model comprises: updating, by the computing system, the location of the vehicle state based, at least in part, on the current location of the aircraft (Way, et al. Paragraph [0051]: "…perception system (110) can determine state data for each object over a number of iterations. In particular, the perception system (110) can update the state data for each object at each iteration [update vehicle state data]. […] proximate to the autonomous vehicle (102) [location of aircraft]").
Regarding claim 6, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 2, and in a further embodiment, teach: The computer-implemented method of the claim 2, wherein the communication is obtained from a computing device of a plurality of different computing devices, the computing device being associated with the aircraft (Way, et al. Paragraph [0035]: “…can be in communication with a large number of vehicles within a fleet simultaneously and can quickly aggregate data from multiple vehicles to provide for determining current conditions that may affect operation of vehicles within the fleet [communication is obtained from plurality of computing devices associated with aircraft].”)
wherein the device specific format is a data format used by the computing device associated with the aircraft, (Way, et al. Paragraph [0025]: "…Vehicle API platform [computing device] […] live stream of telemetry data [data]" ; Way, et al. Paragraph [0029]: "…specific format of the outer envelope of a message with the data inside the message being formatted by the vehicle [device specific format]." ; Way, et al. Paragraph [0039]: "…air-based autonomous vehicle (e.g., airplane, drone, helicopter, or other aircraft) [aircraft]")
wherein the different format corresponds to a data format used by a service entity associated with the plurality of different computing devices (Groves, JR. Paragraph [0017]: "…duplication policy may comprise a number of receivers that are to receive the telemetry data (e.g., the first receiver, the second receiver, etc.), one or more telemetry stream types utilized by respective receivers (e.g., the first receiver may request telemetry data streams formatted according to an sflow format, a syslog format, and a cflow format; the second receiver may request a telemetry data stream formatted according to an sflow format [data format - service entity associated with plurality of computing devices]").
Regarding claim 7, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 6, and in a further embodiment, teach: The computer-implemented method of the claim 6, wherein the device specific format is one of a plurality of different aerial device formats, (Way, et al. Paragraph [0025]: "…Vehicle API platform can provide for streaming real time data from a vehicle, for example, providing a live stream of telemetry data from a vehicle to an operations system to allow for providing assistance to the vehicle [computer implemented method]." ; Way, et al. Paragraph [0029]: "…specific format of the outer envelope of a message with the data inside the message being formatted by the vehicle [device specific format]."; Way, et al. Paragraph [0039]: "…air-based autonomous vehicle (e.g., airplane, drone, helicopter, or other aircraft) [device]" ; Groves, JR. Paragraph [0027]: "…9 telemetry data streams are to be created based upon 3 receivers requesting telemetry data according to an sflow format, a syslog format, and a netflow format (e.g., 3 sflow telemetry data streams, 3 syslog telemetry data streams, and 3 netflow telemetry data streams) [device specific format - example].")
and wherein each of the plurality of different computing devices are associated with a respective aerial device format of the plurality of different aerial device formats (Way, et al. Paragraph [0035]: "…the Vehicle API platform can be in communication with a large number of vehicles within a fleet simultaneously and can quickly aggregate data from multiple vehicles to provide for determining current conditions that may affect operation of vehicles within the fleet. The Vehicle API platform can inform one or more vehicles within the fleet based on the aggregated data and provide for quickly adapting to current conditions [plurality of computing devices]." ; Groves, JR. Paragraph [0017]: "…duplication policy may comprise a number of receivers that are to receive the telemetry data (e.g., the first receiver, the second receiver, etc.), one or more telemetry stream types utilized by respective receivers (e.g., the first receiver may request telemetry data streams formatted according to an sflow format, a syslog format, and a cflow format; the second receiver may request a telemetry data stream formatted according to an sflow format [plurality of different device formats]").
Regarding claim 8, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 6, and in a further embodiment, teach: The computer-implemented method of the claim 6, wherein the service entity is configured to communicate with the plurality of different computing devices to facilitate a multi-modal ride-sharing network (Way, et al. Paragraph [0059]: "…a fleet of vehicles, such as a fleet including one or more autonomous vehicles (102) [plurality of computing devices]. […] ride sharing application platform, delivery service application platform, courier service application platform, and/or other service application platform [multi-modal ride sharing network].").
Regarding claim 9, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 8, and in a further embodiment, teach: The computer-implemented method of the claim 8, wherein the vehicle model is one of a plurality of vehicle models, (Way, et al. Paragraph [0025]: "…what all the vehicles are in a fleet, who they belong to, what they are doing, providing a history for some time window into the behavior of a vehicle, providing moving snapshots of vehicle data over time, and/or the like, for example [one of plurality of vehicle models].")
and wherein each of the plurality of vehicle models correspond to a respective aircraft utilized to facilitate the multi-modal ride-sharing network (Way, et al. Paragraph [0059]: "…a fleet of vehicles, such as a fleet including one or more autonomous vehicles (102) [plurality of vehicle models]. […] ride sharing application platform, delivery service application platform, courier service application platform, and/or other service application platform [multi-modal ride sharing network].").
Regarding claim 10, Way, et al., Groves, JR., and Levy, et al. remain as applied to claim 9, and in a further embodiment, teach: The computer-implemented method of the claim 9, wherein the communication further comprises a received vehicle identifier, and wherein updating the vehicle model associated with the aircraft comprises: generating, by the computing system, a formatted vehicle identifier based, at least in part, on the received vehicle identifier and the device specific format; (Way, et al. Paragraph [0029]: "…specific format of the outer envelope of a message with the data inside the message being formatted by the vehicle [device specific format]." ; Way, et al. Paragraph [0082]: "…communicating authenticated vehicle messages (312) from the operations system (302) to the vehicle (102) (e.g., to a vehicle computing system, etc.) [computing system - received vehicle identifier].")
and identifying, by the computing system, the vehicle model from the plurality of vehicle models based, at least in part, on the formatted vehicle identifier (Way, et al. Paragraph [0085]: "…large amount of traffic, such as messages from a large number of vehicles, the Vehicle API (304) can understand the importance level of different messages and handle them appropriately, such as by classifying messages like requests for control/assistance [formatted vehicle identifier]").
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Way, et al. (U.S. Patent Application Publication No. 20190110174), Groves, JR. (U.S. Patent Application Publication No. 20140079057), and Levy, et al. (U.S. Patent Application Publication No. 20160140851) in view of Troy, et al. (U.S. Patent No. 7885732).
Regarding claim 11, while Way, et al., Groves, JR., and Levy, et al. teach the computer-implemented method of claim 1, they do not teach the process of determining, by the computing system, a data conversion function for the received telemetry data based, at least in part, on the device specific format and generating, by the computing system, the formatted telemetry data based, at least in part, on the data conversion function.
In a similar field of endeavor (haptics based teleoperation of vehicles), Troy, et al. teaches:
wherein generating the formatted telemetry data based, at least in part, on the telemetry data and the aerial vehicle device comprises determining, by the computing system, a data conversion function for the telemetry data based, at least in part, on the device specific format; (Col. 12, lines 28-43: "…are differentiated to get velocity and angular velocity (both of which may also be filtered to reduce noise) for each degree-of-freedom. Position, orientation, linear and angular velocity data is then converted into vehicle coordinates (by using 4.times.4 homogeneous transformation matrix multiplication) and used to calculate error signals, which are then multiplied by feedback gain values, and then used to generate the actuator control values for the actuators of the teleoperable device (110) [data conversion function]. […] converted into a format needed by the communication device (456) prior to transmission to the teleoperable device (110) by the converter (458) [based on device specific format].")
and generating, by the computing system, the formatted telemetry data based, at least in part, on the data conversion function (Method (300), Fig. 3, Col. 14, lines 38-46: "…converted to RC (remote control) signals, and the RC signals may be transmitted to the vehicle (410) [data conversion]. […] For teleoperation embodiments of this method, the measured position and derived velocity data [data conversion example]").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify the combination of Way, et al., Groves, JR., and Levy, et al. to include the teaching of Troy, et al. based on a reasonable expectation of success and motivation to improve the haptics-enabled teleoperation of remotely controlled air, water, and land-based vehicles (Troy, et al. Col. 1, lines 36-53).
Claims 12-14 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Way, et al. (U.S. Patent Application Publication No. 20190110174) in view of Groves, JR. (U.S. Patent Application Publication No. 20140079057), and further in view of Jiwani, et al. (U.S Patent Application Publication No. 20200166929), and further in view of Levy, et al. (U.S. Patent Application Publication No. 2016014085).
Regarding claim 12, Way, et al. teaches: One or more tangible, non-transitory computer-readable media storing computer- readable instructions that when executed by one or more processors cause the one or more processors to perform operations, the operations comprising: (Paragraph [0041]: "…one or more processors (130) [processors] […] non-transitory computer-readable storage mediums [non-transitory computer-readable instructions], […] executed by the processor (130) to cause vehicle computing system (106) to perform operations [perform operations].")
obtaining routing data for an aircraft associated with a computing device, wherein the routing data is formatted according to a device agnostic format corresponding to a service entity associated with the aircraft; (Paragraph [0017]: "…Vehicle API platform can be vehicle agnostic [device agnostic format], […] (e.g., fleet reporting, fleet management, fleet services/maintenance, remote vehicle assistance, routing, scheduling, etc.) [service entity associated with aircraft]")
the computing device is associated with a respective device type of a plurality of device types; (Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with respective device type of multiple device types].")
generating a routing request for the aircraft based, at least in part, on the respective device type of the computing device and the routing data, wherein: the routing request comprises the routing data formatted according to a device specific format corresponding to the computing device; (Paragraph [0029]: "…specific format of the outer envelope of a message with the data inside the message being formatted by the vehicle [routing data/device formatting]." ; Paragraph [0040]: "…autonomous vehicle (102) […] data collected by the sensors (104), and generate an appropriate motion path through such surrounding environment [routing request]." ; Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with device type of multiple device types].")
determining an endpoint corresponding to the computing device, based on the respective device type wherein the endpoint is one of a plurality of endpoints of a vehicle integration interface associated with the service entity, (Paragraph [0076]: "…vehicle-operations system interface (300) [vehicle integration interface] can include a Vehicle API (304) associated with an operations system (302)." ; Paragraph [0090]: "…computing system [computing device] […] infrastructure endpoints (e.g., clients) [endpoints] associated with the operations computing system."; Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with device type of multiple device types].")
and providing a routing request to a computing device associated with the aircraft (Paragraph [0053]: "…given information about the current locations of objects and/or predicted future locations of proximate objects, the motion planning system (114) can determine a motion plan for the autonomous vehicle (102) that best navigates the autonomous vehicle (102) relative to the objects at such locations [routing request]." ; Paragraph [0094]: "…Vehicle API [computing device] can provide for providing vehicle data to the one or more clients associated with an operations computing system in a secure manner that allows for expanded processing of vehicle data off the vehicle, analyzing such data in real time, and/or the like. In some implementations, the computing system can further provide for relaying messages from one or more infrastructure endpoints (e.g., command/control messages, etc.) to the vehicle [endpoints - aircraft] over the one or more channels.").
Way, et al. does not teach the processes of determining a specific endpoint, connecting with the plurality of endpoints, or providing a routing request using a specific endpoint.
In a similar field of endeavor (telemetry data routing), Groves, JR. teaches: determining a specific endpoint and connecting with the plurality of endpoints (Paragraph [0018]: “…receiver destination policy may comprise one or more entries used to format a telemetry data stream for delivery to a receiver. An entry may map a receiver ID of a receiver to a telemetry stream type (e.g., cflow, sflow, syslog, etc.), a destination IP address of the receiver, and/or a destination port of the receiver [specific endpoint]. […] delivery parameter specifying whether the telemetry data stream is to be delivered to multiple destinations [connecting with plurality of endpoints], etc.”)
providing a routing request using a specific endpoint (Paragraph [0005]: “…the receiver destination policy may comprise an entry mapping the first received ID to a telemetry stream type, a destination IP address, and/or a destination port. In this way, the first telemetry data stream may be formatted according to the entry for delivery to the first receiver [type of routing data sent via endpoint of vehicle integration database].”)
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective
filing date of the claimed invention to modify Way, et al. to include the teaching of Groves, JR. based on
a reasonable expectation of success and motivation to improve the development of a system to route telemetry data to receivers in-flight (Groves, JR. Paragraph [0003]).
The combination of Way, et al. and Groves, JR. does not teach and the routing data is formatted according one or more communication protocols; wherein the endpoint based on an identification of the respective device type, and at least one communication protocol of the one or more communication protocols.
In a similar field of endeavor (detection and communication of safety events), Jiwani, et al. teaches: and the routing data is formatted according one or more communication protocols; (Paragraph [0051]: "…communicates with the safety server (120) over the first communication network (126) by means of one or more channels including at least a voice channel, a data channel, a short messaging service (SMS) channel, or the like [data - communication protocols]."
and wherein the endpoint based on an identification of the respective device type, and at least one communication protocol of the one or more communication protocols (Paragraph [0051]: "…communicates with the safety server (120) over the first communication network (126) by means of one or more channels including at least a voice channel, a data channel, a short messaging service (SMS) channel, or the like [endpoint - communication protocols].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify the combination of Way, et al. and Groves, JR. to include the teaching of Jiwani, et al. based on a reasonable expectation of success and motivation to improve the process of detecting and communicating safety events by means of an unmanned aerial vehicle (UAV) (Jiwani, et al. Paragraph [0031]).
The combination of Way, et al., Groves, JR., and Jiwani, et al. does not teach the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft.
In a similar field of endeavor (communication of aircraft navigation paths), Levy, et al. teaches: the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft (Paragraph [0064]: "Control center (1108) [server - provides device type data] monitors and/or controls drones (1106) [aircraft] flying through a designated geographical airspace (1112), for example, urban and/or rural areas. Control center (1108) performs one or more of the following functions: [...] and/or provides each drone with a contingency plan [contingency plan] and/or emergency instructions (e.g., current emergency landing site)" ; Paragraph [0076]: "The infrastructure data may be obtained from an infrastructure database, for example, using a server that retries and/or saves infrastructure data (on the ground and/or in the air) in a local database. The infrastructure database may be updated periodically and/or based on input changes [retries based on contingency flight path for aircraft]." ; Paragraph [0077]: "Policy rules, which may be specific to each national and municipal operator, relating infrastructure types to accepted risk levels. The policy rules may be obtained by a policy server (104) accessing, for example, an external authorization policy and rules server (104B), for example, a local server that retrieves and/or keeps track of policies that affect flight zones and/or routes from the remote server [retry policy associated with aircraft contingency flight plan from server].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify the combination of Way, et al., Groves, JR., and Jiwani, et al. to include the teaching of Levy, et al. based on a reasonable expectation of success and motivation to improve the process of the communication of emergency flight guidance data to and from an unmanned aerial vehicle (Levy, et al. Paragraphs [0005] and [0017]).
Regarding claim 13, Way, et al., Groves, JR., Jiwani, et al., and Levy, et al. remain as applied to claim 12, and in a further embodiment, teach: The one or more tangible, non-transitory computer-readable media of claim 12, wherein the routing request comprises a request to change a current route of the aircraft (Way, et al. Paragraph [0054]: "…deviates from a preferred pathway (e.g., a preapproved pathway) [request to change route of aircraft].").
Regarding claim 14, Way, et al., Groves, JR., Jiwani, et al., and Levy, et al. remain as applied to claim 12, and in a further embodiment, teach: The one or more tangible, non-transitory computer-readable media of claim 12, wherein the routing request is at least one of one or more route request types, the one or more route request types comprising a route change type, a contingency route type, a time of arrival type, a procedure type, or a frequency type (Way, et al. Paragraph [0054]: "…candidate motion plans for the autonomous vehicle (102) based at least in part on the current locations and/or predicted future locations of the objects. For example, the cost function can describe a cost (e.g., over time) of adhering to a particular candidate motion plan [routing request types - route change type].").
Regarding claim 18, Way, et al. teaches: A computing system comprising: one or more processors; (Paragraph [0041]: “…one or more processors (130) [processors]”)
and one or more tangible, non-transitory, computer readable media that store instructions that when executed by the one or more processors cause the computing system to perform operations, the operations comprising: (Paragraph [0041]: “…non-transitory computer-readable storage mediums [non-transitory computer readable media], […] executed by the processor (130) to cause vehicle computing system (106) to perform operations.”)
obtaining routing data for an aircraft associated with a computing device, wherein the computing device is associated with a respective device type of a plurality of device types; (Paragraph [0055]: “…current locations and/or predicted future locations of objects, the motion planning system (114) can determine a cost of adhering to a particular candidate pathway. […] motion plan for the autonomous vehicle (102) [routing data for aircraft]”; Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with device type of multiple device types].")
generating a routing request for the aircraft based, at least in part, on the respective device type of the computing device and the routing data, (Paragraph [0029]: "…specific format of the outer envelope of a message with the data inside the message being formatted by the vehicle." ; Paragraph [0040]: "… autonomous vehicle (102) […] data collected by the sensors (104), and generate an appropriate motion path through such surrounding environment."; Paragraph [0019]: "…systems and methods of the present disclosure can provide a Vehicle API platform that can provide the ability for a service provider (e.g., an operations computing system) to communicate bidirectionally with any type of autonomous or compute - capable vehicle [telemetry data for aircraft is associated with device type of multiple device types].")
identifying a series of endpoints of a vehicle integration interface associated with a service entity (Paragraph [0076]: "As illustrated in FIG. 3, the vehicle-operations system interface (300) can include a Vehicle API (304) associated with an operations system (302)." ; Paragraph [0090]: "At (408), the computing system [computing device] can determine routing of the received vehicle data, for example, to route vehicle data to one or more infrastructure endpoints (e.g., clients) [endpoints] associated with the operations computing system. For example, in some implementations, the computing system can receive data from a vehicle over the one or more channels established between the Vehicle API and the vehicle and provide for different means of classifying the data, writing the data consistently on different messaging protocols, and providing a platform that can route data for other clients/applications in consistent ways.")
and providing a routing request to the computing device associated with the aircraft (Paragraph [0053]: "…given information about the current locations of objects and/or predicted future locations of proximate objects, the motion planning system (114) can determine a motion plan for the autonomous vehicle (102) that best navigates the autonomous vehicle (102) relative to the objects at such locations [routing request]." ; Paragraph [0094]: "…Vehicle API [computing device] can provide for providing vehicle data to the one or more clients associated with an operations computing system in a secure manner that allows for expanded processing of vehicle data off the vehicle, analyzing such data in real time, and/or the like. In some implementations, the computing system can further provide for relaying messages from one or more infrastructure endpoints (e.g., command/control messages, etc.) to the vehicle [endpoints - aircraft] over the one or more channels").
Way, et al. does not teach the processes of determining a specific endpoint, connecting with the plurality of endpoints, or providing a routing request using a specific endpoint.
In a similar field of endeavor (telemetry data routing), Groves, JR. teaches: determining a specific endpoint and connecting with the plurality of endpoints (Paragraph [0018]: "…the receiver destination policy may comprise one or more entries used to format a telemetry data stream for delivery to a receiver. An entry may map a receiver ID of a receiver to a telemetry stream type (e.g., cflow, sflow, syslog, etc.), a destination IP address of the receiver, and/or a destination port of the receiver [specific endpoint]. […] delivery parameter specifying whether the telemetry data stream is to be delivered to multiple destinations [connecting with plurality of endpoints], etc.").
providing a routing request using a specific endpoint (Paragraph [0005]: "…the receiver destination policy may comprise an entry mapping the first received ID to a telemetry stream type, a destination IP address, and/or a destination port. In this way, the first telemetry data stream may be formatted according to the entry for delivery to the first receiver [type of routing data sent via endpoint of vehicle integration database].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify Way, et al. to include the teaching of Groves, JR. based on a reasonable expectation of success and motivation to improve the development of a system to route telemetry data to receivers in-flight (Groves, JR. Paragraph [0003]).
The combination of Way, et al. and Groves, JR. does not teach wherein the routing request is formatted according to one or more communication protocols; and wherein the endpoint based on the identification of the respective device type, and at least one communication protocol of the one or more communication protocols.
In a similar field of endeavor (detection and communication of safety events), Jiwani, et al. teaches: wherein the routing request is formatted according to one or more communication protocols; (Paragraph [0051]: "…communicates with the safety server (120) over the first communication network (126) by means of one or more channels including at least a voice channel, a data channel, a short messaging service (SMS) channel, or the like [communication protocols].")
and wherein the endpoint based on the identification of the respective device type, and at least one communication protocol of the one or more communication protocols (Paragraph [0051]: "…communicates with the safety server (120) over the first communication network (126) by means of one or more channels including at least a voice channel, a data channel, a short messaging service (SMS) channel, or the like [endpoint - communication protocols].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify the combination of Way, et al. and Groves, JR. to include the teaching of Jiwani, et al. based on a reasonable expectation of success and motivation to improve the process of detecting and communicating safety events by means of an unmanned aerial vehicle (UAV) (Jiwani, et al. Paragraph [0031]).
The combination of Way, et al., Groves, JR., and Jiwani, et al. does not teach and wherein the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft.
In a similar field of endeavor (communication of aircraft navigation paths), Levy, et al. teaches: and wherein the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft (Paragraph [0064]: "Control center (1108) [server - provides device type data] monitors and/or controls drones (1106) [aircraft] flying through a designated geographical airspace (1112), for example, urban and/or rural areas. Control center (1108) performs one or more of the following functions: [...] and/or provides each drone with a contingency plan [contingency plan] and/or emergency instructions (e.g., current emergency landing site)" ; Paragraph [0076]: "The infrastructure data may be obtained from an infrastructure database, for example, using a server that retries and/or saves infrastructure data (on the ground and/or in the air) in a local database. The infrastructure database may be updated periodically and/or based on input changes [retries based on contingency flight path for aircraft]." ; Paragraph [0077]: "Policy rules, which may be specific to each national and municipal operator, relating infrastructure types to accepted risk levels. The policy rules may be obtained by a policy server (104) accessing, for example, an external authorization policy and rules server (104B), for example, a local server that retrieves and/or keeps track of policies that affect flight zones and/or routes from the remote server [retry policy associated with aircraft contingency flight plan from server].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify the combination of Way, et al., Groves, JR., and Jiwani, et al. to include the teaching of Levy, et al. based on a reasonable expectation of success and motivation to improve the process of the communication of emergency flight guidance data to and from an unmanned aerial vehicle (Levy, et al. Paragraphs [0005] and [0017]).
Regarding claim 19, Way, et al., Groves, JR., Jiwani, et al., and Levy, et al. remain as applied to claim 18, and in a further embodiment, teach: The computing system of claim 18, wherein generating the routing request comprises: obtaining a vehicle model corresponding to the aircraft, wherein the vehicle model comprises vehicle data for the aircraft in a device agnostic format; (Way, et al. Paragraph [0017]: "…Vehicle API platform can be vehicle agnostic [device agnostic format] […] (e.g., fleet reporting, fleet management, fleet services/maintenance, remote vehicle assistance, routing, scheduling, etc.) [vehicle data]")
and generating the routing request based, at least in part, on the vehicle model (Way, et al. Paragraph [0053]: "…determine a motion plan for the autonomous vehicle (102) […] one or more future locations for the object provided by the prediction system (112) and/or the state data for the object provided by the perception system (110) [routing request based on vehicle model].").
Regarding claim 20, Way, et al., Groves, JR., Jiwani, et al., and Levy, et al. remain as applied to claim 19, and in a further embodiment, teach: The computing system of claim 19, wherein the vehicle model is updated based, at least in part, on telemetry data received, via the endpoint of the vehicle integration interface, from the computing device (Way, et al. Paragraph [0051]: "…perception system (110) can determine state data for each object over a number of iterations. In particular, the perception system (110) can update the state data for each object at each iteration. […] proximate to the autonomous vehicle (102) over time [data updated]." ; Way, et al. Paragraph [0080]: "…communicating onboard data traffic (310) (e.g., telemetry, video, etc.) from the vehicle (102) to the operations system (302) [computing device]."; Way, et al. Paragraph [0090]: "…routing of the received vehicle data, for example, to route vehicle data to one or more infrastructure endpoints (e.g., clients) associated with the operations computing system [endpoint].").
Claims 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Way, et al. (U.S. Patent Application Publication No. 20190110174), Groves, JR. (U.S. Patent Application Publication No. 20140079057), Jiwani, et al. (U.S. Patent Application Publication No. 20200166929), and Levy, et al. (U.S. Patent Application Publication No. 20160140851) in view of Zeng, et al. (U.S. Patent Application Publication No. 20190245610).
Regarding claim 15, while Way, et al., Groves, JR., Jiwani, et al., and Levy, et al. teach the one or more tangible, non-transitory computer readable media of claim 14, wherein the retry policy action comprises providing a second routing request to the computing device associated with the aircraft.
In a similar field of endeavor (performance-based link management communications), Zeng, et al. teaches: The one or more tangible, non-transitory computer-readable media of claim 14, wherein the retry policy action comprises providing a second routing request to the computing device associated with the aircraft (Paragraph [0058]: "…n copied ATC messages to the plurality of n parallel links chosen by step (602). More specifically, at step (608), the CMU (208) may route each of the n messages to the transceiver (212) [multiple routing requests]" ; Paragraph [0062]: "If none of the links have met their max retry attempt, control returns to step (608) [retry action - continues sending routing requests].").
Therefore, it would have been obvious to one of the ordinary skill of the art before the effective filing date of the claimed invention to modify the combination of Way, et al., Groves, JR., Jiwani, et al., and Levy, et al. to include the teaching of Zeng, et al. based on a reasonable expectation of success and motivation to improve sub-network availability and latency performance for air traffic control communication systems via a process of utilizing parallel links in a performance-based link management system (Zeng, et al. Paragraphs [0026] – [0028]).
Regarding claim 16, Way, et al., Groves, JR., Jiwani, et al, Levy, et al., and Zeng, et al. remain as applied to claim 15, and in a further embodiment, teach: The one or more tangible, non-transitory computer-readable media of claim 15, wherein the retry policy is determined based, at least in part, on the one or more route request types, the aircraft, or the computing device (Zeng, et al. Paragraph [0062]: "…max retry attempt number may be policy configurable [retry policy] […] airplane requirements [the aircraft]").
Regarding claim 17, Way, et al., Groves, JR., Jiwani, et al., Levy, et al., and Zeng, et al. remain as applied to claim 15, and in a further embodiment, teach: The one or more tangible, non-transitory computer-readable media of claim 15, further comprising: obtaining, an elapsed time indicative of a time period after the routing request is provided and before an acknowledgement is received from the computing device; (Zeng, et al. Paragraph [0056]: "…step (604) the CMU (208) may prepend a sequence number to the ATC message being transmitted [after routing request is provided]. […] new message is generated, the sequence number may be incremented by one." ; Zeng, et al. Paragraph [0059]: "…step (610), the performance-based link management system (200)/(300) waits a predetermined amount of time [elapsed time] for an acknowledgement [before acknowledgement is received from computing device].")
and in response to the elapsed time achieving a time threshold, initiating, the retry policy action (Zeng, et al. Paragraph [0062]: "If an acknowledgement was not received in the predetermined time in step (610) [elapsed time achieving time threshold], […] the CMU (208) will check to see if any link has reached the link's max retry attempt [initiating retry action].").
Response to Arguments
Applicant's arguments filed on January 28, 2026 have been fully considered but they are not persuasive.
Applicant asserted that claim 1 was patentable over Way, et al. (U.S. Patent Application Publication No. 20190110174) in view of Groves, JR. (U.S. Patent Application Publication No. 20140079057) and in further view of Levy, et al. (U.S. Patent Application Publication No. 20160140851) because the references did not meet the claim limitation “wherein the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft”. Specifically, the Applicant did not believe that Levy, et al. taught the claim limitation of a “retry policy comprising a retry policy action to initiate a contingency plan”. The examiner disagrees. In Levy, et al., the retry policy is associated with an updated and retried database located on a policy server (104) which describes the relationship between infrastructure data in the flight path of the aircraft (Paragraph [0076]) and the available flight path data in a specific flight zone as a function of acceptable risk levels (Step 202), Paragraph [0077]). The server can then apply the data towards an applicable optimized contingency route for landing the aircraft in case of an emergency (Paragraph [0165]). This emergency landing step is listed as part of the method of Fig. 7, which enables implementation by control server (1108) (Paragraph [0162]), in which the policy server (104) is a subcomponent (ref. Fig. 3B). Subsequently, it would have been obvious to combine Levy, et al. with Way, et al. and Groves, JR. because Way, et al. teaches a communication associated with an aircraft via an endpoint in which the communication consists of telemetry data formatted according to a specific device format (Paragraphs [0025], [0029], [0032], [0039], and [0076]) and Groves, JR. teaches a device specific format (Paragraph [0004]).
Therefore, it can be concluded that since the combination of Way, et al., Groves, JR., and Levy, et al. reads on the claim limitation “wherein the respective device type is associated with a retry policy, the retry policy comprising a retry policy action to initiate a contingency plan for the aircraft”, as stated in claim 1, the arguments presented by the Applicant are not persuasive, and the rejection is maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ali, et al. (U.S. Patent Application Publication No. 20220051577) teaches the process of flight path deconfliction within unmanned aerial vehicles (UAVs) through the process of analyzing telemetry data from UAV and air traffic data received from a server or other data sources.
Ali, et al. (U.S. Patent No. 11436930) teaches how data can be recorded with an unmanned aerial vehicle in which a blockchain manger receives a transaction message from a UAV.
Vanderveen, et al. (U.S. Patent Application Publication No. 20200351616) teaches a method and system for aircraft vehicle location using V2X communication.
Smith, et al. (U.S. Patent No. 11431561) teaches a process of connecting unmanned aircraft systems (UAS) via an retry policy on an Internet network.
Applicant is considered to have implicit knowledge of the entire disclosure once a reference has been cited. Therefore, any previously cited figures, columns and lines should not be considered to limit the references in any way. The entire reference must be taken as a whole; accordingly, the Examiner contends that the art supports the rejection of the claims and the rejection is maintained.
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 TORRENCE S MARUNDA II whose telephone number is (571)272-5172. The examiner can normally be reached Monday-Friday 8:00-5:30.
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, ANGELA Y ORTIZ can be reached on 571-272-1206. 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.
/TORRENCE S MARUNDA II/Examiner, Art Unit 3663
/ANGELA Y ORTIZ/Supervisory Patent Examiner, Art Unit 3663
Prosecution Insights