DETAILED ACTION
Status of Claims
This Office action is in response to the application filed on 08/29/2024. Claims 1-20 are allowed.
Notice of Pre-AIA or AIA Status
The present application, which was filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement submitted on 08/29/2024 is in compliance with 37 C.F.R. 1.97 and is being considered by the examiner.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. However, applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 120 as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 17/247,575, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. Claims 4, 13, and 20 are not properly supported by the prior-filed application as explained in more detail in the section of claim rejections under 35 U.S.C. 112(a) below. Accordingly, claims 4, 13, and 20 are not entitled to the benefit of the prior application.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 4, 13, and 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 4 recites “wherein the processor is further operative to determine an estimated time of arrival and a trajectory of the originating aircraft.” Similarly, claim 13 recites “determining an estimated time of arrival and a trajectory of the originating aircraft in response to the velocity, the altitude, and the location of the originating aircraft,” and claim 20 recites “determining a current location, an estimated time of arrival and a trajectory of the originating aircraft.” These limitations are not supported because the written description does not appear to mention an estimated time of arrival in any capacity; further, while the written description appears to imply a step of analyzing the aircraft trajectory (¶ 33 of the specification states that “If the block is not consistent with prior data, such as a discontinuity in aircraft trajectory, the method may reject 312 the data from the originating aircraft.”), there appears to be no mention of determining a trajectory of the originating aircraft “in response to the velocity, the altitude, and the location of the originating aircraft” as recited in claim 13.
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 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); 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 1-3, 5-12, and 14-19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-17 of U.S. Patent No. US 12,100,304 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the differences amount to minor wording differences and specifying that the block includes a performance data of the originating aircraft in the instant claims. Requiring that the block additionally includes performance data is not patentably distinct because the reference claims already require that the block includes velocity data, altitude data, and location data of the originating aircraft; any of these pieces of data could be considered performance data of the originating aircraft, especially because the instant specification does not appear to provide any limits on what the performance data of the originating aircraft could be.
Instant application 18/818777
Reference patent US 12,100,304 B2
1. A blockchain enabled aircraft secure communications system comprising:
a transceiver configured for receiving a block from an originating aircraft wherein the block includes a data, a hash and a prior hash and wherein the data includes a velocity, an altitude, a location of the originating aircraft and a performance data of the originating aircraft and to transmit a consensus data to the originating aircraft;
a memory configured for storing a blockchain register and an airspace map of an airspace;
a processor configured for determining a validity of the block in response to the blockchain register, the hash and the prior hash, determining a consistency of the data in response to the validity of the block, the airspace map and a prior data indicative of a prior location of the originating aircraft from the blockchain register, transmitting an indication of the validity of the block and the consistency of the data to a plurality of distributed fleet network nodes wherein each of the plurality of distributed fleet network nodes is an aircraft within the airspace and wherein each of the plurality of distributed fleet network nodes stores a blockchain register of aircraft locations, determining a network consensus of the validity of the block and the consistency of the data determined in response to a plurality of validity determinations and a plurality of data determined by the plurality of distributed fleet network nodes received from the plurality of distributed fleet network nodes, rejecting the block in response to receiving a notice of invalidity from at least one of the plurality of distributed fleet network nodes, generating the consensus data in response to the plurality of data determined by the plurality of distributed fleet network nodes, and coupling the consensus data to the transceiver, the processor being further operative to generate an updated blockchain register and an updated airspace map in response to the validity of the block, the network consensus and the consistency of the data; and
a controller configured for controlling the aircraft in response to the updated airspace map.
1. A blockchain enabled aircraft secure communications system comprising:
a transceiver configured for receiving a block from an originating aircraft wherein the block includes a data, a hash and a prior hash and wherein the data includes a velocity, an altitude, and a location of the originating aircraft and to transmit a consensus data to the originating aircraft;
a memory configured for storing a blockchain register and an airspace map of an airspace;
a processor configured for determining a validity of the block in response to the blockchain register, the hash and the prior hash, determining a consistency of the data in response to the validity of the block, the airspace map and a prior data indicative of a prior location of the originating aircraft from the blockchain register, transmitting an indication of the validity of the block and the consistency of the data to a plurality of distributed fleet network nodes wherein each of the plurality of distributed fleet network nodes is an aircraft within the airspace and wherein each of the plurality of distributed fleet network nodes stores a blockchain register of aircraft locations, determining a network consensus of the validity of the block and the consistency of the data determined in response to a plurality of validity determinations and a plurality of data determined by the plurality of distributed fleet network nodes received from the plurality of distributed fleet network nodes, rejecting the block in response to receiving a notice of invalidity from at least one of the plurality of distributed fleet network nodes, generating the consensus data in response to the plurality of data determined by the plurality of distributed fleet network nodes, and coupling the consensus data to the transceiver, the processor being further operative to generate an updated blockchain register and an updated airspace map in response to the validity of the block, the network consensus and the consistency of the data; and
a controller configured for controlling the aircraft in response to the updated airspace map.
2. The blockchain enabled aircraft secure communications system of claim 1, wherein the block is rejected in response to determining an invalidity of the block.
2. The blockchain enabled aircraft secure communications system of claim 1, wherein the block is rejected in response to determining an invalidity of the block.
3. The blockchain enabled aircraft secure communications system of claim 1, wherein the network consensus is determined by a trusted node in response to the plurality of distributed fleet network nodes.
3. The blockchain enabled aircraft secure communications system of claim 1, wherein the network consensus is determined by a trusted node in response to the plurality of distributed fleet network nodes.
5. The blockchain enabled aircraft secure communications system of claim 1, wherein the data includes a weather condition measured by the originating aircraft.
4. The blockchain enabled aircraft secure communications system of claim 1, wherein the data includes an environmental condition measured by the originating aircraft.
6. The blockchain enabled aircraft secure communications system of claim 1, wherein the transceiver is further configured to transmit the validity of the block to the plurality of distributed fleet network nodes.
5. The blockchain enabled aircraft secure communications system of claim 1, wherein the transceiver is further configured to transmit the validity of the block to the plurality of distributed fleet network nodes.
7. The blockchain enabled aircraft secure communications system of claim 1, wherein the originating aircraft is operative to update at least one of the velocity, altitude, and location of the originating aircraft in response to the rejection of the notice of invalidity.
6. The blockchain enabled aircraft secure communications system of claim 1, wherein the originating aircraft is operative to update at least one of the velocity, altitude, and location of the originating aircraft in response to the rejection of the notice of invalidity.
8. The blockchain enabled aircraft secure communications system of claim 1, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the originating aircraft.
7. The blockchain enabled aircraft secure communications system of claim 1, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the originating aircraft.
9. The blockchain enabled aircraft secure communications system of claim 1, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the plurality of distributed fleet network nodes.
8. The blockchain enabled aircraft secure communications system of claim 1, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the plurality of distributed fleet network nodes.
10. A method of transmitting data comprising:
receiving, by a transceiver, a block from an originating aircraft wherein the block includes a data, a hash and a prior hash and wherein the data includes a velocity, an altitude, a performance data of the originating aircraft, and a location of the originating aircraft;
determining, by a processor, a validity of the block in response to a blockchain register stored on a memory, the hash and the prior hash;
determining, by the processor, a consistency of the data in response to the validity of the block, an airspace map of an airspace and a prior data indicative of a prior location of the originating aircraft from the blockchain register stored on the memory;
transmitting an indication of the validity of the block and the consistency of the data to a plurality of distributed fleet network nodes wherein each of the plurality of distributed fleet network nodes is an aircraft within the airspace and wherein each of the plurality of distributed fleet network nodes stores a blockchain register of aircraft locations;
determining, by the processor, a consensus of the validity of the block and the consistency of the data in response to a plurality of validity determinations and a plurality of data determined by the plurality of distributed fleet network nodes received from the plurality of distributed fleet network nodes;
rejecting the block in response to receiving a notice of invalidity from at least one of the plurality of distributed fleet network nodes;
generating a consensus data in response to the plurality of data determined by the plurality of distributed fleet network nodes;
generating, by the processor, an updated blockchain register and an updated airspace map in response to the validity of the block, the consensus and the consistency of the data; and
controlling, by an aircraft controller, a host aircraft in response to the updated airspace map.
9. A method of transmitting data comprising:
receiving, by a transceiver, a block from an originating aircraft wherein the block includes a data, a hash and a prior hash and wherein the data includes a velocity, an altitude, and a location of the originating aircraft;
determining, by a processor, a validity of the block in response to a blockchain register stored on a memory, the hash and the prior hash;
determining, by the processor, a consistency of the data in response to the validity of the block, an airspace map of an airspace and a prior data indicative of a prior location of the originating aircraft from the blockchain register stored on the memory;
transmitting an indication of the validity of the block and the consistency of the data to a plurality of distributed fleet network nodes wherein each of the plurality of distributed fleet network nodes is an aircraft within the airspace and wherein each of the plurality of distributed fleet network nodes stores a blockchain register of aircraft locations;
determining, by the processor, a consensus of the validity of the block and the consistency of the data in response to a plurality of validity determinations and a plurality of data determined by the plurality of distributed fleet network nodes received from the plurality of distributed fleet network nodes;
rejecting the block in response to receiving a notice of invalidity from at least one of the plurality of distributed fleet network nodes;
generating a consensus data in response to the plurality of data determined by the plurality of distributed fleet network nodes;
generating, by the processor, an updated blockchain register and an updated airspace map in response to the validity of the block, the consensus and the consistency of the data; and
controlling, by an aircraft controller, a host aircraft in response to the updated airspace map.
11. The method of transmitting data between the originating aircraft and a host aircraft of claim 10, wherein the block is rejected in response to determining an inconsistency of the block.
10. The method of transmitting data between the originating aircraft and a host aircraft of claim 9, wherein the block is rejected in response to determining an inconsistency of the block.
12. The method of transmitting data between the originating aircraft and a host aircraft of claim 10, wherein the consensus is determined by a ground node in response to the plurality of distributed fleet network nodes.
11. The method of transmitting data between the originating aircraft and a host aircraft of claim 9, wherein the consensus is determined by a ground node in response to the plurality of distributed fleet network nodes.
14. The method of transmitting data between the originating aircraft and a host aircraft of claim 10, wherein the data includes an environmental condition measured by the originating aircraft.
12. The method of transmitting data between the originating aircraft and a host aircraft of claim 9, wherein the data includes an environmental condition measured by the originating aircraft.
15. The method of transmitting data between the originating aircraft and a host aircraft of claim 10, wherein the transceiver is further configured to transmit the validity of the block to the plurality of distributed fleet network nodes.
13. The method of transmitting data between the originating aircraft and a host aircraft of claim 9, wherein the transceiver is further configured to transmit the validity of the block to the plurality of distributed fleet network nodes.
16. The method of transmitting data between the originating aircraft and a host aircraft of claim 10, wherein the consensus is determined in response to the plurality of validity determinations received from the plurality of distributed fleet network nodes.
14. The method of transmitting data between the originating aircraft and a host aircraft of claim 9, wherein the consensus is determined in response to the plurality of validity determinations received from the plurality of distributed fleet network nodes.
17. The method of transmitting data between the originating aircraft and a host aircraft of claim 10, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the originating aircraft.
15. The method of transmitting data between the originating aircraft and a host aircraft of claim 9, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the originating aircraft.
18. The method of transmitting data between the originating aircraft and a host aircraft of claim 10, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the plurality of distributed fleet network nodes.
16. The method of transmitting data between the originating aircraft and a host aircraft of claim 9, wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the plurality of distributed fleet network nodes.
19. A distributed fleet communications method comprising:
receiving a block from an originating aircraft including a data, a hash and a prior hash, wherein the data includes a position, a velocity, a performance data and an altitude of the originating aircraft;
validating the block in response to the prior hash and a blockchain register;
determining a consistency of the data in response to a validity of the block, an airspace map of an airspace and a prior data indicative of a prior location of the originating aircraft from the blockchain register stored on a memory;
transmitting an indication of a validity of the block and the consistency of the data to a plurality of distributed fleet network nodes wherein each of the plurality of distributed fleet network nodes is an aircraft within the airspace and wherein each of the plurality of distributed fleet network nodes stores a blockchain register of aircraft locations;
determining, a network consensus of the validity of the block and the consistency of the data in response to a plurality of validity determinations and a plurality of data received from the plurality of distributed fleet network nodes;
rejecting the block in response to receiving a notice of invalidity from at least one of the plurality of distributed fleet network nodes;
generating a consensus data in response to the plurality of data determined by the plurality of distributed fleet network nodes;
generating, an updated blockchain register and an updated airspace map in response to the validity of the block, the network consensus and the consistency of the data; and
controlling, a host aircraft in response to the updated airspace map.
17. A distributed fleet communications method comprising:
receiving a block from an originating aircraft including a data, a hash and a prior hash, wherein the data includes a position, a velocity, and an altitude of the originating aircraft;
validating the block in response to the prior hash and a blockchain register;
determining a consistency of the data in response to a validity of the block, an airspace map of an airspace and a prior data indicative of a prior location of the originating aircraft from the blockchain register stored on a memory;
transmitting an indication of a validity of the block and the consistency of the data to a plurality of distributed fleet network nodes wherein each of the plurality of distributed fleet network nodes is an aircraft within the airspace and wherein each of the plurality of distributed fleet network nodes stores a blockchain register of aircraft locations;
determining, a network consensus of the validity of the block and the consistency of the data in response to a plurality of validity determinations and a plurality of data received from the plurality of distributed fleet network nodes;
rejecting the block in response to receiving a notice of invalidity from at least one of the plurality of distributed fleet network nodes;
generating a consensus data in response to the plurality of data determined by the plurality of distributed fleet network nodes;
generating, an updated blockchain register and an updated airspace map in response to the validity of the block, the network consensus and the consistency of the data; and
controlling, a host aircraft in response to the updated airspace map.
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-3, 6, 9-11, 14-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Raab et al. (US 2017/0357009 A1), hereinafter referred to as Raab, in view of Winslow et al. (US 2019/0334697 A1), hereinafter referred to as Winslow.
Regarding claim 1:
Raab discloses the following limitations:
“A blockchain enabled aircraft secure communications system comprising: a transceiver configured for receiving a block from an originating aircraft wherein the block includes a data, a hash and a prior hash.” (Raab ¶¶ 27-28: “linked blocks form a ‘chain,’ with each additional block reinforcing those before it, thus this database type is known as a ‘block-chain’ database because the blocks are recorded as a series of dependent hashes (i.e., entry N is recorded as a hash of itself as well as entry N−1). … he vehicle 102 may also include a position module 230 in signal communication with one or more positional sensors 232 via signal path 234 and a transceiver 236. In this example, the block-chain storage module 202 is in signal communication with both the positional module 230 and transceiver 236 via signal paths 238 and 240, respectively. Moreover, the transceiver 236 may be in signal communication with a communication satellite 242, ground-station 244, or one of more other vehicles 246 via signal paths 248, 250, and 252, respectively.”)
“and wherein the data includes a velocity, an altitude, a location of the originating aircraft and a performance data of the originating aircraft.” (Raab ¶ 38: “The recorded snapshot of GPS location data 264 includes position, velocity, and time information about the vehicle 102.” Further, Raab ¶ 34: “The receiver's Earth-centered solution location is usually converted to latitude, longitude and height relative to an ellipsoidal Earth model. The height may then be further converted to height relative the geoid (i.e., the global mean sea level used to measure precise surface elevations on Earth).” Further, Raab ¶ 41: “the OBASG system 100 is configured to capture the last known attributes of all assets (both friend and foe) and capture critical attributes that include position, directional heading, and velocity of all the assets and remaining fuel of the vehicle 102.”)
“a memory configured for storing a blockchain register and an airspace map of an airspace.” (Raab ¶ 25: “the block-chain storage module 202 includes a database (not shown) and the database may be any type of known organized collection of meta-data of location related information that may include, for example, records valid GPS signals, two and three-dimensional maps of the environment 108 that the vehicle 102 is going to travel through, GPS ephemeris data for calculating the position of each GPS satellite in orbit, GPS almanac data that includes information about the time and status of the entire GPS constellation, time-stamps, last known velocities and heading, etc. The database may be a distributed database that is linked to a network (not shown) where the database includes a cryptographic hash of preceding records in the database and is accessible to all users of the distributed database.”)
“a processor configured for determining a validity of the block in response to the blockchain register, the hash and the prior hash.” (Raab ¶ 27: “The linked blocks form a “chain,” with each additional block reinforcing those before it, thus this database type is known as a “block-chain” database because the blocks are recorded as a series of dependent hashes (i.e., entry N is recorded as a hash of itself as well as entry N−1). As a result, the block-chain makes it difficult for third-parties (or even the operators) to manipulate the data within the block-chain database. Generally, the block-chain database is protected by cryptography and the block-chain database does not reside in a single database on a single server but across a distributed network of servers or non-server computers. Accordingly, whenever new entry is entered (e.g., uploaded to the block-chain storage module 202), the block-chain database is authenticated across this distributed network, then the entry is included as a new block on the chain.”)
“determining a consistency of the data in response to the validity of the block, the airspace map and a prior data indicative of a prior location of the originating aircraft from the blockchain register.” (Raab ¶ 40: “anti-spoofing module 204 receives the received GPS signals 262, via signal path 216, and compares them against retrieved block-chain data 274 from the block-chain storage module 202 via signal path 220. If the result of the comparison is that the received GPS signals 262 are valid, the anti-spoofing module 204 passes, via signal path 226, to the display module 208 which produces the navigation information 272 that is displayed on the display 212 via signal path 217.” Additionally, Raab ¶ 48: “The source validation module 402 may utilize time-series analysis to monitor patterns of movement of the vehicle 102 relative to other asset locations as described in the block-chain database in the block-chain storage module 202. Moreover, the real-time and block-chain comparator 400 may utilize a threshold detector (not shown) to determine the ‘likeness’ that the received GPS signals 262 are not valid (i.e., spoofed) based on programmable threshold levels that are set by the source validation module 402, where the source validation module 402 may include a processor (not shown) to program the threshold levels and analyze the resulting comparison signals 408 provided by the real-time and block-chain comparator 400.”)
“wherein each of the plurality of fleet network nodes is an aircraft within the airspace.” (Raab ¶ 27: “This distributed network may be spread across a plurality of block-chain databases located at the external sources that include the communication satellite 242, ground-station 244, or one of more other vehicles 246. In this example, every block-chain database located at the external sources 242, 244, and 246 would be nodes in a decentralized network that have a copy of the block-chain database which avoids the need for a centralized database management by a trusted third party. As such, these nodes can each validate entries, add them to their copy and then broadcast the additions of the entries to other nodes.” Further, Raab ¶ 21: “Examples of the vehicle 102 include, for example, an airplane.”)
“wherein each of the plurality of distributed fleet network nodes stores a blockchain register of aircraft locations.” (Raab ¶ 25: “block-chain storage module 202 includes a database (not shown) and the database may be any type of known organized collection of meta-data of location related information that may include, for example, records valid GPS signals, two and three-dimensional maps of the environment 108 that the vehicle 102 is going to travel through, GPS ephemeris data for calculating the position of each GPS satellite in orbit, GPS almanac data that includes information about the time and status of the entire GPS constellation, time-stamps, last known velocities and heading, etc.” Also, Raab ¶ 27: “every block-chain database located at the external sources 242, 244, and 246 would be nodes in a decentralized network that have a copy of the block-chain database which avoids the need for a centralized database management by a trusted third party.”)
“the processor being further operative to generate an updated blockchain register and an updated airspace map in response to the validity of the block, the network consensus and the consistency of the data.” (Raab ¶ 25: “In general, the block-chain storage module 202 includes a database (not shown) and the database may be any type of known organized collection of meta-data of location related information that may include, for example, records valid GPS signals, two and three-dimensional maps of the environment 108 that the vehicle 102 is going to travel through, GPS ephemeris data for calculating the position of each GPS satellite in orbit, GPS almanac data that includes information about the time and status of the entire GPS constellation, time-stamps, last known velocities and heading, etc.” Further, Raab ¶ 27: “these nodes can each validate entries, add them to their copy and then broadcast the additions of the entries to other nodes.” Also, Raab ¶ 40: “If the result of the comparison is that the received GPS signals 262 are valid, the anti-spoofing module 204 passes, via signal path 226, to the display module 208 which produces the navigation information 272 that is displayed on the display 212 via signal path 217.”)
“and a controller configured for controlling the aircraft in response to the updated airspace map.” (Raab ¶ 35: “The navigation module 256 may include a navigation processor (not shown), a mapping module (not shown), and control module (not shown) to control the movement and direction of the vehicle 102 and may receive additional navigation data from the positional module 230 and at least one positional sensor 232.”)
The following limitations are not specifically disclosed by Raab, but they are taught by Winslow:
“transmit a consensus data to the originating aircraft” and “transmitting an indication of the validity of the block and the consistency of the data to a plurality of distributed fleet network nodes.” (Winslow ¶¶ 23-25: “a communication node may be configured to verify and monitor the permissioned blockchain by consensus computing and previous hash comparisons. This means that a blockchain ledger, which is stored in a memory of a communication node, and which has been changed by adding a new block, may be transmitted to other communication nodes in the communication network. … the processor of the communication node may be configured to add the new block to the local copy of the blockchain ledger stored in the memory only in case the communication node receives a positive verification for the new block from a number of trusted communication nodes in the distributed communication network.” Also, Winslow ¶ 34: “a communication that considers information sent from another communication node invalid, will send a warning message to all communication nodes in the communication network.”)
“determining a network consensus of the validity of the block and the consistency of the data determined in response to a plurality of validity determinations and a plurality of data determined by the plurality of distributed fleet network nodes received from the plurality of distributed fleet network nodes.” (Winslow ¶¶ 23-24: “a communication node may be configured to verify and monitor the permissioned blockchain by consensus computing and previous hash comparisons,” wherein the verification process determines whether “the second hash-value and the reference hash-value are identical.” Also, Winslow ¶ 27: “consensus computing is a technique which is based on an exchange of information in a blockchain between numerous, preferably all communication nodes of a communication network, so that at least a majority of the communication nodes agree (consensus) that the information in the blockchain is valid.”)
“rejecting the block in response to receiving a notice of invalidity from at least one of the plurality of distributed fleet network nodes.” (Winslow ¶ 34: “To avoid the use of corrupt data in the communication network, a communication that considers information sent from another communication node invalid, will send a warning message to all communication nodes in the communication network. The warning message may include a command that configures the receiving communication nodes to exclude the communication node that sent the corrupt data from further communication. Thus, the communication network will dynamically protect itself from corrupt communication nodes.” Also, Winslow ¶ 64: “In case a majority, preferably all of the trusted nodes consider the blockchain ledger transmitted by the communication node invalid, the method continues with quarantine step 309 and the message to be sent by the communication node may be discarded.”)
“generating the consensus data in response to the plurality of data determined by the plurality of distributed fleet network nodes, and coupling the consensus data to the transceiver.” (Winslow ¶ 27: “Once the majority of communication nodes in the communication network, preferably all communication nodes in the communication network have agreed to the information in the blockchain, the blockchain is updated and sent to every communication node of the communication network to be stored there for further comparisons with further information to be validated.” Note that the limitation of “coupling the consensus data to the transceiver” is interpreted in light of ¶ 26 of the instant specification, which states that “If there is consensus within the distributed fleet network that the data from the originating aircraft is erroneous, the data may be replaced with the consensus data and/or the erroneous data may be rejected.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system of Raab by implementing a consensus procedure among the aircraft nodes and rejecting any invalid blocks based on the consensus as taught by Winslow with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Winslow ¶¶ 25 and 34 teach that this can keep the blockchain ledger secure and help with avoiding the use of corrupt data in the communication network.
Regarding claim 2:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” and Winslow also teaches “wherein the block is rejected in response to determining an invalidity of the block.” (Winslow ¶ 34: “To avoid the use of corrupt data in the communication network, a communication that considers information sent from another communication node invalid, will send a warning message to all communication nodes in the communication network. The warning message may include a command that configures the receiving communication nodes to exclude the communication node that sent the corrupt data from further communication. Thus, the communication network will dynamically protect itself from corrupt communication nodes.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system of Raab by rejecting an invalid block as taught by Winslow with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Winslow ¶¶ 25 and 34 teach that this can help to keep the blockchain ledger secure and help with avoiding the use of corrupt data in the communication network.
Regarding claim 3:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” and Winslow also teaches “wherein the network consensus is determined by a trusted node in response to the plurality of distributed fleet network nodes.” (Winslow ¶¶ 23-25: “According to an embodiment, a processor of a communication node may be configured to verify and monitor the permissioned blockchain by consensus computing and previous hash comparisons. … the communication node may be configured to add the new block to the local copy of the blockchain ledger stored in the memory only in case the communication node receives a positive verification for the new block from a number of trusted communication nodes in the distributed communication network.” Further, Winslow ¶ 28: “The present disclosure is based on a decentralized validation of information by numerous, preferably all (trusted) communication nodes of a communication network.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system of Raab by allowing a trusted node to determine the result of a consensus of several distributed blockchain nodes as taught by Winslow with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Winslow ¶ 24 teaches that this modification helps the blockchain ledger to remain secure.
Regarding claim 6:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” and Winslow also teaches “wherein the transceiver is further configured to transmit the validity of the block to the plurality of distributed fleet network nodes.” (Winslow ¶ 34: “To avoid the use of corrupt data in the communication network, a communication that considers information sent from another communication node invalid, will send a warning message to all communication nodes in the communication network. The warning message may include a command that configures the receiving communication nodes to exclude the communication node that sent the corrupt data from further communication. Thus, the communication network will dynamically protect itself from corrupt communication nodes.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system of Raab by transmitting the validity of the block to other nodes as taught by Winslow with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this since Winslow ¶ 34 teaches that this can help with avoiding the use of corrupt data in the communication network.
Regarding claim 9:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” and Winslow also teaches “wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the plurality of distributed fleet network nodes.” (Winslow ¶ 33: “the processor may be configured to transmit a message to all other communication nodes of the distributed communication network comprising a command that configures the other communication nodes to exclude the sender node from the distributed communication network, in case the hash comparison of the second hash-value of all previous blocks written in the header of the block transmitted from the sender communication node with the reference hash-value of all previous blocks of the local copy of the blockchain ledger stored in the memory of the communication node is false.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system of Raab by transmitting a notification of invalidity to other nodes as taught by Winslow with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Winslow ¶ 34 teaches that this helps with avoiding the use of corrupt data in the communication network.
Regarding claims 10 and 19:
Claims 10 and 19 are each rejected using the same rationale applied to claim 1 above, mutatis mutandis.
Regarding claim 11:
The combination of Raab and Winslow teaches “The method of transmitting data between the originating aircraft and a host aircraft of claim 10,” and Winslow further teaches “wherein the block is rejected in response to determining an inconsistency of the block.” (Winslow ¶ 33: “According to an embodiment, the processor may be configured to transmit a message to all other communication nodes of the distributed communication network comprising a command that configures the other communication nodes to exclude the sender node from the distributed communication network, in case the hash comparison of the second hash-value of all previous blocks written in the header of the block transmitted from the sender communication node with the reference hash-value of all previous blocks of the local copy of the blockchain ledger stored in the memory of the communication node is false.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of Raab by rejecting a block when it contains an inconsistency as is taught by Winslow with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Winslow ¶ 34 teaches that this helps with avoiding the use of corrupt data in the communication network.
Regarding claim 14:
The combination of Raab and Winslow teaches “The method of transmitting data between the originating aircraft and a host aircraft of claim 10,”and Raab also teaches “wherein the data includes an environmental condition measured by the originating aircraft.” (Raab ¶ 25: “the block-chain storage module 202 may include a first meta-data of the location information about the asset (i.e., the vehicle 102), targeting location information (e.g., the ending second location such as an airport, base, port, target, etc.), and a second meta-data of the environmental information that includes spatial information about the geography of the environment 108, maps (both two-and-three-dimensional), and positional information of objects within the environment 108.”)
Regarding claims 15 and 18:
Claims 15 and 18 are rejected using the same rationale, mutatis mutandis, applied to claims 6 and 9 above, respectively.
Regarding claim 16:
The combination of Raab and Winslow teaches “The method of transmitting data between the originating aircraft and a host aircraft of claim 10,” and Winslow further teaches “wherein the consensus is determined in response to the plurality of validity determinations received from the plurality of distributed fleet network nodes.” (Winslow ¶ 27: “consensus computing is a technique which is based on an exchange of information in a blockchain between numerous, preferably all communication nodes of a communication network, so that at least a majority of the communication nodes agree (consensus) that the information in the blockchain is valid.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of Raab by determining a consensus in response to a plurality of validity determinations received from the plurality of nodes as taught by Winslow with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Winslow ¶¶ 25 and 34 teach that this can keep the blockchain ledger secure and help with avoiding the use of corrupt data in the communication network.
Claims 4, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Raab in view of Winslow as applied to claims 1, 10, and 19 above, and further in view of Becher et al. (US 2013/0110388 A1), hereinafter referred to as Becher.
Regarding claim 4:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” and Raab further teaches “wherein the processor is further operative to determine … a trajectory of the originating aircraft.” (Raab ¶ 25: “the block-chain storage module 202 may include a first meta-data of the location information about the asset (i.e., the vehicle 102).” Also, Raab claim 2: “the GPS block-chain recorder is configured to record GPS-related data produced by the GPS receiver, the block-chain storage module is configured to store the GPS-related data, and the GPS-related data is a first meta-data having positional data related to a location, velocity, and trajectory of the vehicle.”)
The combination of Raab and Winslow does not explicitly teach “wherein the processor is further operative to determine an estimated time of arrival.” However, Becher does teach this limitation. (Becher ¶ 71: “speed and altitude parameters in the model are obtained from the flight procedure and included in the ETA calculation. In an embodiment, the current position and speed of the aircraft received from a radar surveillance system would further inform this calculation to allow for an updated estimation of ETA with each radar surveillance update.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system disclosed by the combination of Raab and Winslow by determining an estimated time of arrival for the aircraft as is taught by Becher with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Becher ¶¶ 31-32 teach that this can help to “ensure conflict-free metering/sequencing schedules.”
Regarding claim 13:
The combination of Raab and Winslow teaches “The method of transmitting data between the originating aircraft and a host aircraft of claim 10,” but does not specifically teach the method further “including determining an estimated time of arrival and a trajectory of the originating aircraft in response to the velocity, the altitude and the location of the originating aircraft.” However, Becher does teach this limitation. (Becher ¶ 71: “Where appropriate, speed and altitude parameters in the model are obtained from the flight procedure and included in the ETA calculation. In an embodiment, the current position and speed of the aircraft received from a radar surveillance system would further inform this calculation to allow for an updated estimation of ETA with each radar surveillance update.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method disclosed by the combination of Raab and Winslow by determining a trajectory and estimated time of arrival for the aircraft as taught by Becher with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Becher ¶¶ 31-32 teach that this helps “ensure conflict-free metering/sequencing schedules.”
Regarding claim 20:
The combination of Raab and Winslow teaches “The distributed fleet communications method of claim 19,” and Raab also teaches the following limitations:
“determining a current location… and a trajectory of the originating aircraft.” (Raab ¶ 25: “block-chain storage module 202 may include a first meta-data of the location information about the asset (i.e., the vehicle 102).” Also, Raab claim 2: “the GPS block-chain recorder is configured to record GPS-related data produced by the GPS receiver, the block-chain storage module is configured to store the GPS-related data, and the GPS-related data is a first meta-data having positional data related to a location, velocity, and trajectory of the vehicle.”)
“and wherein the indication of the consistency of the data from the originating aircraft includes the current location of the originating aircraft and the prior location of the originating aircraft stored in the blockchain register.” (Raab ¶ 40: “the anti-spoofing module 204 receives the received GPS signals 262, via signal path 216, and compares them against retrieved block-chain data 274 from the block-chain storage module 202 via signal path 220. If the result of the comparison is that the received GPS signals 262 are valid, the anti-spoofing module 204 passes, via signal path 226, to the display module 208 which produces the navigation information 272 that is displayed on the display 212 via signal path 217.”)
The combination of Raab and Winslow does not specifically teach “determining … an estimated time of arrival … of the originating aircraft.” However, Becher does teach this limitation. (Becher ¶ 71: “speed and altitude parameters in the model are obtained from the flight procedure and included in the ETA calculation. In an embodiment, the current position and speed of the aircraft received from a radar surveillance system would further inform this calculation to allow for an updated estimation of ETA with each radar surveillance update.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method disclosed by the combination of Raab and Winslow by determining an estimated time of arrival for the aircraft as is taught by Becher with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Becher ¶¶ 31-32 teach that this can help to “ensure conflict-free metering/sequencing schedules.”
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Raab in view of Winslow as applied to claim 1 above, and further in view of Delaney et al. (US 10,880,070 B1), hereinafter referred to as Delaney.
Regarding claim 5:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” but does not explicitly teach “wherein the data includes a weather condition measured by the originating aircraft.” However, Delaney does teach this limitation. (Delaney col. 12 ll. 46-59: “Each of the aircraft sensors 122 may be configured to sense a particular condition(s) external to the aircraft 102 or within the aircraft 102 and output data associated with particular sensed condition(s) to one or more onboard devices or onboard systems (e.g., the communication system 104, the computing devices 112, the aircraft sensors 122, the input/output devices 124, or a combination thereof). For example, the aircraft sensors 122 may include an inertial measurement unit 302, a radio altimeter 304, radar (e.g., weather 306, surveillance radar, and/or weapon radar), airspeed sensors 308, flight dynamic sensors 310 (e.g., configured to sense pitch, roll, and/or yaw), air temperature sensors 312, air pressure sensors 314…”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system disclosed by the combination of Raab and Winslow by allowing the block to include weather data measured by the originating aircraft as taught by Delaney, as this is a simple substitution of one known element (i.e., the weather data of Delaney) for another (i.e., any of the received data elements described in Raab ¶ 25) to obtain predictable results (see MPEP 2143(I)(B)). A person having ordinary skill in the art could have replaced the data of Raab with the weather data of Delaney to achieve the predictable result of authenticating aircraft weather data using blockchain technology.
Claims 7-8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Raab in view of Winslow as applied to claims 1 and 10 above, and further in view of Pennapareddy (US 2021/0035457 A1).
Regarding claim 7:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” but does not explicitly teach “wherein the originating aircraft is operative to update at least one of the velocity, altitude, and location of the originating aircraft in response to the rejection of the notice of invalidity.” However, Pennapareddy does teach this limitation. (Pennapareddy ¶ 33: “the first aircraft 102 compares the position 134 to a flight path indicated by the third flight plan data 116. Because the position 134 is selected by a malicious actor, the position 134 is not related to a flight path of the third aircraft.” Also, Pennapareddy ¶ 35: “flight management system 108 can also attempt to communicate with the third aircraft to confirm its position directly from the third aircraft. After verifying (or failing to verify) the position of the third aircraft, the flight management system 108 generates and sends a second message 142 to the first aircraft 102. The second message 142 confirms whether or not the position 134 is verified.” This at least teaches that the originating aircraft is operative to update its location as claimed.)
Note that under the broadest reasonable interpretation (BRI) of claim 7, consistent with the specification, the originating aircraft being “operative to update at least one of the velocity, altitude, and location of the originating aircraft” is treated as an alternative limitation. Applicant has elected to use the phrase “at least one” in the claim language, and therefore, the BRI covers the scenario in which only one of the limitations applies. Accordingly, while only the “location of the originating aircraft” has been addressed here, the claim is still rejected in its entirety.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system disclosed by the combination of Raab and Winslow by giving the originating aircraft a chance to update its location after the block is initially rejected as taught by Pennapareddy with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Pennapareddy ¶¶ 36-37 teach that this helps to confirm whether the message is malicious and inaccurate so that the system can ignore these messages and improve security.
Regarding claim 8:
The combination of Raab and Winslow teaches “The blockchain enabled aircraft secure communications system of claim 1,” and Winslow also teaches “wherein the transceiver is further configured to transmit a notification of an inconsistency of the data to the originating aircraft.” (Pennapareddy ¶ 33: “first aircraft 102 compares the position 134 to a flight path indicated by the third flight plan data 116. Because the position 134 is selected by a malicious actor, the position 134 is not related to a flight path of the third aircraft.” Further, Pennapareddy ¶ 35: “the flight management system 108 can receive information that the aircraft is off course. The information can be received from an airline or an ATC station. Thus, the flight management system 108 can store or have access to information indicating the position of the third aircraft. If the flight management system 108 does not have access to such information, the flight management system 108 can also attempt to communicate with the third aircraft to confirm its position directly from the third aircraft. After verifying (or failing to verify) the position of the third aircraft, the flight management system 108 generates and sends a second message 142 to the first aircraft 102. The second message 142 confirms whether or not the position 134 is verified.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the system disclosed by the combination of Raab and Winslow by transmitting a notification related to data inconsistency to the originating aircraft as taught by Pennapareddy with a reasonable expectation of success. A person having ordinary skill in the art could have been motivated to do this because Pennapareddy ¶¶ 36-37 teach that this helps to confirm whether the message is malicious and inaccurate so the system can ignore these messages and improve security.
Regarding claim 17:
Claim 17 is rejected with the same rationale applied to claim 8 above, mutatis mutandis.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Raab in view of Winslow as applied to claim 10 above, and further in view of Mitchell et al. (US 2019/0281026 A1), hereinafter referred to as Mitchell.
Regarding claim 12:
The combination of Raab and Winslow teaches “The method of transmitting data between the originating aircraft and a host aircraft of claim 10,” but does not specifically teach “wherein the consensus is determined by a ground node in response to the plurality of distributed fleet network nodes.” However, Mitchell does teach this limitation. (Mitchell ¶ 22: “Examples of nodes contemplated for use with embodiments include ACARS LRUs and ground stations that communication with aircraft ACARS systems. Ground station nodes may each have a copy of the complete blockchain ledger, so that any of them can validate the authenticity and legitimacy of transactions throughout the ledger. Such nodes may be considered privileged according to some embodiments, and they may perform a number of critical tasks to maintain the integrity of the chain, so long as there is a supporting majority vote and a quorum to act.”)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method disclosed by the combination of Raab and Winslow by using a ground node to determine the result of the consensus decision as taught by Mitchell, because this is a simple substitution of one known element (i.e., a ground node) for another (i.e., the aircraft node of Winslow) to obtain predictable results (see MPEP 2143(I)(B)). A person having ordinary skill in the art could have substituted the aircraft node of Winslow with the ground node of Mitchell to achieve the predictable result of providing a centralized, trusted node for managing the execution of final consensus decisions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Madison R Inserra whose telephone number is (571)272-7205. The examiner can normally be reached Monday - Friday: 9:30 AM - 6:30 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aniss Chad can be reached at 571-270-3832. 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.
/Madison R. Inserra/Primary Examiner, Art Unit 3662