Autonomous Vehicles – Christopher Charles Martenis, Amazon Technologies Inc

Abstract for “Autonomous delivery transportation network”

“Aspects a autonomous delivery network for the delivery items are described. A central management system directs the operation and delivery of vehicles through the network. The system may receive a request for transport, including data about the pickup and delivery locations, as well as information about the item attributes. To find a compatible vehicle, the system examines the service routes of vehicles within the network. The system estimates the delay in the vehicle’s existing service route based on pickup and delivery locations. If the delay is acceptable, the system assigns the vehicle to service your request. If the system determines that the delay is unacceptable it may send a new vehicle to join its network. Client devices may also be notified by the system about various aspects of service, including estimated pickup and/or delivery times.

Background for “Autonomous delivery transportation network”

“The need for transportation in urban and suburban areas is growing.” These transportation needs include individuals’ commutes to work, school, shopping malls, and other places. Transporting items between different locations is also part of the transportation requirements. Some municipalities have created public transportation systems to meet these needs. The public transportation system generally uses buses and vehicles to transport people between stops along a predetermined route at predetermined times.

As noted, transportation needs continue to increase in both urban and suburban areas. These transportation requirements include the ability to travel to work, school, shopping centers, and other locations as well as the ability to transport goods between different locations. Some municipalities have created public transportation systems to meet these needs. These public transportation systems use vehicles that follow predetermined routes at predetermined times. These public transportation systems are not only able to meet some passengers’ needs but also have significant disadvantages. The public transport systems are limited in terms of cargo and passenger pickup and drop-off locations. Many times, passengers might not be within walking distance to a service location. The pickup and drop-off times for the system may not be convenient or appropriate.

“In this context, we will describe aspects and embodiments for autonomous transportation networks. Many of the above problems can be addressed by autonomous transportation networks, which offer on-demand transportation services to and from almost any place accessible via surface streets. One central management system for such a transportation network can be used to optimize the routes of multiple vehicles within a network of transport vehicles for efficiency and account for changing service levels. The current service demand may allow vehicles to be added or removed from the network, which will help avoid wasted resources in low-demand situations. The autonomous transportation networks can also be used to transport tangible goods, such as groceries, and other items.

“FIG. “FIG. The networked 100 comprises a computing environment 110 and a network 150. Vehicles 10-16 are illustrated at different locations on the map. FIG. FIG. 1 shows that the computing environment 110 contains a transportation network data storage 120 and a central management software 130.”

“The vehicles 10-16 can be described as any type vehicle, including, but not limited, bikes, carriages and cars, trucks, vans or buses, no matter how powered or driven. The vehicles 10-16 can be collectively referred to as a network transport vehicles. Each vehicle 10-16 has an autonomous vehicle controller, which controls its maneuvering on roads, highways and skyways. The vehicles 10-16 have autonomous vehicle controllers that communicate with the central management 130 over the network 150. They receive pickup, delivery, and any other location information to help determine service routes.

“The vehicles 10-16 can be used to transport any item that is capable of moving, including people, tangible items, and groceries. FIG. FIG. 1 shows that the vehicles 10-13 travel along routes 20-23. The route 20 includes stops 20A-20C; the route 21 includes stop 21,A; the route 22 includes stops 22A-22B and the route 23 includes stop 23,A. The vehicles 14-16 do not operate according to specific routes and may be waiting for instructions from central management 130. The vehicles 14-16 could be considered unallocated or available resources in the transportation network.

“As explained in more detail below, the central management system 130 can receive telemetry data for each vehicle 10-16. Telemetry data could include operating parameters data from the vehicles 10-16 such as passenger and cargo capacities, planned stops data, fuel level, system diagnostic data, and so on. These telemetry data can be stored in the transportation data store 120 to allow central management system 130 to reference them.

“Before we move on to a more detailed explanation of the components and operation 100 in the networked environment, please refer to FIGS. 2A-3C for a brief description of the operation. 1. One example is that a client device can send a request to transport 30 to the computing environment 110 over the network 150. The request 30 could include information such as a pickup location 31 and destination location 32. It may also include information about the number of passengers. Geolocation information may be used to identify the pickup and destination locations 31 or 32.

“In response to the 30th request, the central management system 130 has been configured to identify the vehicle 10-16 that is compatible with the 30th request. The central management system 130 can analyze the service routes 10-16 and identify the vehicle with the passenger capacity and service route that is compatible with the request. An existing service route is compatible with the request, if it can be integrated into an existing route without causing additional delay to the current pickup/destination locations. The request can be considered compatible if it is located sufficiently close to the pickup and/or destination locations of the existing route to cause no delay beyond what is allowed under a service level agreement. The central management system 130 could identify the route 22 for the vehicle 12 as compatible with the request 30 because the pickup and delivery locations 31 and 32 are substantially aligned or along the existing route 22, Based on the comparison of the passenger count in the request 30 with the available vehicle capacity, the central management system 130 could identify the vehicle 12 to be compatible with (e.g. capable of handling) the 30.

“Once vehicle 12 has been identified by central management system 130 and is compatible with request 30, central management system130 may determine if the assignment of vehicle 12 to request 30 will cause an unacceptable delay to passengers or cargo in the vehicle 12. The vehicle 12 can carry multiple passengers to drop off at 22A and 22B. This information is available in the transportation network database 120. In one embodiment, the central management 130 could estimate a delay in the vehicle’s existing service route 22 based on the pickup and destination locations 31-32 in route 22. The modification of the route 22 to include pickup and destination locations 31-32 may result in a delay for passengers destined to the destination 32.

“The central management 130 may compare the delay in route 22 with one of the service level parameters or the autonomous transportation network to determine if it is acceptable under the circumstances. The central management system 130 may allow the vehicle 12 to be assigned to service the request 30, and may communicate to the vehicle the pickup and drop-off locations 31 and 32. The vehicle 12 can then store the pickup/drop off locations 31-32 in a location memory, and update the route 22 with the new locations. The central management system 130 can request another vehicle 10-16 to serve the request 30 if it is not acceptable. The central management system 130, for example, may dispatch the vehicle 14 in order to service the request 30,

“Service level parameters for an autonomous transportation network could be defined as minimum or maximum service delay times, or similar service level metrics. Other aspects of the service level parameters could relate to operating and/or charge costs, time, holiday, event constraints, weather conditions, road conditions or traffic. The central management system 130 can assign one of the vehicles 10-16 according to route compatibility. This is based on different operating and/or maintenance level parameters.

“If vehicle 12 is identified by central management system 130 and assigned for service to the request 30, central management 130 can further configure central management system 130 to calculate the estimated pickup time until vehicle 12 arrives at pickup location 31. A client device may be provided with the estimated pickup time and an identifier for the vehicle 12 by the central management system 130. The user who submitted the transportation request 30 may be notified that the vehicle 12 has been assigned and that the estimated pickup time is 31 minutes.

“In some embodiments, the central managing system 130 may also be used to perform additional maintenance or/or housekeeping activities within the autonomous transportation network. This includes verifying passengers, opening doors and compartments 10-16 under different circumstances, receiving vehicle telemetry data 10-16, processing payments for users, analyzing it, and storing it, as well as receiving maintenance requests 10-16 and responding to them.

“A network of transport vehicles may also include vehicles with cargo bays or compartments for items that can be stored for autonomous delivery. One or more vehicles 10-16 may have cargo bays or compartments that can store items for transport and delivery. The central management system 130 may direct such vehicles to pick up locations. Items are then stored in the cargo bays, and directed to drop-off locations along the service route for delivery. An individual could send a request 40 for delivery to the computing environment 110 through the network 150. The request 40 could include information such as a pickup location 41 and a destination location 42. It may also contain a description of the item to be delivered. Geolocation information, such as latitude and longitude, may be used to identify pickup and destination locations 41, 42. The central management system 130 can then direct the vehicle 15 to stop at the pickup location 41 to pick up the item and deliver it to the delivery address 42. The central management system 130 can also verify that the recipient of the item is at or near delivery location 42. It may allow access (e.g. unlock) to the cargo bay or compartment in the vehicle 15 where the item is stored.

“As mentioned above, autonomous transportation networks may address some of the shortcomings of public transport systems. Autonomous transportation networks offer transportation services to and from almost any location. They generate optimized routes for multiple vehicles within a network of transport vehicles for efficiency. This allows for the accounting of service level parameters that may change over time. The autonomous transportation networks can also be used to transport tangible goods, such as groceries, and other items.

“Turning towards FIG. 2 shows a detailed view of the networked environment 100. Illustration 1 The FIG. 1, FIG. 2, FIG. FIG. FIG. 2 shows user profiles 122, transportation data 124 and vehicle telemetry data 126, among other data that can be stored in transportation data store 120. FIG. FIG. 2 also shows a request manager 132, service route analyzer 134 and telemetry monitor136. Network maintenance supervisor 138 is part of the central management software 130. A transportation network interface engine 140 is part of the computing environment 110. FIG. 2 shows the vehicle 10, which is representative for the other vehicles 11-16. 2. This illustrates an autonomous vehicle controller 182, which includes a location queue, 184, and a cabin accessibility mechanism 186. FIG.

“It is important to note that components of the computing environment 110, and the vehicle 10 shown in FIG. 2 are only representative examples and are not meant to be comprehensive or limitative. The computing environment 110 may have additional or alternative elements, components, and features than those shown in FIG. 2.”

“The computing environment 110 can be represented as one or more computers or computing devices or computing systems. The computing environment 110 could include one or more computing devices, such as those that are arranged in one or more servers or computer banks. The computing device (or devices) may be located in one location or spread across multiple locations. Further details are provided in the following connection to FIG. 6 may contain a number of computing devices that collectively comprise a hosted computing resource or a grid computing resource and/or another distributed computing arrangement. The computing environment 110 could be described as an elastic computing resource, where the allotted processing, network, storage, and other computing-related resources change over time. The computing environment 110 can also be implemented in part as functional and/or logical elements (e.g. computer-readable instructions, device, circuits, processing circuits, etc.). Elements that direct the computing environment 110 in accordance with the embodiments herein. Below is a detailed description of how each component of the computing environment 110 works.

