Patent Application
20230015158
The present invention is in the technical area of modular transport apparatus based on Pod units that may be carried by ground vehicles, rail vehicles and unmanned arial vehicles (UAVs), and storage, docking facilities landing stations and charging facilities for such apparatus.
Pod-based apparatus for transporting passengers and cargo is relatively new in the art, and not many commercial facilities are known. There are, in the current state of the art, UAV taxi systems, for example, which have a passenger pod that may be detached from the UAV, loaded with either passengers of cargo, or both, and then picked up by a UAV to be transported to an end destination. The challenges in many different carriers that may be utilized, how pods may be exchanged between different sorts of carriers, including ground carriers, rail carries and UAVs such as drones are significant, as are how the carriers may be powered, and in the case of battery power, how the carriers may be charged and maintained. The present inventor believes the present disclosure adds unique apparatus and functionality to the existing state of the art in passenger and cargo transport.
In an embodiment of the present invention a transportation system is provided, comprising a plurality of transport vehicles, each having controllable electric motors and a first attachment interface, a plurality of pods, being enclosed compartments that can accommodate cargo, each pod having a door, a rechargeable battery, and a second attachment interface adapted to attach to the first attachment interface of an individual one of the transport vehicles, a plurality of podports, being exchange stations adapted to attach to and detach pods from individual ones of the transport vehicles, individual ones of the podports located at specific locations in a specific geographic area, a plurality of charging stations located at specific locations within the geographic area, and a computerized transport control system. The system is characterized in that an authorized person communicates a request to the computerized transport control system to transport a specific cargo from a first location in the geographic area to a second location in the geographic area, the computerized transport control system in response defines a journey beginning at the first location and ending at the second location, the definition of the journey including a time for pickup of the specific cargo, a specific pod and transport vehicle assigned for pickup, and a route, the route comprising sequential hops through a series of podports and charging stations, the computerized transport control system managing movement of transport vehicles, exchanges at podports, and charging at charging stations along the defined route, the route ending at the second location where the cargo disembarks, wherein the computerized transport control system terminates the journey.
In one embodiment of the system the cargo comprises passengers or parcels, or both passengers and parcels. Also, in one embodiment the plurality of transport vehicles comprises unmanned arial vehicles (UAVs) and transport chassis, the transport chassis adapted to travel on a roadway or on an overhead railway. In one embodiment, in a journey, the pod is carried for a hop by a drone or by a transport chassis, and the pod is detached from one transport vehicle and attached to a different transport vehicle at individual ones of the podports in the journey. And in one embodiment the computerized transport control system creates a cluster network control (CNC) module unique to each defined journey, and the CNC controls the route for which it is created, retrieves status of the pod as the pod exits each podport and charging station along the route, and communicates completion of the journey to the computerized control system.
In one embodiment, with a pod attached to a transport vehicle, an electrical connection is implemented as well as a physical connection, and the electric motors of the transport vehicle are powered by the pod battery. Also, in one embodiment charging stations are adapted to charge the pod battery. Also, in one embodiment individual ones of the plurality of pods comprise an upper attachment interface adapted to attach to an attachment interface of an unmanned arial vehicle, to be suspended below the unmanned arial vehicle, and a lower attachment interface adapted to attach to an upper attachment interface of a transport chassis adapted to travel on a roadway or on an overhead railway. In one embodiment, in the management of a journey the computerized transport control system communicates with remote data centers, comprising at least a weather bureau that provides up to date local weather information, an emergency center adapted to resolve exceptions, a data analytics center that is adapted to store each completed route for future use and analysis, and a test diagnostics unit adapted to check the system and to fix problems. And in one embodiment the CNC for a defined journey tracks the location of the pod, and as the pod approaches each podport in the journey, the podport is provided with information regarding the pod and the journey, and any defined exchange at the podport, and the podport manages movement of the pod through the podport.
In another aspect of the invention a transportation method is provided, comprising communicating a request by an authorized person to a computerized transport control system to transport a specific cargo from a first location in a geographic area to a second location in the geographic area, defining a journey by the computerized transport control system in response to the request, the journey beginning at a first location in the geographic area and ending at a second location, the definition of the journey including a time for pickup of the specific cargo, a specific pod among a plurality of available pods, a pod being an enclosed compartment that can accommodate cargo, each pod having a door, a rechargeable battery, and a second attachment interface, and transport vehicle assigned for pickup among a plurality of available transport vehicles each having controllable electric motors and a first attachment interface, and a route, the route comprising sequential hops through a series of podports and charging stations, a podport being an exchange station adapted to attach to and detach pods from individual ones of the transport vehicles, individual ones of the podports located at specific locations in a specific geographic area, managing by the computerized transport control system movement of the pod and transport vehicle during the journey, exchanges at podports, and charging at charging stations along the defined route, and terminating the journey at the second location where the cargo disembarks.
In one embodiment of the method the cargo comprises passengers or parcels, or both passengers and parcels, comprising moving the passengers and parcels or both along the route to the second location. Also, in one embodiment the plurality of transport vehicles comprises unmanned arial vehicles (UAVs) and transport chassis, the transport chassis adapted to travel on a roadway or on an overhead railway, comprising managing by the computerized transport control system the movement of the transport vehicle whether UAV of chassis. In one embodiment the method comprises, in a journey, carrying the pod for a hop by the UAV or by a the transport chassis, and detaching the pod from one transport vehicle and attaching the pod to a different transport vehicle at individual ones of the podports in the journey. And in one embodiment the computerized transport control system creates a cluster network control (CNC) module unique to each defined journey, comprising controlling the route by the CNC , retrieving status of the pod as the pod exits each podport and charging station along the route, and communicating completion of the journey to the computerized control system.
In one embodiment the method comprises establishing an electrical connection as well as a physical connection when joining a pod to a transport vehicle, and driving the electric motors of the transport vehicle from the pod battery. In one embodiment the method comprises charging the pod battery by the charging stations. In one embodiment the method comprises attaching pods to UAVs by an upper attachment interface on the pad joining a lower attachment interface on the UAV, and attaching pods to transport chassis by a lower attachment interface on the pod to an upper attachment interface on the transport chassis. In one embodiment the method further comprises communicating by the computerized transport control system with remote data centers, the remote data centers comprising at least a weather bureau that provides up to date local weather information, an emergency center adapted to resolve exceptions, a data analytics center that is adapted to store each completed route for future use and analysis, and a test diagnostics unit adapted to check the system and to fix problems. And in one embodiment the method comprises tracking location of the pod in a defined journey by the CNC, providing information regarding the pod and the journey to a podport as the pod approaches the podport, including any defined exchange at the podport, and managing movement of the pod through the podport.
The following provides terminology used in this application:
Referring to
Carpods can exit a podport at surface level to become a trampod on rails or ascend a ramp to become a railpod on an overhead rail, or descend into a tunnel, in each case the rails need no power lines. Or in the future when Level 4+ or 5 car technology is certified, just remain as a carpod on a normal road amongst legacy traffic. The transition from carpod to trampod to railpod to tunnelpod is performed outside podports, with all configurations using the intelligent chassis as the transport vehicle. The important fact here is that the overhead rail uses the same carpod - the wheels and frame supporting the pod, instead of hanging from a trolley suspended below the rails. This has a major advantage in that the podport need only internally support carpods and dronepods, greatly simplifying the podport design while allowing the podport to be very versatile.
The multiple pod vehicles shown in
To save on tire wear both inside and outside the podport, rearward facing sensors at the front of the chassis monitor the gap between the front tire sidewalls and the rail sidewalls. They provide a feedback system that ensures the tires stay in the middle of the rails and not touch the sidewalls of the transfer path inside the podport which may comprise a square ‘U’ shaped cut into a solid surface. The same sensors will be used outside the podport on tramways and overhead rail for monitoring the distance from the sidewalls. This helps guide the [carpod] through the turns on the overhead rail or tramway.
To maintain an elevated level of redundancy in the [carpod] or dronepod to maximize safety, an additional wireless link for sensor and control signals using say the latest WiFi version between pod and transport vehicle will greatly increase reliability, complementing the wired link plus connector. And it is likely a secondary power connection between pod and transport vehicle will eventually be wireless because wireless power capability is improving fast. This will allow for multiple redundancy, enhancing safety, both inside and outside the podport.
Because the pod remains closed for the whole journey, including traversing through all the podports along the way, the isolated enclosed pod minimizes infection risk for passengers, offers privacy for the whole journey, minimizes contamination for sensitive content, and more easily maintains temperature and pressure. This offers major advantages over most forms of local transport where the travel compartment is shared along the way, and the door is opened and closed.
Passengers or parcels in a pod, when traveling through the podport, stay in the same pod from podport entry to exit, see
The podports allow interchanges between the two forms of transport vehicle: 1-chassis and 1-drones. The layout can be greatly simplified by combining all of these into a number of entry bays of a single type or exit bays of a single type, all managed by software in the Station System Control unit of the podport. If the podport is initially built for say 4-pods, even though initial usage might be for 1-pods only, then as the traffic inside the podport increases, and 4-pod vehicles become necessary, there will be no need to re-layout the bays for 4-pods. Merely by installing additional software in the Station System Control, the system can determine which size of train, one or four, and whether dronepod or carpod.
Each arriving dronepod or carpod is directed to enter a pre-selected available entry bay in the podport. If a carpod enters an entry bay, it is simply released on to the internal transfer path as a carpod.
But instead, if a dronepod enters an entry bay, it lands on top of a waiting 1-chassis just transferred from the chassis parking bay, creating a carpod with the drone still on top. The drone then detaches from the carpod, resulting in a short delay, and flies to the drone parking bay to recharge and await its next call. In both cases the remaining carpod is released and serially travels down the transfer path as a carpod.
After leaving an entry bay or passenger terminal or parcel bay in the podport, the carpod travels along the internal transfer path, where the pod is automatically recharged. The carpod transfers to its pre-selected exit bay, or passenger terminal or parcel bay. If a carpod is pre-selected to exit the podport from a certain exit bay, the carpod exits the transfer path to the pre-selected exit bay and can be immediately released by station system control to exit the podport. For exiting dronepods, an unattached fully charged drone from the drone parking bay attaches to the top of the carpod just arrived in the preselected exit bay. Then the chassis beneath is detached, creating a dronepod, causing a similar slight delay. The chassis transfers to the chassis parking bay to be recharged while the dronepod is released by station system control and exits the podport.
Allowing for both dronepod/s or carpod/s to enter any available entry bay overcomes queuing issues caused by surges of dronepods only or carpods only, when arriving. Similarly, when exiting, the exit bays can support both carpods and dronepods. This therefore does not confine how the exit bays can be used. This is provided there are enough 1-chassis in the chassis parking bay when many dronepods are arriving, or enough 1-drones in the drone parking bay when exiting. Minimizing queuing will result in average less delays at busy times. This layout of identical entry bays and identical exit bays that accommodate both dronepods and carpods results in a very versatile podport design and layout.
Because carpods can be linked together in a train, probably electronically, this allows creation of a number of carpods in a train. If two carpods are waiting to leave an exit bay and the podport system knows there is no sign of another going to the same podport, there is no point waiting, and the two can be linked electronically and exit together. Conversely if more than four are going to the same podport and all are ready to exit, once the pre-selected exit bay is full, a second exit bay can take a train of overflow carpods 5-8 and they can link up with the train from 1-4 during exiting. Or if more than four carpods are coupled together in a train that is arriving at a podport, the second train 5-8 will be sent to another entry bay. Any of these will result in average lower delays. 4-railpods and 4-trampods can be charged on podchargers as with 1-railpods and 1-trampods, although the power required from the podcharger will be four times higher.
There will be often a need for passengers to require an urgent journey, which may for example be requested by owners of privately owned pods, to travel at maximum speed through the system. There may be a similar urgent need for say medical kits or certain goods to be sent through the system at high speed. It is likely these cases will accept paying additional fees for high-speed service. One approach to achieve fast thruput is by using only 1-pods the whole journey so that upon arriving at a podport, the closest available entry bay can be assigned to the carpod or dronepod. The 1-carpod or 1-dronepod will immediately enter this entry bay, and if it is a dronepod, it attaches to the waiting intelligent chassis, and its drone will detach. The carpod exits the entry bay, down the transfer path to the nearest pre-assigned available exit bay and exit as a 1-carpod or 1-dronepod. The Cluster Network Controller for this user, CNC[#], will have also selected the fastest hops between podports with a priority over other users entering the same podways so will enter podways immediately.
The podport transfer path can be configured to have two parallel charging slider rails, positive and negative, to be fitted to one side of the transfer path. This allows the pods to charge while traversing the transfer path as shown in
This is important because it allows transport system control (TSC) and the assigned cluster network controller CNC[#] to assume that any carpod or dronepod departing a podport is fully charged, and can be guaranteed to travel a certain distance, and therefore can calculate whether it can or cannot reach the next podport or podcharger, or the final destination and return the empty pod back to a podport. Once charging is complete the amount of charge is checked with the amount specified for that pod that TSC has that information. It is possible that batteries may be of different capacities making this relevant information, requiring that TSC must know the battery capacity of each pod. And that it can select a pod with enough capacity for the maximum distance of the pod’s planned route. Also, the pod’s battery can be checked at the start of charging to ensure the amount of charge remaining after the last hop is what was expected. This checks that the battery is functioning correctly.
As the carpod travels along a transfer path in the podport it uses electronic markers positioned at exit paths as direction indicators to guide the carpod: if the pod while passing a marker does not recognize the exit id, it stays on the main transfer path. If it does recognize the marker for its exit location, it turns into that path which is an exit path to its destination inside the podport. The marker could beam a message id indicating the carpod to exit, or it could be just a pole with the exit marker written on it which a camera in the pod detects the exit marker by matching the wording with its preprogrammed wording for that exit.
It is possible on a long hop between two pre-selected podports that a pod’s battery may not have sufficient battery charge to complete the hop. Besides the use of podchargers, there are two ways a pod can be charged using an interim podport along the route. The pod could pass directly into and through this interim podport and get charged while traversing its internal transfer path. Another approach is to install podchargers at relevant podports so if the dronepod or carpod will have an insufficient charge on a hop between two podports, it can be directed to a waiting podcharger at an intermediate podport where it will fully charge while traversing by. This obviously requires installing podchargers at interim podports where some podports are too far apart. Installation should not be a major issue because the land was already acquired for the podport and permission to add the podcharger may be a formality.
The layout and placement of podports is also important as shown in
The optimum positioning for the entry and exit bays of the podport is at opposite ends of the podport, with the passenger terminal and parcel bay on one of the sides. Probably the best location of a podport is offset relative to say a crossroads. This offset podport supports travel of dronepods on both sides of the road as shown, minimizing risk of collision. The layout also facilitates easy merging of carpods and dronepods to or from a podport with the main throughways.
The layout shown allows the podport to be easily built and upgraded. It also enables fast throughput of pods in the podport. Podports can be laid out in any direction, such as interchanging north and south, etc., and podports can be built initially as just dronepod only, or carpod only, or both, as shown. Parcel and passenger entry and exit can be direct from the access road.
The design and layout of podports is crucial to the success of the autonomous attached pod methodology, by offering low construction cost, small area, easy access, fast throughput, and mixing of parcels and passengers.
When a dronepod arrives at a pre-selected entry bay at a specific time, a fully charged chassis or four chassis will have already driven from the chassis parking bay along the chassis transfer loop to the entry bay. The dronepod lands on and attaches to the chassis, the drone then detaches from the pod/s and flies to the drone parking bay where it recharges. It lands on pillars that at the top have an identical set of connectors as the top of a pod, so that the drone’s battery can be charged while parked on the pillars. Conversely when a dronepod is to exit the podport, a charged drone flies to the carpod/s in the exit bay and lands on top, attaching to the pod/s. The chassis then drives off along the chassis transfer loop, which may be submerged, to the chassis parking bay where it is recharged. The submerged chassis path is thus a loop, with chassis driving to the chassis parking bay from an exit bay for dronepods exiting the podport, and chassis driving from the chassis parking bay to an entry bay when a dronepod enters the podport. If the loop is submerged, then carpods traveling along transfer paths are not delayed if a carpod intersects a chassis passing on the loop.
There is also a need to minimize the number of carpod turns along the podport’s transfer path, both to maximize speed through the podport along the transfer path because turns slow down the carpod, and to minimize passenger inconvenience while turning on a tight turn. A tighter turn will also minimize the additional layout area of each turn keeping the podport base area small. To minimize the number of turns in a podport, some transfer path links can be submerged while passing under a transfer path.
Podports can be designed for a single floor or multiple floors.
This proposed stepped upgrade approach allows minimal disruption of the podport during upgrades, by continually upgrading hardware and software in incremental steps on the two floors, in conjunction with upgrading firmware in the pods and transport vehicles, and podport software.
Step 1. Parcel delivery by 1-dronepod is likely to be implemented ahead of pod-based tramways / overhead rail, once approval for general BVLOS drone parcel delivery has been granted by the FAA, and by other countries’ flight authorities. This will enable dronepod delivery for medical kits, parcels, urgent mail, meals and food, or factory parts, etc. to homes or hospitals or factories or other buildings, possibly in that order.
Step 2. Adds parcel transport capability for trampods, railpods adjacent to or above legacy roads (and later L4, L5 compatible carpods on legacy roads). Also relies on interested parties committing to building infrastructure. This is a trivial task inside the podport but a big one outside.
Step 3. Add capability for passenger railpods, trampods, and passenger drones once international and country standards have been developed. For a parcel delivery company this allows the passenger dronepod, trampod and railpod application to be leased out.
Step 4. Add parcel delivery and passenger transport by 4-carpod. This is a trivial step compared to the others. It can be re-prioritized if parcel business grows fast and 4-carpods become necessary sooner.
Step 5. Add parcel delivery and passenger transport by 4-dronepod. This is likely to be launched after trams/overhead rail depending on 1-dronepod usage once approval for parcel delivery by 4-dronepod has been granted. This step can be re-prioritized if parcel or passenger business grows fast and 4-dronepods become necessary sooner.
Fully autonomous transport of parcels could initially evolve from either drone parcel delivery, or small parcel carrying robots on a sidewalk or local road, or a combination of drones and carpods that are in fact street robots.
A dronepod comprises the transport vehicle carrying a pod with parcels. The dronepod traverses along publicly approved droneways to a pre-selected local podport. In a simple example like in
The parcels remain in the same pod that they were loaded into in the parcel warehouse, through the local podport to the delivery zone, and the pod remains closed and locked throughout the journey. In the Fig., inside the local podport at the pre-selected entry bay, the dronepod lands on a waiting chassis that has driven itself from the chassis parking bay to the entry bay. The dronepod attaches to the chassis underneath and the drone detaches from the top of the pod and flies to the drone parking bay. The pod latched to the chassis is now configured as a carpod, which travels down the transfer path to an exit bay where it can immediately exit the local podport and drive itself autonomously to the delivery zone.
At the delivery zone it offloads the parcels in turn at the preselected homes, by automatically opening the pod’s door, and dropping the parcel/s off using for example the pod’s mechanical arm, on to the home’s marked loading pad. The arm retracts, the pod door closes, and the dronepod autonomously drives to the next pre-selected home and the sequence repeats, until at the last pre-selected home the now empty carpod autonomously drives back to the local podport.
It enters the local podport at the pre-selected entry bay and travels down the transfer path to an exit bay, where a drone from the drone parking bay flies on to the top of the carpod and attaches to it. The chassis underneath then detaches and autonomously drives to the chassis parking bay. The dronepod in the exit bay now exits the local podport and autonomously flies back to the parcel warehouse, where it waits for its next load of parcels.
Fully autonomous transport of parcels could initially evolve from either drone parcel delivery, or small parcel carrying robots on a sidewalk or local road.
Or it can be to a rendezvous with a small parcel carrying robot operating on a sidewalk, or a collection point like the dronepod stop shown in the Fig.. The dronepod routes could include strategically placed off-road 1-dronepod stops with the 1-dronepods landing on a landing zone which could be the stop’s roof. This would allow parcels to be autonomously inserted or removed from a landed dronepod, for possible autonomous delivery or pickup by robots or people. No exchanging of transport vehicles occurs at these stops.
The pods with their transport vehicles can have unlimited range because they are charged either when in a podport or passing by a podcharger. While setting up the journey, transport system control (TSC) may have determined that a pod will not have adequate battery storage capacity to complete a segment of its journey, and therefore needs to re-charge while passing by a pre-selected podcharger. In the dronepod only example shown, the podcharger, referred to in USPTO pat. 9937808, comprises a pole with two horizontal slider rails. After mechanical engagement with the pod, the pod’s battery as the pod’s brushes or receptacle pass along the slider rails. The speed at which the dronepod traverses the slider will depend on the charger and pod battery system capabilities, but as technology progresses this speed could increase to cruise speed such that the dronepod need not slow down. This interim charge gives the dronepod enough range to reach the final destination, which may be either the next podport as shown, or if just charged at the final podport of the journey, deliver the parcels to the external destination and then return the empty dronepod back to the final podport.
Because trampods enter and exit at grade, external tramways are the simplest and lowest cost transport choice. Tramways are advantageous in areas where there are few junctions. Busy junctions can be bridged, using an overhead exceptionally light rail, because the pod with its intelligent chassis is lightweight. The bridge could be then extended later to continue the overhead rail. The extension could be built above existing roads for ease of installation and minimal discomfort to people living below on either side of an existing road or in the central reservation. Local authorities will obviously need to agree to these two forms of transport.
By keeping trampods at grade or railpods on overhead rail separate from legacy road traffic, or pedestrians or bikes from crossing their path uncontrolled, the trampods and railpods will operate on controlled no interruption routes, except when trampods come to a road junction. These autonomous trampods and railpods have sensors and controls in both the pod and chassis that support detection of other traffic or unexpected obstacles in front or sides, and to enable safe merging at junctions. Links between the tramway and overhead rail at busy junctions are shown in
Pods can include passengers as well as parcels, and the use of either is independent of transport vehicle and podports. There may be a difference in the pod for each, as long as the weight restrictions and key dimensions are the same. The entire system can manage both passengers and parcels, with simultaneous and seamless transport of both. Podports will need to add a passenger terminal comprising check-in, security, transit bay, rest area etc. as shown in
Only Transport System Control and Cluster Network Control will know the difference and arrange for the relevant pod type to be called to pick up and deliver the passengers or parcels, then will inform the first and last podport in a journey to activate either the passenger terminal and transit bay, or the parcel bay.
Manufacturers of passenger drones are in the process of trying to get them certified. Future podports will support passengers for carpods, so the additional support needed for passenger dronepods is minimal, because the passenger terminal with its transit bay will already support trampods and railpods, and the entry and exit bays already support dronepods.
The transport system operator may allow privately owned or company owned pods, or specialty pods, for passengers, parcels, or light goods, but these must comply to a future pod standard.
A simple, low-cost example of a parcel / passenger local transport system can comprise a parcel warehouse, a station, and a podport. This configuration can support parcel only, or passenger only, or a combination.
The carpod then autonomously drives along the internal transfer path to an exit bay. During the transfer, the carpod is charged as it traverses the transfer path, such that at arrival at the exit bay it is already fully charged. In the exit bay it drives out to one of the zones to either deliver parcels to some homes in the zone, or takes the passenger/s to a home, or picks up a passenger or parcels. The carpod then autonomously returns to the main podport along a specified route to a pre-selected entry bay.
The carpod drives into the entry bay, and if clear, proceeds along the transfer path where the pod is charged, to a pre-selected exit bay, and waits for a drone from the drone parking bay to land on it, then attach to it. Then the chassis detaches and drives to the chassis parking bay. The drone flies to either the local station to drop off the passenger or pick up another passenger going via the main podport to a zone, or pick up more parcels at the parcel warehouse, or just park and wait for another command.
This configuration is for drones to operate between the warehouse or station and the main podport, and carpods between the main podport and the zones. Another alternative would be instead of carpods to have smaller less range drones between the podport and zones. This would require these drones to be approved for BVLOS (beyond visual line of sight) for both parcels and passengers, which could require the drones to fly above roads instead of people and property. Note that in all examples, the passenger/s and parcels stay in the same pod for the whole journey, minimizing chances of infection, or deterioration of the parcel contents.
Each pod’s journey from origin to destination is set up initially by transport system control (TSC). Once the passenger or the parcel operator has agreed to the proposed route, TSC sets up a temporary cluster network controller CNC[#] that routes the journey in hops via pre-selected podports, podchargers, and podstops on the agreed-to route. CNC[#] manages the pod’s journey through these podports, podchargers, and podstops, messaging with each upon arriving and departing, thereby freeing up TSC to perform its many other tasks. Once the pod has reached its destination, the destination podport alerts CNC[#], which informs TSC. TSC then shuts down that cluster network CNC[#], saving the information for possible use or for data analytics.
In the commute example shown in
So overall high-level control is managed by TSC, and the individual journeys are managed by temporary CNCs, which are individually disabled by TSC whenever that CNC’s journey that it manages is completed.
TSC also directly connects to any pod that has an emergency situation, which could be a passenger problem, a parcel problem such as overheating, or a dislodgement. Or the pod or transport vehicle may be experiencing a mechanical problem. Or there may be a problem with an upcoming podport or podcharger. In any of these cases a system operator will need to talk directly with the pod’s passenger or the parcel operator.
External communication for each podport, PP, is through the podport’s station system control unit using 5G/6G. The PPs communicate at an elevated level with the CNC[#] that assigned the journey’s planned podports, and with the charging PCs passed by during the hop to the next podport. The PPs must also communicate with their assigned dronepods and carpods when in the vicinity, and in particular next and previous podport, stops, and podway markers if necessary. PP’s will also sometimes have to link via 5G/6G direct to a pod when it is external to the podport, typically at the first and/or last podports, when initially picking up and/or later dropping off the passenger or parcels. The PP may use WiFi or a 5G variant whenever an external dronepod or carpod is within range.
The PP also communicates internally using WiFi, for station system control to its passenger terminal, transit bay, parcel bay, entry bays and exit bays, dronepods and carpods entering and exiting, and carpods on its transfer path including monitoring each pod’s charge as it traverses the transfer path while charging.
PCs will link via 5G/6G to approaching dronepods, railpods and trampods and then when in range of WiFi, switch over to WiFi to engage and later disengage the slider. After departing the PC, communication (if needed) will be by 5G/6G.
There also will be a 5G/6G link between the pod’s control box for the passenger/s and TSC and the emergency network so that urgent interrupts can get immediate access for high level control issues.
Pods and transport vehicles when attaching or detaching in podports will communicate both through a wired LAN when attached, and WiFi before, during, and after attachment or detachment.
Each pod’s control box communicates externally to its attached transport vehicle and entertainment module, and internally with the passenger/s and internal controls (not shown).
Dronepods and carpods communicate while in or near a podport, podcharger, and podstop, via their pods. During a journey they also communicate with podway markers along the pre-selected route to ensure they are on course. They may if required communicate while passing each marker on the hop.
Initially the passenger [P] or parcel operator [O], designated [id], contacts TSC either by a mobile device or at a kiosk to request a journey from Origin to Destination, where both Origin and Destination could either be inside a PP or in the vicinity of one. TSC then authenticates [id], determines pickup time or planned ETA, and selects the best PPs for Origin and Destination. It then needs to know the approximate payload weight, which if it is a passenger includes luggage, another passenger, or children. It checks the weather and any possible delays along the way, then calculates the approximate route. It then requests [id] to select the best route to take, depending on [id]’s travel priorities.
These could be: fastest (dronepod, then railpod, then trampod), cheapest (trampod), most scenic (dronepod, railpod), most comfortable, safest, or any carrier vehicle type not wanted, and if relevant will [id] use its own pod? [id] responds, TSC determines the journey more accurately after checking the weather along the route. If the weather is not acceptable in a particular part of the journey, TSC recalculates a better route and checks with [id]. If not acceptable to [id], TSC aborts and informs [id].
If the proposed route is acceptable to [id], TSC re-calculates journey time including wind effects, and creates a new Cluster of PPs, PCs, and stops, that will enable completion of the journey. TSC then hands over control of the journey by creating a Cluster Network Controller CNC[#] to manage the pod’s journey. CNC[#] then accesses and verifies with each PP and PC, calculates the ETA of the pod at each PP and PC, and informs the PP or PC. If there are any issues, CNC[#] re-assigns problematic PPs or PCs to others in the vicinity. CNC[#] then informs TSC, which recalculates the cost, and If not OK with [id], TSC terminates the session. If OK, TSC informs CNC[#] that it can commence the journey, and then inform TSC when successfully completed. There is no further need for TSC to communicate any more for the duration of the trip. At the termination of the trip, CNC[#] informs TSC. TSC then shuts down CNC[#] and probably stores the journey’s details in a database for future data analytics and/or for future repeats of all or part of the journey.
Each Cluster Network Control CNC[#] supervises a pod’s journey traveling through the system from origin to destination. It is initially set up by transport system control (TSC) and subsequently disabled by TSC when the pod has completed its journey, and the CNC[#] information subsequently stored. It mainly communicates with podports and podchargers that CNC[#] has selected for the journey, as shown in
f a dronepod, it lands on a prescribed landing pad, or the trampod stops at a prescribed location. The pod door is opened, and the passenger/s step in or parcels are loaded in. If the weight of the payload is above the maximum allowed CNC[#] informs [id] the weight must be reduced. If not reduced within a certain period, the pod informs [id] that the journey is aborted. If the weight is initially or subsequently within limits, the pod and transport vehicle are designated Pod[id]. Then it informs PP[1] that the payload is ready. PP[1] then instructs Pod[id] to either return to be above PP[1] or enter PP[1] and traverse to a prescribed exit bay, or just enter PP[1] and traverse to the transit bay or the parcel bay for the passenger or parcels to subsequently exit PP[1]. Or the instruction could have been for the passenger/s to enter PP[1] at the passenger terminal or the parcels at the parcel bay, to be subsequently transferred on to the transfer path to an exit bay. Once Pod[id] has either exited PP[1] or is above PP[1], it then transfers to PP[2] possibly via PCs. Pod[id] then follows the prescribed list of PPs and PCs until it arrives at the last podport of the journey, PP[z]. If the passengers or parcels need to be delivered to Destination outside PP[z], Pod[id] departs PP[z] to deliver passenger/s or parcels to Destination, where they are picked up, and the empty Pod[id] returns to PP[z], enters it, and the chassis is parked in the chassis parking bay, or a drone is parked in the drone bay. PP[z] informs CNC[#] which then informs TSC that the journey is complete, and the CNC[#] data is then stored in an external database.
Each podport’s station system control unit can be fairly busy, depending on how many Pod[id]’s have been designated to pass through that podport. Each CNC[#] communicates with all the podports and podchargers along the agreed-to route. If there are several CNC[#]s active at any time, then some of them are likely to involve multiple inclusions of a same podport. Each podport therefore needs to maintain a dynamic list of which dronepods or trampods, or railpods, or carpods are approaching, in sequence. It then deletes the ones that have subsequently exited or terminated the journey in either its passenger terminal or parcel port. The podport’s list will include arriving pods and their transport vehicles. This list can be updated at short notice, as passengers or parcels can be arriving from the access road at any time. An internal list for each podport is needed of pods presently inside the podport and their location relative to markers by the transfer path. This will include the state of charge of each carpod’s pod along the transfer path, and carpods, drones and chassis parked in their parking bays. Then another list is created of the departing pods’ transport vehicle, next podport, podway markers between this podport and the next, and podchargers between this podport and the next.
The 4-trampod exits the tramstop and travels along the tramway to the next junction where it ascends and turns right on to an overhead rail that traverses past the mainpodport. Just before the podport an overhead rail branches off into the podport, which the 4-trampod takes, and enters the mainpodport as a 4-carpod. At the pre-selected entry bay, the 1-carpod with the commuter is released down the transfer path and at the same time the pod’s battery is charged. The carpod enters the pre-selected exit bay. A drone flies from the parking bay and lands on the carpod, the chassis detaches and drives to the chassis parking bay. The fully charged dronepod then exits the podport and flies the commuter along droneways to the office and lands on a prescribed landing pad. The commuter exits the pod.
The dronepod then ascends to the pre-selected droneway. CNC[#] knew that the dronepod would not have sufficient charge to return direct to the mainpodport, so routes the dronepod along droneways to one that passes by a pre-selected podcharger, where it engages with it. The dronepod’s pod is then fully charged as it traverses the slider, and then disengages from the podcharger. The dronepod then follows the pre-selected droneways back to the mainpodport where it enters to a pre-selected entry bay. A 1-chassis had already driven from the chassis parking bay to the entry bay, which the dronepod lands on and attaches to the chassis. The drone disengages and flies to the drone parking bay. The carpod drives to the carpod parking bay. CNC[#] is informed the journey is complete and informs TSC.
Upon exiting a PP, if a dronepod, it then rotates determined by GPS heading and climbs vertically to a specified height above ground to the prescribed droneway, maintaining that height within a specified few feet. Droneways may be at different heights above ground level, depending on direction etc. If instead of a dronepod, a carpod will drive out of the PP, pass a marker, and join either a tramway or overhead rail or a tunnel.
Just before the xpod exits PPn, PPn informs CNC[#], which Acks OK (acknowledges receipt of info). The details transmitted include all the podways, PCs, and markers or beacons, their headings, and ETAs along the hop. The markers or beacons have unique identifiers so there can be no confusion of location, the pod knows exactly where it is. The xpod approaches a marker or beacon using its GPS, its camera, or ultra-wideband (UWB), to recognize the marker, and a radio signal probably using 5G also confirms in case of bad visibility, to determine it is the correct marker. Droneways, tramways, or overhead rail, change headings at each marker.
For droneways a few hundred feet above ground level, these markers could be beacons as with aircraft, such that a dronepod flying towards the beacon detects the beacon id expected and makes the relevant turn to the next droneway heading, following the GPS prescribed route, including adjusting for wind. Instead, on tramways, overhead rail, tunnels, and roadways, the markers can be a small pole with a unique id marker such that the chassis’ sensors can detect the id either visually or by RFID or WiFi or UWB or some other means. The xpod then turns into the new heading on overhead rail or tram tracks and checks with its GPS the direction to the next marker.
The podway directions shown are in 5° steps but could be more accurate in use. The podway parameters are podway #, direction, start node, end node [endway], and height above ground for a dronepod. Also, for the traverse along a podway, the CNC[#] and ETA at the endway of a podway define the timing. TSC initially sets up the PPs to get from Origin to Destination. TSC checks the weather including wind and estimates which PCs to include. CNC[#] then requests the PPs involved to confirm PCs along the hop. Each PP then selects based on P’s or the parcel operator’s preference, the PCs, and marker-beacons (M) along the way and informs CNC[#], which will manage the Pod[id] along the hop.
Podport PPn has already been primed for arrival of Pod[id] by CNC[#] and has been provided with info on the next PPn+1. PPn knows the PCs between the two PPs. PPn will also know if Pod[id] has enough battery charge to reach PPn+1 safely, including charging at PCs, and taking into consideration local weather. PP[1] awaits CNC[#] to start Pod[id]. Each PPn+1 awaits PPn to signal Pod[id] has started the hop. The last PP knows to inform CNC[#] when Pod[id] has completed the journey.
Each PP now has a list of the PCs and markers along the hop, the ETA for each, and the type of transport vehicle for that hop, whether 1-,4-dronepods or 1-,4-trampods, or 1-,4-railpods.
CNC[#] then instructs each PP on the route to set up every PC along the hops between PPs. All are made aware of the calculated ETAs of Pod[id] at all PCs or markers between the two PPs.
At PP it enters an available entry bay and lands on a chassis that has already autonomously driven from the chassis parking bay. The drone detaches and flies to the drone parking bay. The remaining carpod exits the entry bay and travels down the transfer path, recharging while transferring. It arrives at an available exit bay where it exits to head along Podway[5] as a railpod to PP[5] on an overhead rail, informing CNC[1].
Upon arriving at PP[5] it enters an available entry bay and a drone from PP[5]’s drone parking bay attaches to the top. The chassis detaches and parks in the chassis parking bay and recharges. The dronepod exits PP[5], informing CNC[1], and heads along Private_Podway[2] to above the office where it descends on to a prescribed landing pad. The passenger exits and the dronepod returns to PP[5], the drone detaches and parks and recharges in the drone parking bay. The remaining carpod drives to the carpod parking bay where it recharges. PP[5] informs CNC[1] the journey is complete and CNC[1] informs TSC, which shuts it down and stores the CNC[1] info in a database for future use.
The railpod enters an entry bay in PP[5], transfers as a carpod and recharges along the transfer path to an available exit bay, where a fully charged drone flies from the drone parking bay and attaches to the top. It then lifts off and detaches from the chassis which drives to the chassis parking bay to be recharged. The dronepod exits PP[5] and PP[5] informs CNC[2]. The dronepod flies along Podway[8] at 125° to M[3] where it slightly redirects and may change height to Podway [8] at 130° to PP[6]. When the dronepod arrives above PP[6], it informs CNC[2] and flies along Private_Podway[3] to the office, where the dronepod lands on a landing pad. The parcels are removed, the parcel operator closes the pod door and the dronepod ascends to Private_Podway[3] again and returns to PP[6]. It enters the prescribed entry bay on to a waiting chassis and the drone detaches and flies to the drone parking bay to be recharged. The carpod parks in the carpod parking bay and recharges. PP[6] informs CNC[2] the journey is complete, and CNC[2] informs TSC, which shuts down CNC[2].
The dronepod enters PP[4], to an available entry bay that has a waiting fully charged chassis driven from the chassis parking bay. The dronepod attaches to the chassis and the drone detaches and flies to the drone parking bay to be recharged. The remaining carpod autonomously drives and recharges along the transfer path to the prescribed exit bay, where it informs CNC[3], exits PP[4], and ascends up to an overhead rail to PP[5]. Upon arrival at PP[5], the railpod enters as a carpod and transfers and charges along the transfer path to an available exit bay. The carpod exits PP[5] which informs CNC[3] and ascends to an overhead rail to M[3] along Podway[8] at 130°. Then it descends to Podway[11] at 070° on a tramway to PP[7]. It enters PP[7] as a carpod and enters either the transit bay if a passenger or the parcel bay. In either case the passenger or parcels are removed, the empty carpod drives to the carpod parking bay to be recharged, and PP[7] informs CNC[3]. CNC[3] informs TSC which deletes it, while saving the data of CNC[3].
If the number of podports and pods proliferate, it will become increasingly likely that pod collisions could occur at merging podways. If two pods, both attached to the same type of transport vehicle on two different podways, merge on to a single podway, they will be candidates for a collision. A minimum distance between merging pods needs to be determined that allows one pod to be delayed or slowed down so as not to collide with the pod now in front. Too big a gap between the pods will cause more delays and slow down the entire system. The problem is how much to slow down or delay the pod behind.
There are two implementation methods that could be adopted to determine the delay. The easiest is to use sensors already in the pod and transport vehicle that control the transport vehicle drive motors to prevent collisions and maintain the pod on its prescribed course. The sensors must be able to determine the distance between the pods so that a calculation can be made for the amount to slow down. On-board camera sensors will need to be able to determine distance to the pod in front. Lidar sensors will give much better accuracy if installed.
The second implementation uses the knowledge held by the CNC[#]s and PPs as shown in the tables in
To calculate a delay, the trailing pod, if it is less than the minimum delay behind the lead pod, needs to be delayed from the lead pod by the minimum gap. For example, for two ETAs on different CNC[#]s, using the same type of transport vehicle, with a predetermined gap less than the minimum, the delay needs to be increased to the minimum allowed. To avoid delaying a pod already on a podway, it may be easier and safer to delay the pod in the previous podport’s exit bay, where the delay does not affect other pods. The delay is set in the previous PP, such that the delayed pod arrives at the merging PC or M the minimum gap time behind the leading pod, ensuring no collision can occur. The ETAs of the succeeding PPs, PCs and M along the route also need to be extended by the same amount. This delay calculation can be demonstrated using the example routes shown in
Each PP is given the xpod information such as time of starting the podway so that CNC system management can fit the xpod in with all the other xpods controlled by other CNCs in the same podway at a similar time.
Each time a new CNC is set up, the check is done and CNC[1] ETAs are checked with CNC[2] ETAs, then with CNC[3] ETAs. If only three CNCs, then CNC[2] ETAs are checked with CNC[3] ETAs. Then if a gap less than the minimum specified, say 10 seconds, is found, the preceding podport of the slower offending xpod, the xpod is delayed exiting the podport by the calculated amount, the succeeding hops need to be delayed by the same amount.
From
For merging of xpods at markers or PCs, first check for the same consecutive markers/PCs in other CNC routes, then if any, check their ETAs at the matching markers. If a collision between two of the same transport types is likely, delay one xpod at the start of its previous PP, giving priority to requests for fastest. If no priorities, then delay the xpod most likely to arrive last. Plan for xpods to arrive a minimum gap time of say 10 seconds apart initially. For example, at 72 km/h= 20 m/s (= 45 mph) the trailing xpod will need a minimum of 200 m spacing between xpods. Any spacing shorter than 200 m requires the trailing xpod to delay starting from the previous PP until 10 s after the leading xpod.
A possible solution for inserting a delay where needed is shown in
In the routes, there is one combination where a delay is needed. This is for CNC[1] and CNC[3] at PC[1], where the transport is a dronepod and the ETAs are 9:33:36 and 9:33:30, a difference of 6 seconds, which is less than 10 seconds. A delay of 4 seconds is therefore inserted at PP[3] for CNC[1]. Then all subsequent ETAs need to be extended by 4 seconds all the way to the end, which is the office . The table is updated each time a new route is submitted, and each time a CNC is completed it is deleted from the table.
TSC creates and deletes cluster network control modules, CNC[#], that control each route previously defined and agreed to by the passenger or parcel operator while setting up the journey. Each cluster control module manages its own route, with links to each selected podport and podcharger along the route. This enables each CNC to trigger the start of the journey, and to know the status of the pod as it exits each podport or podcharger along the route. It then indicates to TSC when the route has been completed. TSC may store the route’s information for future use, and then it shuts down the module. Each podport is provided with the incoming pod’s information and manages the transfer of the pod through the podport. The transporter comprises a pod attached to a transport vehicle which may be either an intelligent drone or chassis. The latter can operate as either a tramped, overhead railpod, or a carpod, depending on the track’s grade or if it is a road. Also inside the podport, the carpod travels on a transfer path that charges the pod while traversing the podport. The transport vehicle is attached and detached to the pod while only in the podport and can not change vehicle type at a podcharger or a podway marker. But a tramped can become a railpod or carpod or the reverse sequence at a podcharger or podway marker, just by transferring from overhead rail to rail at grade or a road.
Podports are linked together by one or more podways, and the transporter follows the podways along the hop between podports. The transporters travel autonomously along the route, but also can detect other transporters of the same type merging on to the same podway and take necessary avoidance by delaying the trailing transporter. This can be minimized by pre-calculating the ETA of merging same transporter types and delaying the expected trailing one before it exits the previous podport.
The system supports both transport of passengers and parcels operating seamlessly and remaining in the same pod throughout the journey. It also ensures each pod has enough charge to reach the next podport, including the use of podchargers along the hop.
Thus the whole transport system supports passengers and parcels, multiple selectable transport types, unlimited journeys of any length, fast response, and easy upgradability.
In conclusion, a fairly complicated local transport system can be developed by upgrading from a simple parcel delivery system, allowing intermixing of drone transport, tramways, overhead rail and eventually carpods on legacy roads, transporting passengers, parcels, light goods, urgent mail, etc.
In yet another embodiment of the present invention exchange stations with different characteristics than thus far described are provided, in particular to serve air taxis, which are described below as a form of eVTOLs.
There has recently been some introductions of prototype small eVTOLs as electrically powered aircraft that have vertical take-off and landing capability, enabling them to function as air taxis. By definition air taxis infer short-range usage, so they are ideal for short haul flights, such as linking to airports or flying across town. This means they will be flying in built up areas - there will therefore be a requirement for very small size airports. Very small airports mandate the need for operation without a runway, requiring vertical take-off and landing usage, with minimal noise.
The majority of the air taxis proposed so far have wings such that during horizontal travel they offer increased range and higher speed, compared to using horizontal rotors-only aircraft. The use of wings requires some or all of the rotors to be able to rotate to a vertical aspect for regular flight or to rotate to a horizontal aspect for take-off and landing. An advantage of electric motors is that they are much quieter and more efficient than the ubiquitous internal combustion engine (ICE) approach used for helicopters and are more environmentally acceptable. Maintenance should also be lower cost because electric motors have a lower number of moving components than ICE -powered aircraft.
Advent of air taxis has been possible because of the increasing capability of lithium-ion batteries, and new designs of electric motors, as well as much lighter composite materials for the fuselage and wings.
On the negative side, slow charging of the batteries is presently an issue, but this is expected to significantly improve in the next few years. Vertiports will need to support charging of the batteries, so a local high power-source is needed - preferably a nearby electricity substation or transmission line.
This new type of airport using eVTOL aircraft is termed in this specification a vertiport, and these are now being defined and designed for eVTOLs that are planned to be introduced by 2025. In a Vertiport there will be a passenger terminal for checking in and possible security, connecting to an arrivals and departure lane for road access. The passenger terminal initially could be on the same floor but as usage increases there may be a need to locate the passenger terminal on the floor below. There may also be a need for a parcel bay, to support high speed local delivery of parcels or urgent goods, linking to a delivery and collection lane. It will also be advantageous if local public transport could link to the vertiport, such that passengers could autonomously transfer to an airport, a tram or rail system, or to an overhead rail link, as well as to roads. This will depend on the site of the vertiport. Also mandatory will be a charging system to charge the batteries of the eVTOLs. A vertiport system control unit will manage the vertiport. There will probably be a maintenance and repair shop.
A first version of a Vertiport may be with just air taxis that can later evolve into supporting trams and overhead rail, making upgrading easier. After arriving over the vertiport, an air taxi descends vertically onto a selected pad, and take off vertically and then fly horizontally to a destination.
This basic configuration thus far described may be adequate for a while, but as usage continues to increase the layout will become cumbersome with passengers everywhere and will be even more crowded with transportation of parcels. One way to remove clutter of passengers would be to allow an automatic link to an autonomous carpod to pick up passengers as they deplane and transport them autonomously to the terminal, or alternately to take passengers checking in at the terminal to the selected landing pad. Also, depending on local usage, many of the passengers will need to link to a larger airport or a railway station. Again, it would be beneficial for an autonomous carpod to take these passengers to the airport or station, or from the airport or station to the pad. These same needs also apply to parcels.
In this example, passengers transfer (in the same pod) on the landing pad and do not step foot on the transfer path. They stay in the same pod on the same pad during change of transport vehicle, which is much more convenient, comfortable, and faster. In the busiest cases, dronepods could all arrive or depart at close together times, without overloading the system.
One approach to satisfy these needs is to allow the passengers to remain in a pod for an entire journey. This would mean the air taxi would comprise two components, the pod and a drone that latches to the roof of the pod, as shown in
Note that the chassis can be fitted with tires so it may be driven on a hard surface including a road, but also on an overhead rail or tramway dedicated to transporting perhaps one, two or four passengers autonomously.
Also, depending on local usage, many of the passengers will need to link to a larger airport or a railway station. Again, it would be beneficial for a small autonomous carpod to take these passengers to the airport or railway station. The same is true for parcels. The carpods, if designed correctly can have versatile usage. First, they are ideal within the vertiport for transferring passengers or parcels via the transfer path. Second once outside the vertiport they can become trampods or railpods if driving autonomously along dedicated hardened tracks with their sensors detecting the marked track and objects ahead. Third they can be trampods or railpods once outside the vertiport.
One approach to satisfy these needs is to allow the passengers (or parcels) to be in a pod the entire journey, as shown in
In all cases the passengers stay in the pod the entire journey, which is very convenient, and has many other advantages.
Optionally linked to the transfer path are a link to an overhead railway carrying railpods, and a tramlink to an external tramway carrying trampods. This linkage allows any arriving dronepod to enable all passengers in a pod to transfer to an overhead rail system, or a tramway system, without leaving the pod, because the carpods on the transfer path become railpods or trampods at either of the stations, without leaving the pod. All three types of vehicle are identical, apart from their usage, as shown in
These linkings of drone and pod to form a dronepod, and chassis and pod to form a carpod, can take place on a landing pad on the vertiport. The pads must be FAA or EASA/CAA compliant, which basically requires all aspects of the dronepod (and by implication a carpod) to fit within the dimensions of the pad in all directions.
In these applications the podport type of exchange station is ideal. Transfers between air taxis or drones and overhead rail or trams can be autonomous, allowing passengers or parcels to be transferred while remaining in the same pod, all paid for in advance on the same pre-purchased ticket. Passenger dronepods may be directed to pads with easy links to the passenger terminal and parcel dronepods may be directed to pads with easy links to the parcel bay.
The next three figures show different types of transfer operations. As well as dronepod to carpod transfers, it will also be possible for different drone sizes to exchange a pod with each other, as shown in
The skilled artisan will understand that the embodiments described in this disclosure are exemplary and may be implemented in a variety of ways other than as explicitly detailed I these examples. The scope of the invention is limited only by the claims.
The present application is a Continuation-in-Part (CIP) of co-pending application 17/683,677, filed on Mar. 01, 2022, which is a CIP of application 16/725,745 filed on Dec. 23, 2019, which claims priority to provisional patent application 62/785,088, filed Dec. 26, 2018, and also claims priority to provisional patent application 63/155,479 filed Mar. 02, 2021. All disclosure of the parent documents is incorporated at least by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62785088 | Dec 2018 | US | |
| 63155479 | Mar 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17683677 | Mar 2022 | US |
| Child | 17953057 | US | |
| Parent | 16725745 | Dec 2019 | US |
| Child | 17683677 | US |