“The client device 160 represents one or more clients that individuals may rely upon to request transport and/or delivery services. Any type of computing device, processor circuit, or processor-based device or system may be included in the client device 160. This includes personal digital assistants, personal computers, laptop computers, tablets, and cellular phones. One or more subsystems or devices may be included in the client device 160, including wireless communications transceivers and GPS receivers, orientation or acceleration sensors, and others. One or more peripheral devices may be included in the client device 160. The peripheral devices could include a keyboard, keypad touch pad, touch screen or touch screen as well as one or more input devices such a microphone, camera, keypad, touchpad, touchpad, touch screen or touch pad.

“The network monitor client 170 represents one or more client devices. Any type of computing device, processor circuit, or device or system may be embedded in the network monitor client device 170, including a desktop computer or laptop computer, a personal computer assistant, a cell phone, or tablet computer. One or more peripheral devices may be included in the network monitor client device 170 for user interaction. The peripheral devices could include a keyboard, keypad or touch pad, microphone, camera, and/or touch screen.

“Turning back to the vehicle 10, autonomous vehicle controller 182 can be represented as analog, digital or mixed analog-digit processing circuitry, memory that directs the operation of both the vehicle 10 (and the electromechanical drive system, 184) of the vehicle 10. The autonomous vehicle controller 182 can be described as an embedded real-time control device in which control outputs are generated in response to control input conditions. The control system 182 can include various sensors such as radar, cameras, laser Illuminated Detect and Range sensors (LIDAR), and others that may be used to analyze the surrounding environment and generate control signals for the drive system 184. The autonomous vehicle controller 182 can, in some embodiments, perform the processing required to control and operate the vehicle 10, either alone or with other computing systems such as the drive system 184, computing environment 110, and other devices and systems.

“The autonomous vehicle controller 182 could include memory areas that store data used for navigation, such as road data or street view data. To determine the most suitable route, the autonomous vehicle controller 182 relies on feedback from its sensors and drive system 184. The central management system 130 may communicate the pickup, destination and delivery locations to the autonomous vehicle controller 182. These information are stored in the location queue (183) as described herein.

“Among the various embodiments, the autonomous car controller 182 can be integrated with the vehicle’s drive system 184 in any way that allows the autonomous vehicle control 182 to control all aspects of the vehicle 10, including turning, acceleration, signal, and lamp operation. The autonomous vehicle controller 182 can be integrated with the vehicle’s drive system 184 in any manner that is suitable.

“As shown in FIG. 2. The location queue 183 is part of the autonomous vehicle controller 182. The autonomous vehicle controller 182 may include the location queue 183 as a memory area that stores waypoints or geographic locations. The central management system 130 may communicate the locations to the vehicle 10, such as the pickup, destination and delivery points, and separate central management system 130 stores them. The autonomous vehicle controller 182 can be used to determine the best route for the vehicle using the location information. Once a destination has been reached, the autonomous vehicle controller 182 may remove a location from the location queue 383 and the vehicle 10 can proceed to the next stored location. The autonomous vehicle controller 182 can operate independently, or at least substantially independent from the central management 130 once it has been provided with one or more locations through which a route could be determined. The central management 130’s primary concern is to optimize the routes of the vehicles 10-16 in the autonomous transportation network. However, the autonomous vehicle controller 182’s primary concern is to direct the vehicle 10 according the central management 130’s pickup, destination and delivery locations.

The drive system 184 could be described as the powertrain, associated electrical, mechanical and electromechanical systems, and associated control, diagnostic, and management systems for the vehicle. The drive system 184 could include one or more motors, transmissions and steering systems. The autonomous vehicle controller 182 directs the vehicle 10, as the drive system 184 does.

“The cabin accessibility mechanism 186 could be defined as the mechanisms that allow access to the passenger compartment of the vehicle 10, such door locks, power doors, and so forth. The central management system 130 may direct the cabin access mechanism to open and close one or more doors in the passenger cabin.

“The cameras 191 could be described as one or more cameras with a field view inside the vehicle’s passenger cabin and outside the vehicle. The cameras 191 may transmit still images and/or videos from the vehicle 10 into the computing environment 110. This data may then be stored in the vehicle telemetry information 126. The central management system 130 may use the images and video to monitor the operation of autonomous transportation networks and provide operational awareness information to operators. Video monitoring and continuous recording can be used to monitor the vehicles inside and out 10-16. GPS receiver 192 can be described as a receiver that receives and demodulates global positioning system beacons, and identifies the geographical location of vehicles as they move between places.

“The cargo compartments 194 can be described as one or more cargo compartments or cargo bays that store items for autonomous delivery. Items may be stored securely in the cargo compartments 194 for transport and delivery by vehicle. Each cargo compartment 194 can be separated by having an access door that is similar to security locks boxes. The compartment access mechanisms (196) can be used to control individual doors. Access mechanisms for compartment access 196 can be either electromechanically or mechanically locked or unlocked. They also have access mechanisms that allow controlled access to one or several cargo compartments 194. The central management system 130 can direct the compartment access mechanism 196 to unlock or open one or more cargo compartments 194. After verifying the identity and recipient of an item, package or other package contained in them, it may also be described further below. This verification can be done by exchanging a secret code or another verification code, client device authentication, facial, biometric, or any other means.

“In different embodiments, the cargo compartments 194 may be larger or smaller to allow for transportation of larger or less heavy items. The central management system 130 can store data that represents the vehicle’s passenger and cargo carrying capacities, as well as the number of items and passengers carried by the vehicle 10, over time. This information is used to determine if the vehicle has the capacity to handle delivery and transportation requests. The passenger compartment of the vehicle 10 may include seating for passengers. However, the cargo compartments 194 can be distinguished. You should note that some vehicles within a network of transport vehicles may not have cargo compartments 194 but instead be designed for passenger transportation only. Vehicles may be designed to transport items or packages only, and they can also be without passenger compartments.

“Returning to the computing environment 110. The transportation network data store 120 contains user profiles 122 and transportation network data 124, respectively, and vehicle telemetry information 126. User profiles 122 contain data about various customers or users of the autonomous transportation system administered by central management system 130. The user profiles 122 can include representative photos or images, usernames and password combinations, names, addresses, billing information, forms of payment information and contact information. When a client device 160 user installs the client app 162, for example, they may be asked to accept certain terms and conditions. They might also be required to create an account in the computing environment 110. For reference by central management 130, the account information of the user could be saved in the user profiles 122.

“Transportation network data 124 contains data about one or more vehicles within a network autonomous vehicles, such the vehicles 10-16 among others. Transportation network data 124 can include unique vehicle identification information (e.g. vehicle identification numbers (VINs), etc. vehicle identification numbers (VINs), etc. Transportation network data 124 could also contain current location information for vehicles 10-16. Global positioning data, such as latitude and longitude, may be included in the location information. This data is typically received over time from vehicles 10-16.

“The transportation network data 124” may include service level parameters that are applicable to the autonomous transportation network. Service level parameters could be described as minimum or maximum service delay times or other comparable metrics for the network. Other aspects of the service level parameters could be related to operating costs and/or charges, time of day or holiday constraints, weather conditions, road conditions, traffic or any other relevant factors. Based on different operating and/or delivery level parameters, the central management system 130 can assign vehicles 10-16 to transport or delivery requests.

“The vehicle’s telemetry data 126 contains measurement and analysis data from the autonomous vehicle controller 182 (of the vehicle 10), as well as other vehicles 11-16. These telemetry data can include data from vehicles 10-16 such as diagnostic trouble codes and door open/closed indicators, fuel efficiency, vehicle speed and RPM, fuel level, trip information, oxygen sensor, onboard computer monitoring and test, vehicle software version and emissions, radar sensor and other data. The vehicle telemetry data (126) may also include still image and/or video feed data from the cameras 191 and 11-16.

“The central management network 130 comprises the request manager, the service route analyser 134, telemetry monitor 136, and the network maintenance coordinator 138. The request manager 132, which is designed to receive transportation service requests, such as the request 30 shown in FIG. 1. Or requests for delivery service such as the request 40 shown in FIG. 1. From the client device 160. Requests for passenger transportation may include information such as a user identifier, information that allows a potential passenger to be identified, a pickup and destination location, number of passengers, or other pertinent information. Requests for transportation or delivery of items may contain item identifiers or manifests or other descriptive information. This information can be used to identify the person requesting the service, as well as a pickup location and a delivery location. A request manager 132 can be configured to access user profiles 122 to retrieve authorization or payment information related to requests for transport or delivery service. This information is based on the information contained in the requests.

“The service route analyzer (134) is able to analyze multiple existing service routes in order to identify a service route and passenger capacity for a vehicle that can be used to fulfill any request. The service route analyzer may, for example, analyze the 10-16 vehicles’ existing service routes. The service route analyzer may be able to estimate the delay in the existing vehicle service route based on the pickup, destination and/or delivery locations for a request. The service route analyzer may also estimate any time delay or impact on an existing transport or delivery route for passengers and items if the vehicle is already in operation. The service route analyzer may determine if the additional delay is acceptable considering the route. This determination can be made by comparing the additional time delay to at least one service parameter of the autonomous transport network operated centrally 130. Below are further details about service level parameters with reference to FIGS. 3A-3C.”

The request manager 132 can assign the vehicle to service the request. They will also communicate to the vehicle the pickup, destination and/or delivery addresses. If the additional delay is unacceptable for the vehicle with the existing route, the request manger 132 can dispatch a new vehicle to service the request. It is important to note that service level parameters for the autonomous transportation network can be changed over time by network operators using the network monitor device 170. This could cause request managers 132 to rely less on vehicles with existing routes (e.g. ridesharing), or dispatch additional vehicles to improve service levels depending on factors such as operating and/or charge costs, time, holiday constraints, weather conditions, road conditions or traffic or any other relevant factors.

“The request manager 132 is also configured to process payments associated with transportation and delivery service requests. The payment transactions may be processed by the request manager 132 based on billing information or payment information stored in user profiles 122. Transactions may be processed at any time, including when a passenger is picked-up or dropped off by a car, or when an item or service is delivered or picked up.

The telemetry monitor 136, which is designed to analyze vehicle telemetry data (126) received from vehicles 10-16, can be used to monitor and analyze these data. The telemetry monitor 136, in this context, may be able detect dangerous operating conditions or passengers 10-16, verify their location 10-16, and provide a deterrent to crime. It can also visually identify passengers and receivers of items.

“The network maintenance supervisor (138) is able to monitor the vehicles from 10-16. This includes reviewing and monitoring vehicle telemetry data126 to determine fuel levels, service mileage, operating hours, and any other diagnostic information. The network maintenance supervisor 138 can also receive maintenance requests from vehicles 10-16. Requests for maintenance may include requests for different types of maintenance and/or service for vehicles 10-16. The network maintenance supervisor 138 will respond to your requests and direct the vehicles 10-16 to a location to be serviced or refueled.

“The computing environment 110 includes the transportation network engine 140. The transportation network engine 140 can generate different network pages (or other interface elements), which may be displayed as a user interface on client devices, such as the network monitor device 170. One embodiment of the transportation network engine 140 may create network pages as hypertext-based pages that include information about the status of the autonomous transport network managed by the central management systems 130. The transportation network interface engine 140 can also generate a user interface that allows for administration and control of the autonomous transport network via one or more central management systems 130, 10-16 vehicles, individually.

“Turning further details on the operation and vehicles 10-16, FIGS. 3A-3C show a 300-degree autonomous transportation process in the networked environment 100 of FIGS. 1. and 2. According to an example embodiment the present disclosure. The flowcharts shown in FIGS. 3A-3C can be seen as a group of steps that were performed in the networked environment 100 according one or more embodiments. The flowcharts shown in FIGS. 3A-3C are just one example of the functional sequences or arrangements that could be used to implement the networked environments 100 operations, as described herein. The process 300 is discussed herein in relation to the computing environment 110, and the vehicles 10-16 shown in FIGS. 1, 2 and 3 may also perform the process 300 in other environments or vehicles.

“Referring first and foremost to FIG. 3A, reference numeral 302, is the 300-step process. It involves receiving a request from client 160 for transport or delivery services. FIG. 1. The central management system 130 could receive a request to transport 30 from a passenger. A request for delivery 40 may be made to the central management system 130 at reference number 302. The request may contain a user identifier and a pickup location. It can also include the delivery location, number, passengers, item identifiers and manifests. The central management system 130 can receive a request for modification to a previously submitted request. This modified request could include modified pickup, delivery, and/or destination locations or any other descriptive information. The central management system 130 can also receive telemetry data, such as from vehicles 10-16, throughout the 300-step process, as illustrated in FIGS. 3A and 3B. The central management system 130 may use the telemetry data to make different decisions as described in this article.

“The process 300, at reference number 304, includes retrieving authorization/or payment information related to the request. Based on the user identifier information provided in the request, the central management system 130 may retrieve authorization and/or payment information from the user profiles. The authorization information can include billing information or billing information. The central management system 130 generally retrieves information from the transportation network database 120 at reference number 304 to determine if the request is valid and if it corresponds to a known user. It may also associate billing and/or payments information with the request. The process 300 might return an error message 160 to the client device if the requested information is not retrieved at reference number 304.

“At reference number 306, the 300-step process includes identifying a vehicle within the transportation network compatible to the request at reference numeral 312. Below is a description of the process for identifying the vehicle. Refer to FIG. 3C.”

“Once the vehicle has been located at reference number 308, 300 is the communication process that includes the delivery of pickup, destination and/or delivery addresses to the vehicle. As shown in FIG. 1. The central management system 130 could communicate pickup and drop-off locations 31 and 32 to vehicle 12 based upon the request for transport 30. The vehicle 12 can store pickup and drop-off locations 31 and 32 in its location memory 183, and then update its route 22 autonomously to include the pickup or drop off locations 31 through 32.”

“At reference number 310, process 300 includes the calculation of an estimated pickup time until vehicle arrives at pickup location. As shown in FIG. 1. The central management system 130 could calculate the estimated time it will take for the vehicle 12 to arrive at pickup location 31 or 15 to arrive at pickup location 41, as shown in FIG. The estimated pickup time can be based on a variety of factors such as current and anticipated traffic conditions, vehicle types, distances between vehicles, pickup locations, and current or expected traffic conditions. Referring to reference number 310, process 300 may also include the calculation of an estimated time for the vehicle to arrive at a delivery or destination. The central management system 130 can calculate the estimated delivery or destination times based on a variety of factors such as current traffic conditions, anticipated traffic conditions, types of vehicles, and distances between vehicles.

“At reference number 312, the 300 process includes communicating to the client 160 the attributes of fulfilling the request for service. The central management 130 will assign a vehicle to service the request at reference numeral 312. It may also estimate the pickup, drop-off, and/or delivery times. This information can be communicated to the client 160 by the central management 130. Referring to reference number 312, the central management 130 may send a vehicle identification of one of the vehicles 12-15 (or any other vehicles 10-16, as assigned) and estimated pickup, drop-off, and/or delivery times, for example, to the client 160. The client device 160 can be informed by the central management system 130 that his request for transport or delivery services has been fulfilled. The user might also be able to know when he can expect to pick up the item and drop it off. Alternately, information may be provided by the user about when an item will arrive to him or her.

“In other embodiments the central management system 130 may forward the bar code or quick response (QR), code to the client 160 for display. The bar code or QR code displayed on the client device 160 may be presented by the vehicle 12 to the user. The vehicle 12 can communicate with central management system 130 in either case to verify and compare the verification code, password or fingerprint, facial scan or scanned bar code with expected verification information. Once verified, the process 300 moves to reference number 318. Otherwise, the process 300 awaits reference numeral 318 for at least a reasonable time before a pickup verification can occur before the pickup cancellation is made. Also, the process can be repeated 300 times while waiting for pickup verification at reference number 316 in FIG. 3A), the process 300 continues to FIG. 330. 3B.”

“At reference number 318, the process 300 involves directing the vehicle’s opening. After verification at reference number 314, the central management 130 might send instructions to vehicle 12 to open and unlock a passenger compartment door. The client device 160 may be used as a passenger in the vehicle’s passenger compartment 12 once it has been opened. Alternately, the central management 130 can send instructions to the vehicle 12 to, for example, direct the compartment access mechanism to 196 to unlock or open a cargo compartment 194. An item can be stored in one the cargo compartments 194 once it has been opened. The vehicle can pick up either a passenger or an item for transport or delivery.

“Turning towards FIG. “Turning to FIG. The central management system 130 can review data from the cameras 191, the seat weight sensors embedded with the seats in vehicle 12, and telemetry data from other sensors within the vehicle 12 in order to determine if a passenger or an item were picked up. The process 300 can take corrective actions if the pickup location is not confirmed. This includes sending error messages to client 160 and trying to locate the pickup location. The process at reference number 320 can be omitted in some embodiments.

“At reference number 322, the process 300 involves processing a payment transaction to transport or deliver service. The request manager 132 can process the payment transaction using billing information and/or payment data stored in the user profile 122. You can process the transaction at any time during the 300 process. This includes when a passenger is picked-up or dropped off, or when an item or service is delivered or picked up. The costs of certain embodiments may differ depending on the demand, time of day or holiday, event constraints, weather and/or any other cost factors. Payment transactions can be processed through a bank or credit card.

“At reference number 324, process 300 includes monitoring of the route of vehicle assigned to request at reference numeral 322. The central management system 130 can monitor the vehicle’s progress and may also monitor other vehicles. The central management system 130 can also monitor if the vehicle 12 has arrived at its delivery, pickup and/or drop-off times. The vehicle’s operating status can be monitored by the telemetry monitor 13 as it travels along its route.

“At reference number 326, process 300 includes determining if the vehicle that was assigned to service the request at reference numeral 302 reached its destination or delivery address. The central management system 130 could determine whether the vehicle 12 has reached the destination 32. The central management system 130 can also check if the passenger exited the vehicle 12 at 32. For example, the central management system 130 could send a confirmation message to 160 or a receipt. Another example is that of item delivery. The central management system 130 might determine if the vehicle 15 has reached the delivery address 42. The central management system 130 might then wait for verification of the recipient of an item. This is similar to the verification at reference number 314. Once verified, the central management 130 may instruct the compartment access mechanism (196) to unlock or open the compartment that holds the item. If the vehicle that was assigned to service the request arrives at its destination and completes a drop-off, then the process 300 proceeds to reference number 330. For continued monitoring, the 300 process proceeds to reference number 324.

“Reference numeral 330 is the 300-step process. It includes determining if the vehicle that was assigned to the request still has drop off or delivery locations. The central management system 130 can direct the vehicle to continue to its next destination at reference number 332, if it does not, the central management software 130 may instruct the vehicle. The central management system 130 can also direct the vehicle to park or standby at a specific location while it waits for further instructions at reference number 334.

“Turning towards FIG. 3C is a detailed description of the process for identifying a vehicle that matches the request at reference number 302. FIG. 3C can be considered part 300 of the overall process among FIGS. 3A-3C.”

“At reference number 340, the process involves analyzing a plurality service routes to find a service route that is compatible with the request at reference numeral 302. The service route analyzer (134) may analyse the routes 10-16 of the vehicles (FIG. 1) to determine which one is most suitable or compatible with the request. For efficiency, the service route analyzer 134 may be used to determine which vehicle route is closest to the requested pickup, drop-off, and/or delivery locations. After identifying a vehicle, process 300 moves to reference number 342. This includes determining if the vehicle’s passenger or cargo capacity is compatible with the request. The central management system 130 can determine if the vehicle has enough passenger or cargo space to accommodate the requested number of items or passengers. The process will then proceed to reference number 344.

“Reference numeral 344: The process 300 includes the estimation of a delay to an existing service route for the identified vehicle, with reference to the pickup, delivery, and destination locations specified in the request. The vehicle could be already operating under an existing transport and/or delivery route for items or passengers. The service route analyzer (134) may then estimate the time delay or impact on that route based upon the additional request. The service route analyzer (134) may determine if the additional delay is acceptable for passengers or items that are being serviced using the existing route reference number 346.

Referring to reference number 346, process 300 involves comparing the time delay with one of the service level parameters in the autonomous transportation network. Service route analyzer 134 can compare the time delay to service level parameters to determine whether the delay is in line with other passengers or delivery commitments. Service level parameters can be described as the maximum and minimum service delay time, as well other comparable metrics. Other aspects of the service level parameters could be related to operating costs and/or charges, time of day or holiday constraints, weather conditions, road conditions, traffic or any other relevant factors.

After comparing the service level parameters at reference number 346, process 300 proceeds to reference number 348. This includes determining if the delay is acceptable in accordance with the one or more service-level parameters. If the answer is yes, the process 300 moves to reference numeral 352, where the vehicle identified is assigned to service the request at reference numeral 346 (FIG. 3A). If the delay is unacceptable according to one or more service-level parameters, the process proceeds to reference number 356, which involves dispatching a new vehicle to service the request (e.g., vehicle with no existing route).

Referring to reference number 342, if it’s determined that no vehicles have routes compatible with the request at reference numeral 302. This could be due to a large distance between pickup and drop-off locations or a lack of cargo or passenger capacity. Otherwise, process 300 will proceed to reference numeral 352. This includes determining if optimization of existing routes is possible. The service route analyzer (134) may determine if one or more vehicles (10-16) can be optimized for efficiency or increased service capacities. A modification to the pickup, delivery, or drop-off locations of vehicles 10-16 may be considered optimization. This is done in response to additional service requests, or to improve efficiency. If optimization is possible, the process 300 proceeds as reference numeral 354, which also includes the service route analyser 134 optimizing existing service routes between the vehicles 10-16 within the transportation vehicle network. Otherwise, the process proceeds to reference number 356, which includes dispatching of a new vehicle. In certain instances, requests received at reference number 302 might be denied if optimization is not possible or no additional vehicles are available.

The process 300 can be used to solve the above problems by providing on-demand transportation services to and from almost any place accessible via surface streets. The central management system 130 can optimize the routes of the vehicles 10-16 in a network transport vehicles for efficiency and account for variations in service level parameters. The operator can control or direct the operation 300 via the network monitor client device 170, and the transportation network engine 140 throughout the process 300. You can also add or remove vehicles from the network of vehicles according to current service demand. This allows you to avoid wasting resources when there is little demand.

“FIG. “FIG. 1. and 2. According to different embodiments of this disclosure. One or more computing devices 400 are included in the computing environment 110. Each computing device 400 contains at least one processor, such as a processor 402 or a memory 402. Both of these systems are electrically and communicatively connected to a local interface (406). Each computing device 400 could be, for example, a server computer or other similar device. Local interface 406 could be, for instance, a data bus that has an accompanying address/control or any other bus structure.

“In different embodiments, the memory 402 stores executable-code or data. The memory 404 can store executable code components that are associated with central management system 130. This information is available for execution by processor 402. Other data, such as those stored in the transportation data store 120 may be kept in the memory 404.

“As we have discussed, the memory 404 contains software that can be executed by the processor 402. The terms “executable” and “for execution” are used here. Executable? or?for execution? are used to refer to software forms that can be run or executed by the processor 402. Software forms that can be executed or run by the processor 402. Executable programs can include, for instance, a compiled program which can be translated into machine code and loaded into the random access section of the memory 402. Source code can also be loaded into the random access section of the 404 by the CPU 402, and executed. Or source code that can then be interpreted by another executable to generate instructions in the random access section of the 404. The processor 402 can execute the source code, etc. An executable program can be stored in any part or component of the memory 402, including a random access memory, read-only memory, ROM, magnetic or other hard drive drive, solid-state or semiconductor drive, solid-state or similar drive and executed by the processor 402, source code that can be expressed in an object code format and loaded into a random acces portion of memory 404 and executed by the processor 402. Source code that can be interpreted by another executable program to generate instructions in a random area of memory 404, magnetic tape, magnetic tape, magnetic disk, magnetic tape or other component.

“In different embodiments, the memory 408 may contain both volatile and nonvolatile memories and data storage components. Volatile components do not store data when power is lost. Nonvolatile components retain data even if power is lost. The memory 404 could include, for instance, a RAM or ROM, magnetic, other hard drive, solid-state semiconductor, or similar drive. It also may contain a USB flash drive. A floppy drive can be accessed through an associated floppy drive. An optical disk can be accessed via the optical disk drive. Magnetic tape access via an appropriate tape driver. And/or any other memory component. The RAM could also include, for instance, static random access memory, dynamic random access memories (DRAM), magnetic random access memories (MRAM), and/or any other similar memory device. A programmable, read-only, or erasable, programmable, read-only memory may be included in the ROM.

“Also the processor 402 could represent multiple processors 402./or multiple cores. The memory 404 may be multiple memories that work in parallel or in combination. The local interface 406 could be a network or bus that allows communication between any two processors 402, any processor 402 or any memory 404. It may also allow for communication between the processors 402 and the memories 404. Additional systems may be added to the local interface 406 to facilitate this communication, such as a load balancer, which performs load balancing. The processor 402 could be electrical or any other type of construction.

“As mentioned above, the central management software 130 can be implemented in part by executable-code or software components that can be executed by general purpose hardware. The same could also be embedded in dedicated hardware, or a combination general, specific, or dedicated purpose hardware. Each can be implemented in hardware if it is embodied. For example, a circuit or state machine that uses any combination of several technologies could be created. These technologies include, but not limited to, discrete circuits with logic gates that implement various logic functions upon application of one or several data signals, application-specific integrated circuits (ASICs), which have appropriate logic gates, FPGAs, or other components. These technologies are well-known by all who are skilled in the art. Therefore, they are not discussed in detail in this article.

“The process flowcharts or flowcharts in FIGS. 3A-3C represent certain functions and operations that are discussed in this document. Each block can represent one or more steps or executions within a process. Alternately, or in addition, each block could represent a module or segment of code, which includes instructions for implementing the specified logical function. Program instructions can be represented in source code. This may include human-readable statements written using a programming language, or machine code that contains numerical instructions that are recognizable by a suitable execution platform such as the processor 402. The source code can be used to convert the machine code. Each block can also represent, or be connected to, a circuit, or a series of interconnected circuits, in order to implement a particular logical function, process step, or combination thereof.

“Even though the process diagrams and flowcharts shown in FIGS. While FIGS. 3A-3C show a particular order, it’s possible that the order might be different. An order for execution of multiple blocks can be altered from the one shown. You can also see two or more blocks in succession in FIGS. 3A-3C can be executed simultaneously or with partial concurrence. In some embodiments, one of the blocks in FIGS. You can skip or omit blocks 3A-3C in some embodiments. For purposes of enhanced utility and accounting, performance measurement or troubleshooting, you can add any number of counters or state variables to the logical flow. All such variations are included in the scope of this disclosure.

“Also any logic or application described in this document, including central management systems 130, that is embodied at least in part by software or executable code components, may also be embodied in any tangible and non-transitory computer readable medium or device for execution via an instruction execution system like a general-purpose processor. The logic could be described as executable-code or software components, which can be downloaded from the computer-readable media and executed by an instruction execution system. The instructions may direct the execution of certain processes, such as those shown in FIGS. 3A-3C. 3A-3C. Any tangible medium that can store, maintain, or transmit any logic, application or software described herein, for use with or in connection to an instruction execution system, is a?computer-readable medium?”

Any physical media, such as magnetic, optical, and semiconductor media, can be included in the computer-readable medium. Some examples of computer-readable media that are suitable include magnetic tapes, magnetic diskettes, magnetic hard drives and memory cards. The computer-readable medium can also include a RAM, such as an SRAM or DRAM, or MRAM. The computer-readable medium can also include a PROM or ROM. An EPROM, an EEEPROM, and other similar memory devices.

“Any logic or application described herein, even adaptive topic logic may be implemented in many ways. One or more of the applications may be implemented in modules or as components of one application. One or more of the applications described herein can be executed on shared computing devices, separate computing devices, or a combination thereof. A plurality of the described applications may be executed in one computing device or in multiple computing environments 110. It is also understood that terms like?application?,?, and?service? may be interchangeable. ?service,? ?system,? ?engine,? ?module,? These and other terms may be interchangeable, and not meant to be restrictive.”

“Disjunctive language” such as the phrase ‘at least one of X or Y or Z? Unless otherwise stated, the context is used to show that an item, term or other entity may be either X or Y or Z. This disjunctive language does not imply that certain embodiments require at most one of X, at minimum one of Z, or both.

“It is important to note that the embodiments described in the present disclosure are only possible examples of implementations. This allows for a clear understanding and application of the principles of disclosure. Without departing from the spirit or principles of disclosure, many variations and modifications can be made to the described embodiments. All modifications and variations of the above-described embodiments are included in the scope and protected by the following claims.

Summary for “Autonomous delivery transportation network”

“The need for transportation in urban and suburban areas is growing.” These transportation needs include individuals’ commutes to work, school, shopping malls, and other places. Transporting items between different locations is also part of the transportation requirements. Some municipalities have created public transportation systems to meet these needs. The public transportation system generally uses buses and vehicles to transport people between stops along a predetermined route at predetermined times.

As noted, transportation needs continue to increase in both urban and suburban areas. These transportation requirements include the ability to travel to work, school, shopping centers, and other locations as well as the ability to transport goods between different locations. Some municipalities have created public transportation systems to meet these needs. These public transportation systems use vehicles that follow predetermined routes at predetermined times. These public transportation systems are not only able to meet some passengers’ needs but also have significant disadvantages. The public transport systems are limited in terms of cargo and passenger pickup and drop-off locations. Many times, passengers might not be within walking distance to a service location. The pickup and drop-off times for the system may not be convenient or appropriate.

“In this context, we will describe aspects and embodiments for autonomous transportation networks. Many of the above problems can be addressed by autonomous transportation networks, which offer on-demand transportation services to and from almost any place accessible via surface streets. One central management system for such a transportation network can be used to optimize the routes of multiple vehicles within a network of transport vehicles for efficiency and account for changing service levels. The current service demand may allow vehicles to be added or removed from the network, which will help avoid wasted resources in low-demand situations. The autonomous transportation networks can also be used to transport tangible goods, such as groceries, and other items.

“FIG. “FIG. The networked 100 comprises a computing environment 110 and a network 150. Vehicles 10-16 are illustrated at different locations on the map. FIG. FIG. 1 shows that the computing environment 110 contains a transportation network data storage 120 and a central management software 130.”

“The vehicles 10-16 can be described as any type vehicle, including, but not limited, bikes, carriages and cars, trucks, vans or buses, no matter how powered or driven. The vehicles 10-16 can be collectively referred to as a network transport vehicles. Each vehicle 10-16 has an autonomous vehicle controller, which controls its maneuvering on roads, highways and skyways. The vehicles 10-16 have autonomous vehicle controllers that communicate with the central management 130 over the network 150. They receive pickup, delivery, and any other location information to help determine service routes.

“The vehicles 10-16 can be used to transport any item that is capable of moving, including people, tangible items, and groceries. FIG. FIG. 1 shows that the vehicles 10-13 travel along routes 20-23. The route 20 includes stops 20A-20C; the route 21 includes stop 21,A; the route 22 includes stops 22A-22B and the route 23 includes stop 23,A. The vehicles 14-16 do not operate according to specific routes and may be waiting for instructions from central management 130. The vehicles 14-16 could be considered unallocated or available resources in the transportation network.

“As explained in more detail below, the central management system 130 can receive telemetry data for each vehicle 10-16. Telemetry data could include operating parameters data from the vehicles 10-16 such as passenger and cargo capacities, planned stops data, fuel level, system diagnostic data, and so on. These telemetry data can be stored in the transportation data store 120 to allow central management system 130 to reference them.

“Before we move on to a more detailed explanation of the components and operation 100 in the networked environment, please refer to FIGS. 2A-3C for a brief description of the operation. 1. One example is that a client device can send a request to transport 30 to the computing environment 110 over the network 150. The request 30 could include information such as a pickup location 31 and destination location 32. It may also include information about the number of passengers. Geolocation information may be used to identify the pickup and destination locations 31 or 32.

“In response to the 30th request, the central management system 130 has been configured to identify the vehicle 10-16 that is compatible with the 30th request. The central management system 130 can analyze the service routes 10-16 and identify the vehicle with the passenger capacity and service route that is compatible with the request. An existing service route is compatible with the request, if it can be integrated into an existing route without causing additional delay to the current pickup/destination locations. The request can be considered compatible if it is located sufficiently close to the pickup and/or destination locations of the existing route to cause no delay beyond what is allowed under a service level agreement. The central management system 130 could identify the route 22 for the vehicle 12 as compatible with the request 30 because the pickup and delivery locations 31 and 32 are substantially aligned or along the existing route 22, Based on the comparison of the passenger count in the request 30 with the available vehicle capacity, the central management system 130 could identify the vehicle 12 to be compatible with (e.g. capable of handling) the 30.

“Once vehicle 12 has been identified by central management system 130 and is compatible with request 30, central management system130 may determine if the assignment of vehicle 12 to request 30 will cause an unacceptable delay to passengers or cargo in the vehicle 12. The vehicle 12 can carry multiple passengers to drop off at 22A and 22B. This information is available in the transportation network database 120. In one embodiment, the central management 130 could estimate a delay in the vehicle’s existing service route 22 based on the pickup and destination locations 31-32 in route 22. The modification of the route 22 to include pickup and destination locations 31-32 may result in a delay for passengers destined to the destination 32.

“The central management 130 may compare the delay in route 22 with one of the service level parameters or the autonomous transportation network to determine if it is acceptable under the circumstances. The central management system 130 may allow the vehicle 12 to be assigned to service the request 30, and may communicate to the vehicle the pickup and drop-off locations 31 and 32. The vehicle 12 can then store the pickup/drop off locations 31-32 in a location memory, and update the route 22 with the new locations. The central management system 130 can request another vehicle 10-16 to serve the request 30 if it is not acceptable. The central management system 130, for example, may dispatch the vehicle 14 in order to service the request 30,

“Service level parameters for an autonomous transportation network could be defined as minimum or maximum service delay times, or similar service level metrics. Other aspects of the service level parameters could relate to operating and/or charge costs, time, holiday, event constraints, weather conditions, road conditions or traffic. The central management system 130 can assign one of the vehicles 10-16 according to route compatibility. This is based on different operating and/or maintenance level parameters.

“If vehicle 12 is identified by central management system 130 and assigned for service to the request 30, central management 130 can further configure central management system 130 to calculate the estimated pickup time until vehicle 12 arrives at pickup location 31. A client device may be provided with the estimated pickup time and an identifier for the vehicle 12 by the central management system 130. The user who submitted the transportation request 30 may be notified that the vehicle 12 has been assigned and that the estimated pickup time is 31 minutes.

“In some embodiments, the central managing system 130 may also be used to perform additional maintenance or/or housekeeping activities within the autonomous transportation network. This includes verifying passengers, opening doors and compartments 10-16 under different circumstances, receiving vehicle telemetry data 10-16, processing payments for users, analyzing it, and storing it, as well as receiving maintenance requests 10-16 and responding to them.

“A network of transport vehicles may also include vehicles with cargo bays or compartments for items that can be stored for autonomous delivery. One or more vehicles 10-16 may have cargo bays or compartments that can store items for transport and delivery. The central management system 130 may direct such vehicles to pick up locations. Items are then stored in the cargo bays, and directed to drop-off locations along the service route for delivery. An individual could send a request 40 for delivery to the computing environment 110 through the network 150. The request 40 could include information such as a pickup location 41 and a destination location 42. It may also contain a description of the item to be delivered. Geolocation information, such as latitude and longitude, may be used to identify pickup and destination locations 41, 42. The central management system 130 can then direct the vehicle 15 to stop at the pickup location 41 to pick up the item and deliver it to the delivery address 42. The central management system 130 can also verify that the recipient of the item is at or near delivery location 42. It may allow access (e.g. unlock) to the cargo bay or compartment in the vehicle 15 where the item is stored.

“As mentioned above, autonomous transportation networks may address some of the shortcomings of public transport systems. Autonomous transportation networks offer transportation services to and from almost any location. They generate optimized routes for multiple vehicles within a network of transport vehicles for efficiency. This allows for the accounting of service level parameters that may change over time. The autonomous transportation networks can also be used to transport tangible goods, such as groceries, and other items.

“Turning towards FIG. 2 shows a detailed view of the networked environment 100. Illustration 1 The FIG. 1, FIG. 2, FIG. FIG. FIG. 2 shows user profiles 122, transportation data 124 and vehicle telemetry data 126, among other data that can be stored in transportation data store 120. FIG. FIG. 2 also shows a request manager 132, service route analyzer 134 and telemetry monitor136. Network maintenance supervisor 138 is part of the central management software 130. A transportation network interface engine 140 is part of the computing environment 110. FIG. 2 shows the vehicle 10, which is representative for the other vehicles 11-16. 2. This illustrates an autonomous vehicle controller 182, which includes a location queue, 184, and a cabin accessibility mechanism 186. FIG.

“It is important to note that components of the computing environment 110, and the vehicle 10 shown in FIG. 2 are only representative examples and are not meant to be comprehensive or limitative. The computing environment 110 may have additional or alternative elements, components, and features than those shown in FIG. 2.”

“The computing environment 110 can be represented as one or more computers or computing devices or computing systems. The computing environment 110 could include one or more computing devices, such as those that are arranged in one or more servers or computer banks. The computing device (or devices) may be located in one location or spread across multiple locations. Further details are provided in the following connection to FIG. 6 may contain a number of computing devices that collectively comprise a hosted computing resource or a grid computing resource and/or another distributed computing arrangement. The computing environment 110 could be described as an elastic computing resource, where the allotted processing, network, storage, and other computing-related resources change over time. The computing environment 110 can also be implemented in part as functional and/or logical elements (e.g. computer-readable instructions, device, circuits, processing circuits, etc.). Elements that direct the computing environment 110 in accordance with the embodiments herein. Below is a detailed description of how each component of the computing environment 110 works.

“The client device 160 represents one or more clients that individuals may rely upon to request transport and/or delivery services. Any type of computing device, processor circuit, or processor-based device or system may be included in the client device 160. This includes personal digital assistants, personal computers, laptop computers, tablets, and cellular phones. One or more subsystems or devices may be included in the client device 160, including wireless communications transceivers and GPS receivers, orientation or acceleration sensors, and others. One or more peripheral devices may be included in the client device 160. The peripheral devices could include a keyboard, keypad touch pad, touch screen or touch screen as well as one or more input devices such a microphone, camera, keypad, touchpad, touchpad, touch screen or touch pad.

“The network monitor client 170 represents one or more client devices. Any type of computing device, processor circuit, or device or system may be embedded in the network monitor client device 170, including a desktop computer or laptop computer, a personal computer assistant, a cell phone, or tablet computer. One or more peripheral devices may be included in the network monitor client device 170 for user interaction. The peripheral devices could include a keyboard, keypad or touch pad, microphone, camera, and/or touch screen.

“Turning back to the vehicle 10, autonomous vehicle controller 182 can be represented as analog, digital or mixed analog-digit processing circuitry, memory that directs the operation of both the vehicle 10 (and the electromechanical drive system, 184) of the vehicle 10. The autonomous vehicle controller 182 can be described as an embedded real-time control device in which control outputs are generated in response to control input conditions. The control system 182 can include various sensors such as radar, cameras, laser Illuminated Detect and Range sensors (LIDAR), and others that may be used to analyze the surrounding environment and generate control signals for the drive system 184. The autonomous vehicle controller 182 can, in some embodiments, perform the processing required to control and operate the vehicle 10, either alone or with other computing systems such as the drive system 184, computing environment 110, and other devices and systems.

“The autonomous vehicle controller 182 could include memory areas that store data used for navigation, such as road data or street view data. To determine the most suitable route, the autonomous vehicle controller 182 relies on feedback from its sensors and drive system 184. The central management system 130 may communicate the pickup, destination and delivery locations to the autonomous vehicle controller 182. These information are stored in the location queue (183) as described herein.

“Among the various embodiments, the autonomous car controller 182 can be integrated with the vehicle’s drive system 184 in any way that allows the autonomous vehicle control 182 to control all aspects of the vehicle 10, including turning, acceleration, signal, and lamp operation. The autonomous vehicle controller 182 can be integrated with the vehicle’s drive system 184 in any manner that is suitable.

“As shown in FIG. 2. The location queue 183 is part of the autonomous vehicle controller 182. The autonomous vehicle controller 182 may include the location queue 183 as a memory area that stores waypoints or geographic locations. The central management system 130 may communicate the locations to the vehicle 10, such as the pickup, destination and delivery points, and separate central management system 130 stores them. The autonomous vehicle controller 182 can be used to determine the best route for the vehicle using the location information. Once a destination has been reached, the autonomous vehicle controller 182 may remove a location from the location queue 383 and the vehicle 10 can proceed to the next stored location. The autonomous vehicle controller 182 can operate independently, or at least substantially independent from the central management 130 once it has been provided with one or more locations through which a route could be determined. The central management 130’s primary concern is to optimize the routes of the vehicles 10-16 in the autonomous transportation network. However, the autonomous vehicle controller 182’s primary concern is to direct the vehicle 10 according the central management 130’s pickup, destination and delivery locations.

The drive system 184 could be described as the powertrain, associated electrical, mechanical and electromechanical systems, and associated control, diagnostic, and management systems for the vehicle. The drive system 184 could include one or more motors, transmissions and steering systems. The autonomous vehicle controller 182 directs the vehicle 10, as the drive system 184 does.

“The cabin accessibility mechanism 186 could be defined as the mechanisms that allow access to the passenger compartment of the vehicle 10, such door locks, power doors, and so forth. The central management system 130 may direct the cabin access mechanism to open and close one or more doors in the passenger cabin.

“The cameras 191 could be described as one or more cameras with a field view inside the vehicle’s passenger cabin and outside the vehicle. The cameras 191 may transmit still images and/or videos from the vehicle 10 into the computing environment 110. This data may then be stored in the vehicle telemetry information 126. The central management system 130 may use the images and video to monitor the operation of autonomous transportation networks and provide operational awareness information to operators. Video monitoring and continuous recording can be used to monitor the vehicles inside and out 10-16. GPS receiver 192 can be described as a receiver that receives and demodulates global positioning system beacons, and identifies the geographical location of vehicles as they move between places.

“The cargo compartments 194 can be described as one or more cargo compartments or cargo bays that store items for autonomous delivery. Items may be stored securely in the cargo compartments 194 for transport and delivery by vehicle. Each cargo compartment 194 can be separated by having an access door that is similar to security locks boxes. The compartment access mechanisms (196) can be used to control individual doors. Access mechanisms for compartment access 196 can be either electromechanically or mechanically locked or unlocked. They also have access mechanisms that allow controlled access to one or several cargo compartments 194. The central management system 130 can direct the compartment access mechanism 196 to unlock or open one or more cargo compartments 194. After verifying the identity and recipient of an item, package or other package contained in them, it may also be described further below. This verification can be done by exchanging a secret code or another verification code, client device authentication, facial, biometric, or any other means.

“In different embodiments, the cargo compartments 194 may be larger or smaller to allow for transportation of larger or less heavy items. The central management system 130 can store data that represents the vehicle’s passenger and cargo carrying capacities, as well as the number of items and passengers carried by the vehicle 10, over time. This information is used to determine if the vehicle has the capacity to handle delivery and transportation requests. The passenger compartment of the vehicle 10 may include seating for passengers. However, the cargo compartments 194 can be distinguished. You should note that some vehicles within a network of transport vehicles may not have cargo compartments 194 but instead be designed for passenger transportation only. Vehicles may be designed to transport items or packages only, and they can also be without passenger compartments.

“Returning to the computing environment 110. The transportation network data store 120 contains user profiles 122 and transportation network data 124, respectively, and vehicle telemetry information 126. User profiles 122 contain data about various customers or users of the autonomous transportation system administered by central management system 130. The user profiles 122 can include representative photos or images, usernames and password combinations, names, addresses, billing information, forms of payment information and contact information. When a client device 160 user installs the client app 162, for example, they may be asked to accept certain terms and conditions. They might also be required to create an account in the computing environment 110. For reference by central management 130, the account information of the user could be saved in the user profiles 122.

“Transportation network data 124 contains data about one or more vehicles within a network autonomous vehicles, such the vehicles 10-16 among others. Transportation network data 124 can include unique vehicle identification information (e.g. vehicle identification numbers (VINs), etc. vehicle identification numbers (VINs), etc. Transportation network data 124 could also contain current location information for vehicles 10-16. Global positioning data, such as latitude and longitude, may be included in the location information. This data is typically received over time from vehicles 10-16.

“The transportation network data 124” may include service level parameters that are applicable to the autonomous transportation network. Service level parameters could be described as minimum or maximum service delay times or other comparable metrics for the network. Other aspects of the service level parameters could be related to operating costs and/or charges, time of day or holiday constraints, weather conditions, road conditions, traffic or any other relevant factors. Based on different operating and/or delivery level parameters, the central management system 130 can assign vehicles 10-16 to transport or delivery requests.

“The vehicle’s telemetry data 126 contains measurement and analysis data from the autonomous vehicle controller 182 (of the vehicle 10), as well as other vehicles 11-16. These telemetry data can include data from vehicles 10-16 such as diagnostic trouble codes and door open/closed indicators, fuel efficiency, vehicle speed and RPM, fuel level, trip information, oxygen sensor, onboard computer monitoring and test, vehicle software version and emissions, radar sensor and other data. The vehicle telemetry data (126) may also include still image and/or video feed data from the cameras 191 and 11-16.

“The central management network 130 comprises the request manager, the service route analyser 134, telemetry monitor 136, and the network maintenance coordinator 138. The request manager 132, which is designed to receive transportation service requests, such as the request 30 shown in FIG. 1. Or requests for delivery service such as the request 40 shown in FIG. 1. From the client device 160. Requests for passenger transportation may include information such as a user identifier, information that allows a potential passenger to be identified, a pickup and destination location, number of passengers, or other pertinent information. Requests for transportation or delivery of items may contain item identifiers or manifests or other descriptive information. This information can be used to identify the person requesting the service, as well as a pickup location and a delivery location. A request manager 132 can be configured to access user profiles 122 to retrieve authorization or payment information related to requests for transport or delivery service. This information is based on the information contained in the requests.

“The service route analyzer (134) is able to analyze multiple existing service routes in order to identify a service route and passenger capacity for a vehicle that can be used to fulfill any request. The service route analyzer may, for example, analyze the 10-16 vehicles’ existing service routes. The service route analyzer may be able to estimate the delay in the existing vehicle service route based on the pickup, destination and/or delivery locations for a request. The service route analyzer may also estimate any time delay or impact on an existing transport or delivery route for passengers and items if the vehicle is already in operation. The service route analyzer may determine if the additional delay is acceptable considering the route. This determination can be made by comparing the additional time delay to at least one service parameter of the autonomous transport network operated centrally 130. Below are further details about service level parameters with reference to FIGS. 3A-3C.”

The request manager 132 can assign the vehicle to service the request. They will also communicate to the vehicle the pickup, destination and/or delivery addresses. If the additional delay is unacceptable for the vehicle with the existing route, the request manger 132 can dispatch a new vehicle to service the request. It is important to note that service level parameters for the autonomous transportation network can be changed over time by network operators using the network monitor device 170. This could cause request managers 132 to rely less on vehicles with existing routes (e.g. ridesharing), or dispatch additional vehicles to improve service levels depending on factors such as operating and/or charge costs, time, holiday constraints, weather conditions, road conditions or traffic or any other relevant factors.

“The request manager 132 is also configured to process payments associated with transportation and delivery service requests. The payment transactions may be processed by the request manager 132 based on billing information or payment information stored in user profiles 122. Transactions may be processed at any time, including when a passenger is picked-up or dropped off by a car, or when an item or service is delivered or picked up.

The telemetry monitor 136, which is designed to analyze vehicle telemetry data (126) received from vehicles 10-16, can be used to monitor and analyze these data. The telemetry monitor 136, in this context, may be able detect dangerous operating conditions or passengers 10-16, verify their location 10-16, and provide a deterrent to crime. It can also visually identify passengers and receivers of items.

“The network maintenance supervisor (138) is able to monitor the vehicles from 10-16. This includes reviewing and monitoring vehicle telemetry data126 to determine fuel levels, service mileage, operating hours, and any other diagnostic information. The network maintenance supervisor 138 can also receive maintenance requests from vehicles 10-16. Requests for maintenance may include requests for different types of maintenance and/or service for vehicles 10-16. The network maintenance supervisor 138 will respond to your requests and direct the vehicles 10-16 to a location to be serviced or refueled.

“The computing environment 110 includes the transportation network engine 140. The transportation network engine 140 can generate different network pages (or other interface elements), which may be displayed as a user interface on client devices, such as the network monitor device 170. One embodiment of the transportation network engine 140 may create network pages as hypertext-based pages that include information about the status of the autonomous transport network managed by the central management systems 130. The transportation network interface engine 140 can also generate a user interface that allows for administration and control of the autonomous transport network via one or more central management systems 130, 10-16 vehicles, individually.

“Turning further details on the operation and vehicles 10-16, FIGS. 3A-3C show a 300-degree autonomous transportation process in the networked environment 100 of FIGS. 1. and 2. According to an example embodiment the present disclosure. The flowcharts shown in FIGS. 3A-3C can be seen as a group of steps that were performed in the networked environment 100 according one or more embodiments. The flowcharts shown in FIGS. 3A-3C are just one example of the functional sequences or arrangements that could be used to implement the networked environments 100 operations, as described herein. The process 300 is discussed herein in relation to the computing environment 110, and the vehicles 10-16 shown in FIGS. 1, 2 and 3 may also perform the process 300 in other environments or vehicles.

“Referring first and foremost to FIG. 3A, reference numeral 302, is the 300-step process. It involves receiving a request from client 160 for transport or delivery services. FIG. 1. The central management system 130 could receive a request to transport 30 from a passenger. A request for delivery 40 may be made to the central management system 130 at reference number 302. The request may contain a user identifier and a pickup location. It can also include the delivery location, number, passengers, item identifiers and manifests. The central management system 130 can receive a request for modification to a previously submitted request. This modified request could include modified pickup, delivery, and/or destination locations or any other descriptive information. The central management system 130 can also receive telemetry data, such as from vehicles 10-16, throughout the 300-step process, as illustrated in FIGS. 3A and 3B. The central management system 130 may use the telemetry data to make different decisions as described in this article.

“The process 300, at reference number 304, includes retrieving authorization/or payment information related to the request. Based on the user identifier information provided in the request, the central management system 130 may retrieve authorization and/or payment information from the user profiles. The authorization information can include billing information or billing information. The central management system 130 generally retrieves information from the transportation network database 120 at reference number 304 to determine if the request is valid and if it corresponds to a known user. It may also associate billing and/or payments information with the request. The process 300 might return an error message 160 to the client device if the requested information is not retrieved at reference number 304.

“At reference number 306, the 300-step process includes identifying a vehicle within the transportation network compatible to the request at reference numeral 312. Below is a description of the process for identifying the vehicle. Refer to FIG. 3C.”

“Once the vehicle has been located at reference number 308, 300 is the communication process that includes the delivery of pickup, destination and/or delivery addresses to the vehicle. As shown in FIG. 1. The central management system 130 could communicate pickup and drop-off locations 31 and 32 to vehicle 12 based upon the request for transport 30. The vehicle 12 can store pickup and drop-off locations 31 and 32 in its location memory 183, and then update its route 22 autonomously to include the pickup or drop off locations 31 through 32.”

“At reference number 310, process 300 includes the calculation of an estimated pickup time until vehicle arrives at pickup location. As shown in FIG. 1. The central management system 130 could calculate the estimated time it will take for the vehicle 12 to arrive at pickup location 31 or 15 to arrive at pickup location 41, as shown in FIG. The estimated pickup time can be based on a variety of factors such as current and anticipated traffic conditions, vehicle types, distances between vehicles, pickup locations, and current or expected traffic conditions. Referring to reference number 310, process 300 may also include the calculation of an estimated time for the vehicle to arrive at a delivery or destination. The central management system 130 can calculate the estimated delivery or destination times based on a variety of factors such as current traffic conditions, anticipated traffic conditions, types of vehicles, and distances between vehicles.

“At reference number 312, the 300 process includes communicating to the client 160 the attributes of fulfilling the request for service. The central management 130 will assign a vehicle to service the request at reference numeral 312. It may also estimate the pickup, drop-off, and/or delivery times. This information can be communicated to the client 160 by the central management 130. Referring to reference number 312, the central management 130 may send a vehicle identification of one of the vehicles 12-15 (or any other vehicles 10-16, as assigned) and estimated pickup, drop-off, and/or delivery times, for example, to the client 160. The client device 160 can be informed by the central management system 130 that his request for transport or delivery services has been fulfilled. The user might also be able to know when he can expect to pick up the item and drop it off. Alternately, information may be provided by the user about when an item will arrive to him or her.

“In other embodiments the central management system 130 may forward the bar code or quick response (QR), code to the client 160 for display. The bar code or QR code displayed on the client device 160 may be presented by the vehicle 12 to the user. The vehicle 12 can communicate with central management system 130 in either case to verify and compare the verification code, password or fingerprint, facial scan or scanned bar code with expected verification information. Once verified, the process 300 moves to reference number 318. Otherwise, the process 300 awaits reference numeral 318 for at least a reasonable time before a pickup verification can occur before the pickup cancellation is made. Also, the process can be repeated 300 times while waiting for pickup verification at reference number 316 in FIG. 3A), the process 300 continues to FIG. 330. 3B.”

“At reference number 318, the process 300 involves directing the vehicle’s opening. After verification at reference number 314, the central management 130 might send instructions to vehicle 12 to open and unlock a passenger compartment door. The client device 160 may be used as a passenger in the vehicle’s passenger compartment 12 once it has been opened. Alternately, the central management 130 can send instructions to the vehicle 12 to, for example, direct the compartment access mechanism to 196 to unlock or open a cargo compartment 194. An item can be stored in one the cargo compartments 194 once it has been opened. The vehicle can pick up either a passenger or an item for transport or delivery.

“Turning towards FIG. “Turning to FIG. The central management system 130 can review data from the cameras 191, the seat weight sensors embedded with the seats in vehicle 12, and telemetry data from other sensors within the vehicle 12 in order to determine if a passenger or an item were picked up. The process 300 can take corrective actions if the pickup location is not confirmed. This includes sending error messages to client 160 and trying to locate the pickup location. The process at reference number 320 can be omitted in some embodiments.

“At reference number 322, the process 300 involves processing a payment transaction to transport or deliver service. The request manager 132 can process the payment transaction using billing information and/or payment data stored in the user profile 122. You can process the transaction at any time during the 300 process. This includes when a passenger is picked-up or dropped off, or when an item or service is delivered or picked up. The costs of certain embodiments may differ depending on the demand, time of day or holiday, event constraints, weather and/or any other cost factors. Payment transactions can be processed through a bank or credit card.

“At reference number 324, process 300 includes monitoring of the route of vehicle assigned to request at reference numeral 322. The central management system 130 can monitor the vehicle’s progress and may also monitor other vehicles. The central management system 130 can also monitor if the vehicle 12 has arrived at its delivery, pickup and/or drop-off times. The vehicle’s operating status can be monitored by the telemetry monitor 13 as it travels along its route.

“At reference number 326, process 300 includes determining if the vehicle that was assigned to service the request at reference numeral 302 reached its destination or delivery address. The central management system 130 could determine whether the vehicle 12 has reached the destination 32. The central management system 130 can also check if the passenger exited the vehicle 12 at 32. For example, the central management system 130 could send a confirmation message to 160 or a receipt. Another example is that of item delivery. The central management system 130 might determine if the vehicle 15 has reached the delivery address 42. The central management system 130 might then wait for verification of the recipient of an item. This is similar to the verification at reference number 314. Once verified, the central management 130 may instruct the compartment access mechanism (196) to unlock or open the compartment that holds the item. If the vehicle that was assigned to service the request arrives at its destination and completes a drop-off, then the process 300 proceeds to reference number 330. For continued monitoring, the 300 process proceeds to reference number 324.

“Reference numeral 330 is the 300-step process. It includes determining if the vehicle that was assigned to the request still has drop off or delivery locations. The central management system 130 can direct the vehicle to continue to its next destination at reference number 332, if it does not, the central management software 130 may instruct the vehicle. The central management system 130 can also direct the vehicle to park or standby at a specific location while it waits for further instructions at reference number 334.

“Turning towards FIG. 3C is a detailed description of the process for identifying a vehicle that matches the request at reference number 302. FIG. 3C can be considered part 300 of the overall process among FIGS. 3A-3C.”

“At reference number 340, the process involves analyzing a plurality service routes to find a service route that is compatible with the request at reference numeral 302. The service route analyzer (134) may analyse the routes 10-16 of the vehicles (FIG. 1) to determine which one is most suitable or compatible with the request. For efficiency, the service route analyzer 134 may be used to determine which vehicle route is closest to the requested pickup, drop-off, and/or delivery locations. After identifying a vehicle, process 300 moves to reference number 342. This includes determining if the vehicle’s passenger or cargo capacity is compatible with the request. The central management system 130 can determine if the vehicle has enough passenger or cargo space to accommodate the requested number of items or passengers. The process will then proceed to reference number 344.

“Reference numeral 344: The process 300 includes the estimation of a delay to an existing service route for the identified vehicle, with reference to the pickup, delivery, and destination locations specified in the request. The vehicle could be already operating under an existing transport and/or delivery route for items or passengers. The service route analyzer (134) may then estimate the time delay or impact on that route based upon the additional request. The service route analyzer (134) may determine if the additional delay is acceptable for passengers or items that are being serviced using the existing route reference number 346.

Referring to reference number 346, process 300 involves comparing the time delay with one of the service level parameters in the autonomous transportation network. Service route analyzer 134 can compare the time delay to service level parameters to determine whether the delay is in line with other passengers or delivery commitments. Service level parameters can be described as the maximum and minimum service delay time, as well other comparable metrics. Other aspects of the service level parameters could be related to operating costs and/or charges, time of day or holiday constraints, weather conditions, road conditions, traffic or any other relevant factors.

After comparing the service level parameters at reference number 346, process 300 proceeds to reference number 348. This includes determining if the delay is acceptable in accordance with the one or more service-level parameters. If the answer is yes, the process 300 moves to reference numeral 352, where the vehicle identified is assigned to service the request at reference numeral 346 (FIG. 3A). If the delay is unacceptable according to one or more service-level parameters, the process proceeds to reference number 356, which involves dispatching a new vehicle to service the request (e.g., vehicle with no existing route).

Referring to reference number 342, if it’s determined that no vehicles have routes compatible with the request at reference numeral 302. This could be due to a large distance between pickup and drop-off locations or a lack of cargo or passenger capacity. Otherwise, process 300 will proceed to reference numeral 352. This includes determining if optimization of existing routes is possible. The service route analyzer (134) may determine if one or more vehicles (10-16) can be optimized for efficiency or increased service capacities. A modification to the pickup, delivery, or drop-off locations of vehicles 10-16 may be considered optimization. This is done in response to additional service requests, or to improve efficiency. If optimization is possible, the process 300 proceeds as reference numeral 354, which also includes the service route analyser 134 optimizing existing service routes between the vehicles 10-16 within the transportation vehicle network. Otherwise, the process proceeds to reference number 356, which includes dispatching of a new vehicle. In certain instances, requests received at reference number 302 might be denied if optimization is not possible or no additional vehicles are available.

The process 300 can be used to solve the above problems by providing on-demand transportation services to and from almost any place accessible via surface streets. The central management system 130 can optimize the routes of the vehicles 10-16 in a network transport vehicles for efficiency and account for variations in service level parameters. The operator can control or direct the operation 300 via the network monitor client device 170, and the transportation network engine 140 throughout the process 300. You can also add or remove vehicles from the network of vehicles according to current service demand. This allows you to avoid wasting resources when there is little demand.

“FIG. “FIG. 1. and 2. According to different embodiments of this disclosure. One or more computing devices 400 are included in the computing environment 110. Each computing device 400 contains at least one processor, such as a processor 402 or a memory 402. Both of these systems are electrically and communicatively connected to a local interface (406). Each computing device 400 could be, for example, a server computer or other similar device. Local interface 406 could be, for instance, a data bus that has an accompanying address/control or any other bus structure.

“In different embodiments, the memory 402 stores executable-code or data. The memory 404 can store executable code components that are associated with central management system 130. This information is available for execution by processor 402. Other data, such as those stored in the transportation data store 120 may be kept in the memory 404.

“As we have discussed, the memory 404 contains software that can be executed by the processor 402. The terms “executable” and “for execution” are used here. Executable? or?for execution? are used to refer to software forms that can be run or executed by the processor 402. Software forms that can be executed or run by the processor 402. Executable programs can include, for instance, a compiled program which can be translated into machine code and loaded into the random access section of the memory 402. Source code can also be loaded into the random access section of the 404 by the CPU 402, and executed. Or source code that can then be interpreted by another executable to generate instructions in the random access section of the 404. The processor 402 can execute the source code, etc. An executable program can be stored in any part or component of the memory 402, including a random access memory, read-only memory, ROM, magnetic or other hard drive drive, solid-state or semiconductor drive, solid-state or similar drive and executed by the processor 402, source code that can be expressed in an object code format and loaded into a random acces portion of memory 404 and executed by the processor 402. Source code that can be interpreted by another executable program to generate instructions in a random area of memory 404, magnetic tape, magnetic tape, magnetic disk, magnetic tape or other component.

“In different embodiments, the memory 408 may contain both volatile and nonvolatile memories and data storage components. Volatile components do not store data when power is lost. Nonvolatile components retain data even if power is lost. The memory 404 could include, for instance, a RAM or ROM, magnetic, other hard drive, solid-state semiconductor, or similar drive. It also may contain a USB flash drive. A floppy drive can be accessed through an associated floppy drive. An optical disk can be accessed via the optical disk drive. Magnetic tape access via an appropriate tape driver. And/or any other memory component. The RAM could also include, for instance, static random access memory, dynamic random access memories (DRAM), magnetic random access memories (MRAM), and/or any other similar memory device. A programmable, read-only, or erasable, programmable, read-only memory may be included in the ROM.

“Also the processor 402 could represent multiple processors 402./or multiple cores. The memory 404 may be multiple memories that work in parallel or in combination. The local interface 406 could be a network or bus that allows communication between any two processors 402, any processor 402 or any memory 404. It may also allow for communication between the processors 402 and the memories 404. Additional systems may be added to the local interface 406 to facilitate this communication, such as a load balancer, which performs load balancing. The processor 402 could be electrical or any other type of construction.

“As mentioned above, the central management software 130 can be implemented in part by executable-code or software components that can be executed by general purpose hardware. The same could also be embedded in dedicated hardware, or a combination general, specific, or dedicated purpose hardware. Each can be implemented in hardware if it is embodied. For example, a circuit or state machine that uses any combination of several technologies could be created. These technologies include, but not limited to, discrete circuits with logic gates that implement various logic functions upon application of one or several data signals, application-specific integrated circuits (ASICs), which have appropriate logic gates, FPGAs, or other components. These technologies are well-known by all who are skilled in the art. Therefore, they are not discussed in detail in this article.

“The process flowcharts or flowcharts in FIGS. 3A-3C represent certain functions and operations that are discussed in this document. Each block can represent one or more steps or executions within a process. Alternately, or in addition, each block could represent a module or segment of code, which includes instructions for implementing the specified logical function. Program instructions can be represented in source code. This may include human-readable statements written using a programming language, or machine code that contains numerical instructions that are recognizable by a suitable execution platform such as the processor 402. The source code can be used to convert the machine code. Each block can also represent, or be connected to, a circuit, or a series of interconnected circuits, in order to implement a particular logical function, process step, or combination thereof.

“Even though the process diagrams and flowcharts shown in FIGS. While FIGS. 3A-3C show a particular order, it’s possible that the order might be different. An order for execution of multiple blocks can be altered from the one shown. You can also see two or more blocks in succession in FIGS. 3A-3C can be executed simultaneously or with partial concurrence. In some embodiments, one of the blocks in FIGS. You can skip or omit blocks 3A-3C in some embodiments. For purposes of enhanced utility and accounting, performance measurement or troubleshooting, you can add any number of counters or state variables to the logical flow. All such variations are included in the scope of this disclosure.

“Also any logic or application described in this document, including central management systems 130, that is embodied at least in part by software or executable code components, may also be embodied in any tangible and non-transitory computer readable medium or device for execution via an instruction execution system like a general-purpose processor. The logic could be described as executable-code or software components, which can be downloaded from the computer-readable media and executed by an instruction execution system. The instructions may direct the execution of certain processes, such as those shown in FIGS. 3A-3C. 3A-3C. Any tangible medium that can store, maintain, or transmit any logic, application or software described herein, for use with or in connection to an instruction execution system, is a?computer-readable medium?”

Any physical media, such as magnetic, optical, and semiconductor media, can be included in the computer-readable medium. Some examples of computer-readable media that are suitable include magnetic tapes, magnetic diskettes, magnetic hard drives and memory cards. The computer-readable medium can also include a RAM, such as an SRAM or DRAM, or MRAM. The computer-readable medium can also include a PROM or ROM. An EPROM, an EEEPROM, and other similar memory devices.

“Any logic or application described herein, even adaptive topic logic may be implemented in many ways. One or more of the applications may be implemented in modules or as components of one application. One or more of the applications described herein can be executed on shared computing devices, separate computing devices, or a combination thereof. A plurality of the described applications may be executed in one computing device or in multiple computing environments 110. It is also understood that terms like?application?,?, and?service? may be interchangeable. ?service,? ?system,? ?engine,? ?module,? These and other terms may be interchangeable, and not meant to be restrictive.”

“Disjunctive language” such as the phrase ‘at least one of X or Y or Z? Unless otherwise stated, the context is used to show that an item, term or other entity may be either X or Y or Z. This disjunctive language does not imply that certain embodiments require at most one of X, at minimum one of Z, or both.

“It is important to note that the embodiments described in the present disclosure are only possible examples of implementations. This allows for a clear understanding and application of the principles of disclosure. Without departing from the spirit or principles of disclosure, many variations and modifications can be made to the described embodiments. All modifications and variations of the above-described embodiments are included in the scope and protected by the following claims.

Click here to view the patent on Google Patents.

How to Search for Patents

A patent search is the first step to getting your patent. You can do a google patent search or do a USPTO search. Patent-pending is the term for the product that has been covered by the patent application. You can search the public pair to find the patent application. After the patent office approves your application, you will be able to do a patent number look to locate the patent issued. Your product is now patentable. You can also use the USPTO search engine. See below for details. You can get help from a patent lawyer. Patents in the United States are granted by the US trademark and patent office or the United States Patent and Trademark office. This office also reviews trademark applications.

Are you interested in similar patents? These are the steps to follow:

1. Brainstorm terms to describe your invention, based on its purpose, composition, or use.

Write down a brief, but precise description of the invention. Don’t use generic terms such as “device”, “process,” or “system”. Consider synonyms for the terms you chose initially. Next, take note of important technical terms as well as keywords.

Use the questions below to help you identify keywords or concepts.

  • What is the purpose of the invention Is it a utilitarian device or an ornamental design?
  • Is invention a way to create something or perform a function? Is it a product?
  • What is the composition and function of the invention? What is the physical composition of the invention?
  • What’s the purpose of the invention
  • What are the technical terms and keywords used to describe an invention’s nature? A technical dictionary can help you locate the right terms.

2. These terms will allow you to search for relevant Cooperative Patent Classifications at Classification Search Tool. If you are unable to find the right classification for your invention, scan through the classification’s class Schemas (class schedules) and try again. If you don’t get any results from the Classification Text Search, you might consider substituting your words to describe your invention with synonyms.

3. Check the CPC Classification Definition for confirmation of the CPC classification you found. If the selected classification title has a blue box with a “D” at its left, the hyperlink will take you to a CPC classification description. CPC classification definitions will help you determine the applicable classification’s scope so that you can choose the most relevant. These definitions may also include search tips or other suggestions that could be helpful for further research.

4. The Patents Full-Text Database and the Image Database allow you to retrieve patent documents that include the CPC classification. By focusing on the abstracts and representative drawings, you can narrow down your search for the most relevant patent publications.

5. This selection of patent publications is the best to look at for any similarities to your invention. Pay attention to the claims and specification. Refer to the applicant and patent examiner for additional patents.

6. You can retrieve published patent applications that match the CPC classification you chose in Step 3. You can also use the same search strategy that you used in Step 4 to narrow your search results to only the most relevant patent applications by reviewing the abstracts and representative drawings for each page. Next, examine all published patent applications carefully, paying special attention to the claims, and other drawings.

7. You can search for additional US patent publications by keyword searching in AppFT or PatFT databases, as well as classification searching of patents not from the United States per below. Also, you can use web search engines to search non-patent literature disclosures about inventions. Here are some examples:

  • Add keywords to your search. Keyword searches may turn up documents that are not well-categorized or have missed classifications during Step 2. For example, US patent examiners often supplement their classification searches with keyword searches. Think about the use of technical engineering terminology rather than everyday words.
  • Search for foreign patents using the CPC classification. Then, re-run the search using international patent office search engines such as Espacenet, the European Patent Office’s worldwide patent publication database of over 130 million patent publications. Other national databases include:
  • Search non-patent literature. Inventions can be made public in many non-patent publications. It is recommended that you search journals, books, websites, technical catalogs, conference proceedings, and other print and electronic publications.

To review your search, you can hire a registered patent attorney to assist. A preliminary search will help one better prepare to talk about their invention and other related inventions with a professional patent attorney. In addition, the attorney will not spend too much time or money on patenting basics.

Download patent guide file – Click here