Autonomous Vehicles – Eric Berkobin, Hamsa Ibrahim, Verizon Patent and Licensing Inc
Abstract for “Methods and systems for autonomous car errands”
A delivery server can generate two security codes after a transaction between a vendor and a user. It may also generate a hash of the combinations of the codes. The server might provide the first code to the user, the second code to a vendor, and give the hash of a combination to the vendor and user. The vendor’s location may be provided to the user’s vehicle. It may then use that mapping information to navigate autonomously to the exchange station at the vendor location. The vendor and the vehicle may exchange security code information at the exchange station. Both vehicle and vendor can create a hash from the combined first and second codes and compare this hash to the hash obtained from the delivery server. The vendor can then give the goods to the vehicle. If the vehicle receives them, it may return them to the owner.
Background for “Methods and systems for autonomous car errands”
To further verify the transaction, a customer must present additional identification when they pick up or deliver a product. The customer must drive to the vendor’s address and navigate to the area where pick-up or delivery will occur. These drawbacks and others are not uncommon.
“Systems and methods for facilitating transactions and deliveries using one or more autonomous vehicles are disclosed. An electronic transaction may be made with the vendor by a user using a mobile device. A transaction could include a delivery the user must make to the vendor, and/or an item the user must pick-up from the vendor. A VIN number may be provided by the user to identify the vehicle being delivered. The delivery server can generate two security codes as well as a combination of them. The vendor may receive the first code and the vendor the second. The hash of the combined codes may be sent to both the vendor and user. The vendor may be provided with the VIN number by the server. The server might provide a location file to the user. This file contains information about the physical layout of the vendor’s address. The server might provide the address of the vendor and/or the associated GPS coordinates to a user.
Based on the address of the vendor, the vehicle could arrive at the vendor?s location. A layout file and one or more sensors may be used to guide the vehicle to the loading area. To authenticate the vehicle, the vendor may ask for the VIN number of the vehicle. The vendor might provide the vehicle with the second code and the vehicle with first code. The vehicle could create a hash from the combination of the first and second codes and use it to authenticate the vendor (by comparing the hash with that received from the delivery service). The vendor could also do the same. The vendor might then give the goods to the vehicle. If the vehicle receives them, it may return them to the owner.
“The following description describes modules that can include one or more servers and databases as well as subsystems and other components. The term “module” is used herein. The term “module” can be used to mean non-transitory executable code, firmware, processor, or other hardware and/or different combinations thereof. Modules should not be understood to mean software that isn’t implemented on hardware or firmware or recorded on a tangible, processor-readable, or recordable storage medium. These modules may be combined, separated, or duplicated in order to support different applications. They can also be centralized, distributed, or consolidated. One function that is described as being performed at a specific module could be performed by one or more modules, or by one or more additional devices in addition to or instead of the function performed at that module. Modules can be implemented on multiple devices or other components, either local or distant. One module can have multiple components and devices. However, they may be different from other modules and devices.
Referring to FIG. “Referring to FIG. 1, a schematic diagram is shown of a system 100 that provides autonomous vehicle errands. Network 108 can be communicatively connected with one or more data transmitter devices or entities, users devices, or network elements, as illustrated. The system 100 in FIG. There are many ways to implement the system 100 in FIG. Architecture in system 100 can be implemented as a component of a network element (e.g., a module) or within a box. Architecture within system 100 can also be implemented as computer executable software, e.g. on a tangible computer-readable media. The module functionality of architecture in system 100 can be found on one device or distributed over a number of devices, including one or several centralized servers or mobile units.
“Network 108 can be a wireless or wired network, or any combination thereof. Network 108, for example, may contain one or more of the following: a fiber optics network or passive optical network; a cable network; an Internet network; a satellite network (e.g. operating in Band C, Band Ku, or Band Ka); a wireless network; a Global System for Mobile Communication? (?GSM)? ), A Personal Communication Service (??PCS?). ), a Personal Area Network, (?PAN) ), a Personal Area Network (?PAN) Network 108 can also include, but is not limited to, telephone lines, fiber optics and IEEE Ethernet 802.3. A wide area network (?WAN?) may also be included. ), or a local area network. ), or a global network, such as the Internet. Network 108 can also support an Internet network, wireless communication network, Bluetooth, or any combination thereof. Network 108 could be a 4G network in various configurations that conforms to the International Mobile Telecommunications Advanced specification (IMT-Advanced). Network 108 could be a Long Term evolution (LTE) network. Network 108 could be a LTE Advanced network (LTE-A). Network 108 could be a Mobile WiMAX network (IEEE 802.16e). Network 108 could be a Mobile WiMAX Release 2 network (IEEE 8002.16m).
“Network 108 could also include any one of the exemplary networks described above, either as a standalone network or in conjunction with others. Network 108 could use one or more protocols from one or more network elements to whom it is communicatively connected. Network 108 can translate from one protocol to another to one or more network devices. Network 108 is shown as one network. However, network 108 could be made up of multiple networks. According to some embodiments, network108 may include a number of interconnected networks such as a broadcaster network, an Internet service provider network or cellular network.
“Mobile device 130 could be a mobile communications or tablet device, such as a smartphone, tablet computer, or a watch, bracelet, glasses, or wristwatch. It can also function as a personal digital assistant. Mobile device 130, TCU 118, network element 120 and/or network element 118 can connect to network108 and communicate using WiFi, 3G/4G, Bluetooth or other chipsets with other network elements, servers, providers or providers. Mobile device 130 can receive sensor data from vehicle116 and/or truck control unit 118 and send it to the delivery server 102.
“Network element 120 could include one or more processors (not illustrated) for recording, transmitting and receiving data. Network element 120 can transmit and receive data from network 108. Data may be sent and received using a standard telecommunications or standard networking protocol. One embodiment could use text messages and/or Short Message Service (?SMS)?. In some other embodiments, data can be transmitted or received using Session Initiation Protocol. ), Voice Over IP (?VoIP? ), or any other messaging protocol. Wireless Application Protocol (WAP) can also transmit or receive data. ), Multimedia Messaging Service? (?MMS)? Enhanced Messaging Service?EMS? ), Enhanced Messaging Service (?EMS) Based systems, Code Division Multiple Access(?CDMA?) based systems, Code Division Multiple Access (?CDMA???) ), hypertext transfer protocol (?HTTP? ), hypertext transfer protocol secure (?HTTPS? ), real-time streaming protocol (?RTSP?) ), real-time streaming protocol (?RTSP?) or any other protocols and systems that can be used for transmitting and receiving information. Data can be sent and received wirelessly, or in certain cases, may use a cabled network or telecom connection such as an Ethernet Category 5 Ethernet connection, fiber connection, cable connection, or any other wired network connection. There are many types of alerts or signals that can be transmitted over network 108, including alerts indicative or text messages (including voice messages), emails, prompts, notifications, banners, pop-ups, video signals, links, vibration patterns, visual light signals, ringtones, and other forms of data.
“Application server104 may offer an application to a computing system such as mobile device 130. An application that is installed on the mobile device 130 allows the user to set various settings including privacy and tracking. An application could be linked to a third-party app, such as a map application. The application could also be a social-media add-on that works in conjunction with a particular social media application but is maintained by another entity.
“User settings can be created by the user in the application or via an associated website on Internet. They may be saved on the computing device (e.g. mobile device 130), application server 104 and database 150 or in user profile module 204. Input module 202 can retrieve user settings and be used by vendor profile module, security module, and/or mapping modules 210 to perform the operations described herein.
“User(s), 110” could be any user of a computing devices, a person receiving an alert or a driver driving vehicle 116. User(s), 110 can be singular or plural. Vendor 140 could be an individual/entity that sells goods or services to other people and/or entities. Vendor 140 could be composed of one or more network-enabled computer communicatively connected to network 108. User 110 could be another business entity similar to vendor 140 in various embodiments. User 110 could be a manufacturer, while vendor 140 might be a distributor. User 110 could own multiple vehicles, such as vehicle 116, and use one vehicle to deliver goods to vendor 140 or pick up goods from vendor 140 after an electronic transaction.
Vehicle 116 may have one or more display devices. These may include a touchscreen device, a dashboard display or a touch screen device. Vehicle 116 could include one or more sensors 112a and 112b. The sensors 112a and 112b can be used to detect low-energy transmissions from nearby beacons. The devices 112a and 112b can be equipped with near-field communications (NFC), RFID, infrared, Bluetooth-enabled, LEDs, RFID, near field communications (NFC), and/or Bluetooth. The sensors 112a and 112b can be communicatively connected to TCU118, network element 120, or mobile device 130. TCU 118, mobile device 130, and/or network element 120 may provide information about the location of each sensor 112a and 112b on vehicle 116. TCU 118, network element 120, and/or mobile device 130 may determine the location of each sensor 112a and 112b on vehicle 116 based on the type vehicle (e.g. pickup truck, sedan or 4-door vs. 2-door), as well as whether they are located on vehicle 116.
FIG. 118 “Telematics control units (TCU)” One or more devices may be used to monitor vehicle parameters 116. TCU 118 may also include sensors such as accelerometers and cameras, speakers, microphones, and connections for them. A user’s mobile device 130 can also include sensors. These sensors may replace some or all of the functionality and features of TCU118 that a vehicle manufacturer installed at the factory. Or, they may be replaced by an aftermarket, telematics device that couples with a vehicle’s diagnostic port. TCU 118 can provide substantial data regarding the vehicle, its location, movement, and acceleration in various embodiments. TCU 118 can collect large amounts data about the vehicle 116 to it, such as: location (GPS or GLONASS), speed, stops and starts, temperature, acceleration values. Brake applications. Gyroscope sensor data. Height information from an altimeter. Visual information from a camera communicatively connected to the TCU device. Audio from a microphone. Or revolutions per minute (RPM). Multiple TCU devices may collect data from different vehicles. It is important to understand that the ‘TCU device’ can refer to multiple TCU devices. It could refer to one or more TCU units. These data can be collected anonymously. These data can be collected in response to user 110’s command. Data may be automatically collected at regular intervals. Remote signals from delivery server 101 may be used to gather the data. TCU 118 could include a variety of sensors, including an accelerometer barometer, altimeter and gyroscope. The sensors in mobile device 130 could also include an accelerometer or gyroscope as well as a GPS sensor.
TCU118 may capture some examples of data over time, including location (e.g. latitude, longitude, and/or altitude), heading, weather conditions (e.g. degrees), vehicle speed, vehicle status (whether the headlights have been turned on/off), vehicle speed, vehicle status (whether the headlights are ON/OFF), vehicle status, vehicle speed, vehicle position, vehicle speed, vehicle speeds, vehicle status, vehicle brakes, vehicle slippage, wheel slippage (skidding, sliding), rate of incline/decline), damping forces, using the vehicle’s horn), use of the vehicle’s horn (rate of adamping forces, such as well as well as well-producing damping forces, the vehicle’s horn, and other factors, like a vehicle’s horn, the vehicle’s s s horn, vehicle’s s s s s, such as wells, the vehicle’s s s, fuel consumption,
“Data may include unique information identifying user 110. User 110 can create a profile on application server104. He may access his profile via an app on mobile device 130 provided by application server104. Profile information can include user’s name and address as well as phone number and email address. To associate his profile with mobile device 130, vehicle116, or TCU 118, the user can use the application. Delivery server 102 can communicate with application server104 to obtain the profile information. User profile module 204 may receive the profile information and store it in database 150. The sensors 118 and 130 may transmit sensor data. The data may be transmitted to the delivery server 102 by mobile device 130.
“Delivery server102 may contain an input module and a vendor profile module as well as a security module. A mapping module is also possible, as shown in FIG. 2. Delivery server 102 can be either a resolution server, module or communicatively coupled with a Domain Name System (DNS) in various embodiments. server such as a BIND to convert host names and domain names into Internet IP addresses. One or more network-enabled computers may be part of delivery server 102. A network-enabled computer system or device can include, but not be limited to, e.g. a server or network appliance, personal computers (PC), workstations, mobile devices, handheld computers, personal digital assistants (PDA), thin clients, fat clients, Internet browsers, and other devices. Other embodiments allow the delivery server 102 to perform operations on a mobile device 130, network elements 120, and/or TCU 118 of vehicle 112. The modules 202 to 204, 206-28, 208 and 210 are examples. However, the functions performed in one or more modules can be combined with those performed by others. These functions, described as being performed in the modules 202-204,206,208, 208 and 210, can also be separated and performed by other modules. The modules 202-204,206,208, 208 and 210 can be executed at other devices in the system 100 (e.g. mobile device 130, TCU118 and/or network element 120).
“Input module 022 may be a network element which receives information from mobile devices 130, TCU 118 and 120, as well as vendor 140 via network 110. The received information may be provided to input module 202 by vendor profile module 206, security module 206 and/or mapping module 220. The input module 202 can provide information to mobile device 130 and TCU 118 as well as network element 120 and/or vendor 140 via the network 108.
User profile module 204 could store or maintain one or more profiles that are associated with user 110. User profile information can include the user’s name and address as well as phone numbers and payment information (e.g. account numbers, routing numbers), email addresses(es), username and password), driver’s license number and vehicle plate number 116, VIN number 116, make and model of the vehicle 116 and other identifying information. This user profile information may have been provided by User 110 via mobile device 130. User profile module 204 may receive the user profile information and store it in database 150.
“Vendor profile module206 may store or maintain one or more vendor profiles that are associated with 140. The vendor profile information could include, without limitation, the vendor name, address, phone number(s), payment data (e.g. account numbers, routing numbers), email addresses, usernames, passwords, and logos. Vendor 140 might have given this vendor profile information via network108. The vendor profile information could be received from third-party sources (not illustrated). The vendor profile information can be received by vendor module 206 and stored at database 150.
“User 110 could conduct a transaction over network 108 with vendor 140. Delivery server 102 may conduct the transaction. A third party may conduct the transaction. A component of the transaction could require that user 110 pick up or deliver an item from vendor 140. User 110 might access input module 202 to access a web portal interface. This web interface can facilitate transactions between user 110, vendor 140. The web interface allows user 110 to order goods and services from vendor 140. User 110 can also pay for these items using the web interface. Input module 200 may receive signals to indicate that the transaction is complete. Delivery server 102 can facilitate online transactions using user profile information and vendor information from vendor profile module 206, respectively. Security module 208 can generate a unique transaction number. A first and second part of the transaction code can be combined. The user profile information for user 110 may generate the first and/or second portions based on some information (e.g. the user’s name and address, phone numbers, VIN numbers, and vehicle 116’s VIN numbers) and/or vendor profile information (e.g. the vendor’s address, phone number and logos). The first and/or second portions may be generated randomly by security profile module 208. Security profile module 208 could generate a hash (i.e. the first portion+the next portion).
“Input module 200 may provide the first part of the transaction and the hash to the transaction code via mobile device 130, network elements 120 and/or TCU118 via network 110. The input module 202 could provide the second part of the transaction and the hash to the transaction code for vendor 140 via network 110. Input module 200 may give the address of vendor 140 via mobile device 130, network elements 120, and/or the TCU 118 (based upon the vendor profile module 206) via the network 108. The address can be stored in geographical coordinates (e.g. GPS coordinates). An address could be a street address that pinpoints the location of vendor 140. The input module 202 could provide vendor 140 with the vehicle identification number via network 108. Input module 202 can provide vendor 140 with an estimate pick-up/drop off time in various embodiments. This could be calculated using information that user 110 provided via mobile device 130. This could be calculated based on vehicle 116’s current distance to vendor 140.
“Mobile device 130 and/or network element 120 and/or TCU118 may calculate a route between vehicle 116, vendor 140, using the vendor address received via input module 202. The current location of vehicle 116 relative or against vendor 140 may determine the route. The date and time may also be used to determine the route. The current weather conditions and traffic conditions may also be used to determine the route. Mapping module 210 may compute the route based on vehicle location 116. Mapping module 220 may have access (not shown) to one or more mapping database. The estimated travel time for vehicle 116 to reach vendor 140 may be determined by mobile device 130, network element 120 and/or TCU118. Input module 202 may have this estimated time of travel.
“Input module202 may provide vendor mapping information to vendor 140 to mobile device 130 and/or network element 120. TCU 118 via network 110. Mapping module 210 may retrieve the mapping information. FIG. 3 will show you how to retrieve vendor mapping information. 3.”
Based on the calculated route, vehicle 116 can drive to vendor 140. User 110 can use mobile device 130 or TCU 118 and/or network element 120, to tell vehicle 116 how to drive to vendor 140. Vehicle 116 could be transporting goods to vendor 140, and/or may contain a storage compartment to receive goods from vendor 140. Vendor 140 may receive vehicle 116. FIG. FIG. 3 shows a diagram showing a vendor 140 according to an example embodiment. FIG. FIG.
“Security apparatus 302 could be a gate or arm that blocks vendor 140’s access. One or more sensors may be used to detect vehicle 116’s presence at security station 304. Vehicle 116 can transmit an identifier over short-range, wireless media to security station 304. The vehicle 116’s VIN may be used as the identifier. Security station 304 could include one or more network enabled computers that received the VIN number previously from input module 222. (See above). Security station 304 can match the VIN number received from vehicle 116 with its previous VIN number, and security station may permit vehicle 116 to enter premises (e.g. by opening gate 302 or lifting a mechanical arm 302. Other embodiments allow security station 304 to be placed at any exchange station 314a-314c. The verification process can take place when vehicle number 116 arrives at exchangestations 314a-314c.
“Vendor mapping information may include information about beacons 312, a-312, f, guidance segment 308, exchange facility 308 and exchange stations 314a-314f. Bluetooth-enabled beacons 312 a-312f can transmit the unique identification. Beacons 312a-312f may use Bluetooth Low Energy (Bluetooth LE) or Bluetooth Smart technology. Beacons 312 a-312 f could be iBeacons. The vendor mapping data could include the unique identifier transmitted by each beacon 312a-312f.
“Vendor mapping information may include instructions to TCU 118, mobile devices 130, and/or network elements 120 to guide vehicle 112 to the correct exchange station. Each exchange station may be designed to fit vehicles of different types, sizes, classes, and weights. Exchange station 314a could be used for pickup trucks; exchange station 314, b, for sedans; and exchange station 314, c, for smaller or mid-sized vehicles. You can modify the vendor mapping information provided in mapping module 210 based on your vehicle’s size, weight, type, and class. Vehicle 116. (For example, if vehicle is a 4-door sedan and the vendor mapping information includes instructions for vehicle 112 to drive to exchange station 314b once it arrives at vendor 140). Mapping module 220 may alter the vendor mapping information using the user profile information from module 204 or module 206. The vendor mapping information might include specific guidance segments 308 which vehicle 116 should be following. The vendor mapping information could include unique identifiers for the beacons 312a-312f of that vehicle 116 to ensure you arrive at the right exchange station.
“As vehicle116 enters vendor 140?s facility, sensors 112a and 112b in (vehicle 116) may detect signals transmitted from each beacon 312a-312f when vehicle is 116. TCU 118 can determine vehicle 116’s position relative to each beacon 312a-312f. This is based on the signal strength received by sensor 112.a and the signal received at sensor 112b. (Or the timing of the signal being detected by sensor 112.a versus sensor 112.b). TCU 118 might compare unique identifiers received from each beacon 312 a-312 f to the unique identifiers found in vendor mapping information 140. TCU 118 may use matching unique identifiers to determine vehicle 116’s position relative to beacons 312 a-312 f. TCU 118 and mobile device 130, as well as user 110, may direct vehicle 116 using the information in the vendor mapping information, beacons 312a-312f, guidance segments 308, and/or Exchange Stations 314a-314c.
“Guide segment 308 could include one or more infrared sensor/or marker on the driving surface at vendor 140. Vehicle 116 can be guided to exchange stations 314a-314c by using guidance segments 308. Sensors 112a and 112b detect guide segment 308 as vehicle 116 passes over guide segment 308. TCU118, mobile 130, network element 120 and/or user 110 can automatically guide vehicle 112 along guide segment 308 to one of the exchange stations 314a-314c. Vehicle 116 can also be equipped with sensors 112 a and 112 b that detect guide segments 308 when vehicle 116 drives over them. This information can be used by vehicle, TCU118, mobile 130, network element 120 and/or vehicle 116 to guide vehicle. TCU 118, mobile device 130, and/or the network element 120 may display step-by-step instructions on vehicle 116 for driver 110 (or other driver of vehicle 116) (e.g., “Follow the red line for 100 feet; (2) turn right now?). (1) Follow the red line for 100 ft; (2) Turn right now
TCU 118 can automatically guide vehicle 116 towards one of 314 a-314 C exchange stations. This is based on signals from beacons 312a-312f and/or guide section 308. The vendor mapping information could identify the exchange station to which vehicle 116 should be driven. Based on signals from beacons 312a-312f, guide segment 308, or exchange stations 314a-314c (using vendor mapping information), vehicle 116 could drive to exchange station 314. Vehicle 116 may be detected if it is parked at exchange station 314.
“If exchange station 314a and/or facility 314a detect vehicle 116 being parked at the correct location to receive/deliver goods, exchange facility 314a and/or station 314a may transmit to vehicle 116 a request for the first part of the transaction code (the portion that was received by vehicle 116 when it was first performed). Vehicle 116 can transmit a request for the second part of the transaction code to exchange facility 314 a and/or station 314a (the portion received from vendor 140 when the transaction first took place). Vehicle 116 can combine the first and second portions of the transaction codes from each other. This will perform a hash and compare it with security module 208. Vehicle 116 can proceed with delivery/pickup if the hashes match. The same process may be performed independently by exchange station 314a or exchange facility 310. This allows both vehicle 116 as well as exchange facility 310 to independently verify the transaction.
“If vehicle 116 verifies the transaction vehicle 116 can automatically open a receiving compartiment to receive the goods from exchange facility 314a/or deliver them to exchange station 314.a. If exchange station 314a and/or exchange facility310 verify the transaction, vehicle 116 may open a receiving compartment to receive the goods from exchange station 314a. Vehicle 116 can then leave vendor 140 and return home to user 110. Vehicle 116 may then leave vendor 140 and return to user 110.
A user with 130 mbs uses a mobile device to make an online transaction. The user makes the payment online and specifies a time and date (e.g. 8/14/2014 at 2:00 PM) when their vehicle will drop off dry cleaning at the vendor’s location. Vendor profile module206 provides the address of the drycleaner (1000 Washington Lane Richmond, Va. 23219) to mobile device 130. It also includes the vehicle number (vehicle 116) via TCU 118 and/or network element 120. Mapping module 220 provides vendor mapping information to the drycleaner’s location on mobile device 130 or vehicle 116. The drycleaner will be notified of the approximate date and time of drop-off. The drycleaner will receive vehicle 116’s VIN through the user profile module 204.
“Security module208 creates two keys (e.g. key_A or key_B). Key_A/or Key_B could also be generated randomly. Key_A or Key_B could be determined based on the user?s address, the address of the vendor, and transaction information. Security module 208 generates a hash from key_A and/or key_B. Hash(Key_A+Key_B) The hash function may be one-way and provided to mobile devices 130, TCU118, 120, network element 120, vehicle116, dry cleaner, and vehicle 116. The security module 208 may provide key_A and hash(Key_A+Key_B), to mobile device 130, TCU-118, network element 120 and/or vehicle 112. The security module 208 could provide Key_B or Hash (Key_A+Key_B to drycleaner).
“In different embodiments, security module208 may create a third-key. The location coordinates of vehicle 116 at time of transaction may be used to create the third key. TCU 118 may give mobile device 130 GPS coordinates and transmit them to interface module 222. Mobile device 130, or mobile device 130, may also provide its own GPS coordinates for interface module 202. Security module 208 could create a third key by decrypting and/or hashing GPS coordinates from mobile device 130. TCU 118 could also store these coordinates.”
“Vehicle116 may drive to address of drycleaner (1000 Washington Lane Richmond, Va. 23219). Vehicle 116 could navigate there with a GPS-system (e.g. part of TCU 118). Mobile device 130 can navigate to the address and send directions to vehicle number 116. The vendor can wirelessly request vehicle 116’s identification (e.g. using Bluetooth signals) when vehicle 116 arrives at drycleaner. Vehicle 116 might provide its VIN number to the vendor. After the vendor has verified the VIN, vehicle 116 may be allowed to continue. Vehicle 116 may also give the vendor the location coordinates stored in TCU 118 (associated to the vehicle’s position at the time of transaction as described above) over short-range wireless frequency (e.g. Bluetooth). Vendor might receive the third security key from module 208. He or she may perform a hash function on the coordinates received from vehicle 116 and compare it to the third key (as an extra layer of authentication). Vehicle 116 may be allowed to continue if there is a match.
“Vehicle116 could use vendor mapping information to locate the drycleaner and navigate to the area where delivery will take place. Multiple beacons, such as beacons 312a-312f, and/or guidance segments (such guidance segment 308) may be used to locate the drycleaner’s address. Vehicle 116 may have vendor mapping information that includes the location and transmission information of these beacons/guidance sections. Vehicle 116 may be given specific directions and/or instructions in the vendor mapping information. Vehicle 116 can use the vendor mapping information once it is granted access to the drycleaner. This allows vehicle 116 to navigate to the exact delivery area using the built-in sensors of vehicle 116 (e.g. sensors 112a and 112b). Mobile device 130 can also detect beacons 312a-312f and/or guidance segment 308 and provide navigation directions to vehicle 116.
“Once vehicle number 116 has been parked in the delivery area, vehicle number 116 or mobile device 130 may transmit key_A (using a short-range transmission medium such as Bluetooth). The drycleaner can also transmit key_B from vehicle 116 to mobile device 130. Vehicle 116, and/or mobile 130 may combine key_A with key_B to perform a hash. The hash may be compared with the one received after the initial transaction (Hash(Key_A+Key_B)). Vehicle 116 may then proceed with delivery if the hashes match (e.g. by opening the door on vehicle 112 next to the dry-cleaning area in vehicle 116). The drycleaner can also combine Key_A with Key_B, and then perform a hash. This hash may be compared to the hash that was received after the initial transaction (Hash(Key_A+Key_B)). If the hashes match the drycleaner can automatically extract the dry-cleaning from vehicle 112 (e.g. using a mechanical arm). The drycleaner can compare the current date/time to the delivery date/time received at the time the transaction was completed. The drycleaner can refuse to authenticate vehicle 116 or receive dry cleaning if the difference is greater than a predetermined time, such as 1 hour. The drycleaner might refuse to allow vehicle 116 into the premises if it arrives earlier than expected.
“In various embodiments, vendor 140 may be mobile (e.g., a delivery truck). Vendor 140 could drive to an area and park. One or more beacons may broadcast unique signals to Vendor 140. Vehicle 116 can receive this information in vendor mapping information. Then vehicle 116 could drive to vendor 140. This embodiment may include vendor 140 as a mobile device. Mobile device 130 and the vendor’s mobile device can exchange authentication information. The process can be reversed in some embodiments. For example, vendor 140 could deliver goods or services directly to user 110. In some embodiments, vendor 140 and user 110 may be notified by mobile device 130 that a delivery has been made. Vendor 140 might confirm to interface module202 that vendor 140 delivered the goods to vehicle 116. Interface module202 may also transmit confirmation to mobile device 130. This process can also be reversed.
Referring to FIG. 4. An illustrative flowchart showing a method to facilitate a transaction and delivery using one of more autonomous vehicles. As there are many ways to implement methods in accordance with the present disclosure, this exemplary method 400 is only an example. FIG. 400 shows the method 400. 4. can be executed by any combination of different systems or modules. System 100, shown in FIG. 1, can be used to perform the method 400. 1, and FIG. 102, which shows the delivery server 102. 2. To illustrate the exemplary method in FIG. 2, we will refer to various elements of the delivery server 102 and system 100. 4. FIG. FIG. 4 shows one or more of the processes, decisions or methods, or subroutines, that were performed in an exemplary method 400. These processes, decisions and methods, as well as subroutines, are not always executed in the order shown in FIG. 4 and not each one of them is required. Referring to FIG. Referring to FIG. 4, an exemplary method 400 could begin at block 402.
“At block410, input module202 of delivery server102 may receive transaction information from user 110 (e.g. via mobile device 130 and vendor 140). User 110 might have dropped the motor off at a mechanic previously for repairs. A mechanic might send the user a notification letting them know that the motor is available for pickup at their location. A web portal may be accessed by interface module 200 to schedule a pickup time. The user can schedule the motor to be picked up at 2:00 PM on September 30, 2014. Interface module 202 allows the user to make payment. Transaction data can include one or more account numbers that are associated with a payment bank. The date and time of the pickup may be included in the transaction data. Transaction data can include the VIN (or license plate number) of the vehicle. This example shows that the vehicle used by the user may be a Toyota 4-Runner. Method 400 could be used to block 420.
“At block420, mapping module210 may give the vendor’s address. This example shows that interface module 202 and/or mapping module 210 may give the mechanic’s address to the mobile device of the user and/or the onboard computer in the vehicle. Mapping module 220 may provide vendor mapping information to users (e.g. at mobile device 130 or network element 120 and/or TCU118). The vendor mapping information could include information about the mechanic as well as specific instructions on where vehicle 116 should go after it has reached the mechanic’s place. Block 430 may contain security module 208 that can generate transaction codes. A transaction code may contain a first and second code. The code_1 code could be the first, and code_2 the second. Block 440 may see interface module 202 provide code_1 and code_2 for the mechanic. The code_1 may be sent to the user’s mobile phone and/or onboard computer of his Toyota 4-Runner. The security module 208 can generate a hash from code_1 and code_2 and give this hash to both you and your mechanic. The mechanic and the user may also be provided with the hash function by security module 208. Method 400 could block 450.
“At block 455, the user may drive his vehicle to the vendor’s address using the received address. The vehicle can navigate using turn-by-turn directions from mobile device 130, TCU118, and/or network elements 120. Vehicle 116 could navigate automatically (e.g. vehicle 116 might be self-driven). 110 user may drive vehicle number 116 to the mechanic. Block 460 may allow vehicle 116 to arrive at the mechanic. This vehicle will then be able to navigate to the vendor’s exchange station. Based on mapping module 210’s vendor mapping information, vehicle 116 could navigate to the correct station. Based in part on vehicle type, the vendor mapping information might have been generated. Vehicle 116, a Toyota 4-Runner pickup truck, may be directed to an exchange station by the vendor mapping information.
“The vendor mapping information could include the layout of the mechanic?s facility. Four beacons may be used to identify the mechanic’s location: beacon A, beacon B and beacon C. Each beacon can broadcast a unique identifier via Bluetooth Low Energy. The unique identifier transmitted by each beacon A-D may be included in the vendor mapping information. Location data may be included in the vendor mapping information relative to exchange stations. Instructions for driving to exchange station 1 may be included in the vendor mapping information. These instructions are suitable for pickup trucks. Transceivers may be included in exchange station 1, similar to beacons D-A.
“The 4-Runner user may have sensors that detect signals from beacons D and relay this information to TCU 118 or mobile device 130 and/or network element 120. Based on signals from beacons A-D, TCU 118, mobile 130 and/or network 120, the 4-Runner may display turn-by-turn directions that a user can follow. Based on signals from each beacon A-D, the 4-Runner can be driven autonomously to exchange station 1. Based on the strength of each received signal, the sensors on the 4-Runner could determine the 4-Runner’s location relative to each beacon. TCU 118 and mobile device 130 may guide the 4-Runner based upon the instructions in vendor mapping information, beacons A-D and guidance segments 308 and/or exchange stations 314, a-314 c. The 4-Runner may be parked at exchange station 1 to detect its presence. Method 400 could block 470.
“At block 471, the vehicle and exchange station/mechanic can perform mutual authentication. One or more network-enabled computers located at exchange station 1 could provide code_2 to vehicle and/or mobile devices 130. Security module 208 can also do this (e.g. security module208 may send code_2 to 130 after receiving a confirmation signal (mechanic from the vendor) that the vehicle arrived at the exchange station). These codes can be exchanged locally using bluetooth transmission signals. The code_1 may be provided by the 4-Runner/mobile device, and/or security module208 to the exchange station network enabled computer (and/or any other network-enabled computers associated with the mechanic). The vehicle/mobile device can perform the hashing of code_1 and code_2 to determine if it matches the hash from security module208. A mechanic network-enabled computer could do the same. The mechanic can deliver the motor to the 4-Runner if there is a match between the vehicle and the mechanic (e.g. using a mechanic arm, lift). The mechanic may allow the 4-Runner to leave their lot and then return to the owner. Block 480 may see the vehicle/mobile device or mechanic transmit a confirmation signal to interface module 200, indicating that the transaction is complete.
Referring to FIG. 5 is an illustration of a flowchart that illustrates a method to facilitate a transaction and delivery using one, or more autonomous vehicles. As there are many ways to implement methods in accordance with the present disclosure, this 500-word example is only an example. FIG. 500 shows the method 500. 5, can be executed by any combination of different systems or modules. System 100, shown in FIG. 1, may be used to perform the method 500. 1, and FIG. 102, which shows the delivery server 102. 2. To illustrate the exemplary method in FIG. 2, we will refer to various elements of the delivery server 102 and system 100. 5. FIG. 5 shows each block. FIG. 5 shows one or more of the processes, decisions or methods shown in FIG. 5 and not each one of them is required. Referring to FIG. Referring to FIG. 5, an exemplary method 500 could begin at block510.”
“Block 510: Input module 202 may receive transaction data (e.g. via mobile device 130 or vendor 140) from user 110. This could be similar to block 410 in FIG. 4. Mobile device 130 may transmit location data for vehicle 116 at T0 as part of the transaction. Location data could include GPS coordinates. Method 500 could block 520.
“At block520, delivery server102 may generate a transaction and a vendor code. The transaction code could include a first hash (VIN for vehicle 116+location data at T0) (received block 510). The vendor key code could include a second hash plus the time T0. Both the first and second hash could be of identical hash functions. Method 500 could block 530.
“At block 532, delivery server 102 might provide vendor 140 with the vendor key code and transaction code. Block 540: Delivery server 102 may provide the transaction code and pickup and delivery times, as well as the vendor location and vendor mapping information to vehicle (116) and/or mobile device (130). Vehicle 116 can save the vehicle’s location information at T0.
“Vehicle 116 may drive to vendor at block 550 (using vendor mapping and/or vendor location information). Block 560 may see vehicle 116 arrive at the exchange station. They will provide vehicle 116’s VIN and location data (at an exchange station) from T0 to vendor 140. These information can be transmitted wirelessly, such as Bluetooth. Vendor 140 will then do the first hash and compare the location data to time T0 with the transaction code from delivery server 102 in block 520. If the match is found, vendor 140 may then provide vehicle 116 or mobile device 130 the vendor key code. Block 570 will allow vehicle 116 to authenticate the vendor. This is done by performing the second hash (VIN+time T0) and comparing it with the vendor key. If validation succeeds, pickup/delivery can take place at block 580. Vehicle 116 unlocks/opens a door to allow goods to be picked up/delived at vendor 140’s exchange station.
“The various computing devices, including phones and network equipment, generally include computer executable instructions. The instructions can be executed by one or more processors. Computer-executable instruction can be compiled from programs written in a variety programming languages or technologies. This includes, but is not limited to, Java?. C, C++. Visual Basic. Java Script. Perl. A processor or microprocessor generally receives instructions from a memory or a computer-readable media, and executes them. This allows it to perform one or more of these processes. These instructions and other data can be stored on a variety computer-readable media and may be transmitted.
“Databases, data repository or other data stores, described herein, can include various types of mechanisms for accessing, retrieving, and storing various types of data. These include a hierarchical data base, a set files in a filesystem, an application database in proprietary format, a relational data management system (RDBMS), and many others. Each of these data stores is usually included in a computing device that uses a computer operating software such as the one mentioned above. They can be accessed via a network using any one or many of a variety. A file system can be accessed from any computer operating system. It may contain files in different formats. A RDBMS typically employs Structured Query Language, (SQL), in addition to a language that allows for the creation, storage, editing, and execution of stored procedures such as the PL/SQL language.
“The preceding specification describes various preferred embodiments with references to the accompanying illustrations. However, it will be apparent that modifications and changes can be made to the specification and that additional embodiments could be implemented without departing from wider scope of the invention as described in the claims. Accordingly, the specification and drawings should be considered in an illustrative not restrictive sense.
“Regarding the processes, systems and methods, heuristics etc. It should be noted that although these processes are described in an ordered sequence, the steps involved can be performed in any order. Although the steps of these processes are described in an ordered order, they can be performed in any order. You should also understand that some steps can be performed simultaneously and that additional steps may be added or omitted. The descriptions of the processes in this document are intended to illustrate certain embodiments and should not be taken as limiting the claims.
“Accordingly, it should be understood that the description above is meant to be illustrative only and not to limit. You will find many other embodiments and applications in the description. It is important to determine the scope not by looking at the description above, but rather with reference the attached claims and the full scope of equivalents which these claims cover. Future developments are anticipated and planned for the technologies described herein. The disclosed systems and methods will also be included in such future embodiments. The application can be modified and varied, so it is important to understand this.
“All terms in the claims are to be given their widest possible constructions and their normal meanings as understood in the technologies described, unless otherwise stated. Particularly, singular articles like?a? and?the? are not permitted. ?the,? ?said,? etc. Unless a claim contains an explicit limitation, it should be read to recite the elements indicated.
The Abstract of the Disclosure allows the reader to quickly determine the nature of the technical disclosure. This Abstract of the Disclosure is provided with the understanding that it won’t be used to limit or interpret the claims. Additionally, the Detailed Description above shows that different features have been grouped in different embodiments to simplify the disclosure. This disclosure method is not intended to imply that claimed embodiments need more features than those cited in the claims. The following claims show that inventive subject matter is not contained in all of the disclosed features. The following claims are hereby incorporated in the Detailed Description. Each claim is a separate subject matter.
Summary for “Methods and systems for autonomous car errands”
To further verify the transaction, a customer must present additional identification when they pick up or deliver a product. The customer must drive to the vendor’s address and navigate to the area where pick-up or delivery will occur. These drawbacks and others are not uncommon.
“Systems and methods for facilitating transactions and deliveries using one or more autonomous vehicles are disclosed. An electronic transaction may be made with the vendor by a user using a mobile device. A transaction could include a delivery the user must make to the vendor, and/or an item the user must pick-up from the vendor. A VIN number may be provided by the user to identify the vehicle being delivered. The delivery server can generate two security codes as well as a combination of them. The vendor may receive the first code and the vendor the second. The hash of the combined codes may be sent to both the vendor and user. The vendor may be provided with the VIN number by the server. The server might provide a location file to the user. This file contains information about the physical layout of the vendor’s address. The server might provide the address of the vendor and/or the associated GPS coordinates to a user.
Based on the address of the vendor, the vehicle could arrive at the vendor?s location. A layout file and one or more sensors may be used to guide the vehicle to the loading area. To authenticate the vehicle, the vendor may ask for the VIN number of the vehicle. The vendor might provide the vehicle with the second code and the vehicle with first code. The vehicle could create a hash from the combination of the first and second codes and use it to authenticate the vendor (by comparing the hash with that received from the delivery service). The vendor could also do the same. The vendor might then give the goods to the vehicle. If the vehicle receives them, it may return them to the owner.
“The following description describes modules that can include one or more servers and databases as well as subsystems and other components. The term “module” is used herein. The term “module” can be used to mean non-transitory executable code, firmware, processor, or other hardware and/or different combinations thereof. Modules should not be understood to mean software that isn’t implemented on hardware or firmware or recorded on a tangible, processor-readable, or recordable storage medium. These modules may be combined, separated, or duplicated in order to support different applications. They can also be centralized, distributed, or consolidated. One function that is described as being performed at a specific module could be performed by one or more modules, or by one or more additional devices in addition to or instead of the function performed at that module. Modules can be implemented on multiple devices or other components, either local or distant. One module can have multiple components and devices. However, they may be different from other modules and devices.
Referring to FIG. “Referring to FIG. 1, a schematic diagram is shown of a system 100 that provides autonomous vehicle errands. Network 108 can be communicatively connected with one or more data transmitter devices or entities, users devices, or network elements, as illustrated. The system 100 in FIG. There are many ways to implement the system 100 in FIG. Architecture in system 100 can be implemented as a component of a network element (e.g., a module) or within a box. Architecture within system 100 can also be implemented as computer executable software, e.g. on a tangible computer-readable media. The module functionality of architecture in system 100 can be found on one device or distributed over a number of devices, including one or several centralized servers or mobile units.
“Network 108 can be a wireless or wired network, or any combination thereof. Network 108, for example, may contain one or more of the following: a fiber optics network or passive optical network; a cable network; an Internet network; a satellite network (e.g. operating in Band C, Band Ku, or Band Ka); a wireless network; a Global System for Mobile Communication? (?GSM)? ), A Personal Communication Service (??PCS?). ), a Personal Area Network, (?PAN) ), a Personal Area Network (?PAN) Network 108 can also include, but is not limited to, telephone lines, fiber optics and IEEE Ethernet 802.3. A wide area network (?WAN?) may also be included. ), or a local area network. ), or a global network, such as the Internet. Network 108 can also support an Internet network, wireless communication network, Bluetooth, or any combination thereof. Network 108 could be a 4G network in various configurations that conforms to the International Mobile Telecommunications Advanced specification (IMT-Advanced). Network 108 could be a Long Term evolution (LTE) network. Network 108 could be a LTE Advanced network (LTE-A). Network 108 could be a Mobile WiMAX network (IEEE 802.16e). Network 108 could be a Mobile WiMAX Release 2 network (IEEE 8002.16m).
“Network 108 could also include any one of the exemplary networks described above, either as a standalone network or in conjunction with others. Network 108 could use one or more protocols from one or more network elements to whom it is communicatively connected. Network 108 can translate from one protocol to another to one or more network devices. Network 108 is shown as one network. However, network 108 could be made up of multiple networks. According to some embodiments, network108 may include a number of interconnected networks such as a broadcaster network, an Internet service provider network or cellular network.
“Mobile device 130 could be a mobile communications or tablet device, such as a smartphone, tablet computer, or a watch, bracelet, glasses, or wristwatch. It can also function as a personal digital assistant. Mobile device 130, TCU 118, network element 120 and/or network element 118 can connect to network108 and communicate using WiFi, 3G/4G, Bluetooth or other chipsets with other network elements, servers, providers or providers. Mobile device 130 can receive sensor data from vehicle116 and/or truck control unit 118 and send it to the delivery server 102.
“Network element 120 could include one or more processors (not illustrated) for recording, transmitting and receiving data. Network element 120 can transmit and receive data from network 108. Data may be sent and received using a standard telecommunications or standard networking protocol. One embodiment could use text messages and/or Short Message Service (?SMS)?. In some other embodiments, data can be transmitted or received using Session Initiation Protocol. ), Voice Over IP (?VoIP? ), or any other messaging protocol. Wireless Application Protocol (WAP) can also transmit or receive data. ), Multimedia Messaging Service? (?MMS)? Enhanced Messaging Service?EMS? ), Enhanced Messaging Service (?EMS) Based systems, Code Division Multiple Access(?CDMA?) based systems, Code Division Multiple Access (?CDMA???) ), hypertext transfer protocol (?HTTP? ), hypertext transfer protocol secure (?HTTPS? ), real-time streaming protocol (?RTSP?) ), real-time streaming protocol (?RTSP?) or any other protocols and systems that can be used for transmitting and receiving information. Data can be sent and received wirelessly, or in certain cases, may use a cabled network or telecom connection such as an Ethernet Category 5 Ethernet connection, fiber connection, cable connection, or any other wired network connection. There are many types of alerts or signals that can be transmitted over network 108, including alerts indicative or text messages (including voice messages), emails, prompts, notifications, banners, pop-ups, video signals, links, vibration patterns, visual light signals, ringtones, and other forms of data.
“Application server104 may offer an application to a computing system such as mobile device 130. An application that is installed on the mobile device 130 allows the user to set various settings including privacy and tracking. An application could be linked to a third-party app, such as a map application. The application could also be a social-media add-on that works in conjunction with a particular social media application but is maintained by another entity.
“User settings can be created by the user in the application or via an associated website on Internet. They may be saved on the computing device (e.g. mobile device 130), application server 104 and database 150 or in user profile module 204. Input module 202 can retrieve user settings and be used by vendor profile module, security module, and/or mapping modules 210 to perform the operations described herein.
“User(s), 110” could be any user of a computing devices, a person receiving an alert or a driver driving vehicle 116. User(s), 110 can be singular or plural. Vendor 140 could be an individual/entity that sells goods or services to other people and/or entities. Vendor 140 could be composed of one or more network-enabled computer communicatively connected to network 108. User 110 could be another business entity similar to vendor 140 in various embodiments. User 110 could be a manufacturer, while vendor 140 might be a distributor. User 110 could own multiple vehicles, such as vehicle 116, and use one vehicle to deliver goods to vendor 140 or pick up goods from vendor 140 after an electronic transaction.
Vehicle 116 may have one or more display devices. These may include a touchscreen device, a dashboard display or a touch screen device. Vehicle 116 could include one or more sensors 112a and 112b. The sensors 112a and 112b can be used to detect low-energy transmissions from nearby beacons. The devices 112a and 112b can be equipped with near-field communications (NFC), RFID, infrared, Bluetooth-enabled, LEDs, RFID, near field communications (NFC), and/or Bluetooth. The sensors 112a and 112b can be communicatively connected to TCU118, network element 120, or mobile device 130. TCU 118, mobile device 130, and/or network element 120 may provide information about the location of each sensor 112a and 112b on vehicle 116. TCU 118, network element 120, and/or mobile device 130 may determine the location of each sensor 112a and 112b on vehicle 116 based on the type vehicle (e.g. pickup truck, sedan or 4-door vs. 2-door), as well as whether they are located on vehicle 116.
FIG. 118 “Telematics control units (TCU)” One or more devices may be used to monitor vehicle parameters 116. TCU 118 may also include sensors such as accelerometers and cameras, speakers, microphones, and connections for them. A user’s mobile device 130 can also include sensors. These sensors may replace some or all of the functionality and features of TCU118 that a vehicle manufacturer installed at the factory. Or, they may be replaced by an aftermarket, telematics device that couples with a vehicle’s diagnostic port. TCU 118 can provide substantial data regarding the vehicle, its location, movement, and acceleration in various embodiments. TCU 118 can collect large amounts data about the vehicle 116 to it, such as: location (GPS or GLONASS), speed, stops and starts, temperature, acceleration values. Brake applications. Gyroscope sensor data. Height information from an altimeter. Visual information from a camera communicatively connected to the TCU device. Audio from a microphone. Or revolutions per minute (RPM). Multiple TCU devices may collect data from different vehicles. It is important to understand that the ‘TCU device’ can refer to multiple TCU devices. It could refer to one or more TCU units. These data can be collected anonymously. These data can be collected in response to user 110’s command. Data may be automatically collected at regular intervals. Remote signals from delivery server 101 may be used to gather the data. TCU 118 could include a variety of sensors, including an accelerometer barometer, altimeter and gyroscope. The sensors in mobile device 130 could also include an accelerometer or gyroscope as well as a GPS sensor.
TCU118 may capture some examples of data over time, including location (e.g. latitude, longitude, and/or altitude), heading, weather conditions (e.g. degrees), vehicle speed, vehicle status (whether the headlights have been turned on/off), vehicle speed, vehicle status (whether the headlights are ON/OFF), vehicle status, vehicle speed, vehicle position, vehicle speed, vehicle speeds, vehicle status, vehicle brakes, vehicle slippage, wheel slippage (skidding, sliding), rate of incline/decline), damping forces, using the vehicle’s horn), use of the vehicle’s horn (rate of adamping forces, such as well as well as well-producing damping forces, the vehicle’s horn, and other factors, like a vehicle’s horn, the vehicle’s s s horn, vehicle’s s s s s, such as wells, the vehicle’s s s, fuel consumption,
“Data may include unique information identifying user 110. User 110 can create a profile on application server104. He may access his profile via an app on mobile device 130 provided by application server104. Profile information can include user’s name and address as well as phone number and email address. To associate his profile with mobile device 130, vehicle116, or TCU 118, the user can use the application. Delivery server 102 can communicate with application server104 to obtain the profile information. User profile module 204 may receive the profile information and store it in database 150. The sensors 118 and 130 may transmit sensor data. The data may be transmitted to the delivery server 102 by mobile device 130.
“Delivery server102 may contain an input module and a vendor profile module as well as a security module. A mapping module is also possible, as shown in FIG. 2. Delivery server 102 can be either a resolution server, module or communicatively coupled with a Domain Name System (DNS) in various embodiments. server such as a BIND to convert host names and domain names into Internet IP addresses. One or more network-enabled computers may be part of delivery server 102. A network-enabled computer system or device can include, but not be limited to, e.g. a server or network appliance, personal computers (PC), workstations, mobile devices, handheld computers, personal digital assistants (PDA), thin clients, fat clients, Internet browsers, and other devices. Other embodiments allow the delivery server 102 to perform operations on a mobile device 130, network elements 120, and/or TCU 118 of vehicle 112. The modules 202 to 204, 206-28, 208 and 210 are examples. However, the functions performed in one or more modules can be combined with those performed by others. These functions, described as being performed in the modules 202-204,206,208, 208 and 210, can also be separated and performed by other modules. The modules 202-204,206,208, 208 and 210 can be executed at other devices in the system 100 (e.g. mobile device 130, TCU118 and/or network element 120).
“Input module 022 may be a network element which receives information from mobile devices 130, TCU 118 and 120, as well as vendor 140 via network 110. The received information may be provided to input module 202 by vendor profile module 206, security module 206 and/or mapping module 220. The input module 202 can provide information to mobile device 130 and TCU 118 as well as network element 120 and/or vendor 140 via the network 108.
User profile module 204 could store or maintain one or more profiles that are associated with user 110. User profile information can include the user’s name and address as well as phone numbers and payment information (e.g. account numbers, routing numbers), email addresses(es), username and password), driver’s license number and vehicle plate number 116, VIN number 116, make and model of the vehicle 116 and other identifying information. This user profile information may have been provided by User 110 via mobile device 130. User profile module 204 may receive the user profile information and store it in database 150.
“Vendor profile module206 may store or maintain one or more vendor profiles that are associated with 140. The vendor profile information could include, without limitation, the vendor name, address, phone number(s), payment data (e.g. account numbers, routing numbers), email addresses, usernames, passwords, and logos. Vendor 140 might have given this vendor profile information via network108. The vendor profile information could be received from third-party sources (not illustrated). The vendor profile information can be received by vendor module 206 and stored at database 150.
“User 110 could conduct a transaction over network 108 with vendor 140. Delivery server 102 may conduct the transaction. A third party may conduct the transaction. A component of the transaction could require that user 110 pick up or deliver an item from vendor 140. User 110 might access input module 202 to access a web portal interface. This web interface can facilitate transactions between user 110, vendor 140. The web interface allows user 110 to order goods and services from vendor 140. User 110 can also pay for these items using the web interface. Input module 200 may receive signals to indicate that the transaction is complete. Delivery server 102 can facilitate online transactions using user profile information and vendor information from vendor profile module 206, respectively. Security module 208 can generate a unique transaction number. A first and second part of the transaction code can be combined. The user profile information for user 110 may generate the first and/or second portions based on some information (e.g. the user’s name and address, phone numbers, VIN numbers, and vehicle 116’s VIN numbers) and/or vendor profile information (e.g. the vendor’s address, phone number and logos). The first and/or second portions may be generated randomly by security profile module 208. Security profile module 208 could generate a hash (i.e. the first portion+the next portion).
“Input module 200 may provide the first part of the transaction and the hash to the transaction code via mobile device 130, network elements 120 and/or TCU118 via network 110. The input module 202 could provide the second part of the transaction and the hash to the transaction code for vendor 140 via network 110. Input module 200 may give the address of vendor 140 via mobile device 130, network elements 120, and/or the TCU 118 (based upon the vendor profile module 206) via the network 108. The address can be stored in geographical coordinates (e.g. GPS coordinates). An address could be a street address that pinpoints the location of vendor 140. The input module 202 could provide vendor 140 with the vehicle identification number via network 108. Input module 202 can provide vendor 140 with an estimate pick-up/drop off time in various embodiments. This could be calculated using information that user 110 provided via mobile device 130. This could be calculated based on vehicle 116’s current distance to vendor 140.
“Mobile device 130 and/or network element 120 and/or TCU118 may calculate a route between vehicle 116, vendor 140, using the vendor address received via input module 202. The current location of vehicle 116 relative or against vendor 140 may determine the route. The date and time may also be used to determine the route. The current weather conditions and traffic conditions may also be used to determine the route. Mapping module 210 may compute the route based on vehicle location 116. Mapping module 220 may have access (not shown) to one or more mapping database. The estimated travel time for vehicle 116 to reach vendor 140 may be determined by mobile device 130, network element 120 and/or TCU118. Input module 202 may have this estimated time of travel.
“Input module202 may provide vendor mapping information to vendor 140 to mobile device 130 and/or network element 120. TCU 118 via network 110. Mapping module 210 may retrieve the mapping information. FIG. 3 will show you how to retrieve vendor mapping information. 3.”
Based on the calculated route, vehicle 116 can drive to vendor 140. User 110 can use mobile device 130 or TCU 118 and/or network element 120, to tell vehicle 116 how to drive to vendor 140. Vehicle 116 could be transporting goods to vendor 140, and/or may contain a storage compartment to receive goods from vendor 140. Vendor 140 may receive vehicle 116. FIG. FIG. 3 shows a diagram showing a vendor 140 according to an example embodiment. FIG. FIG.
“Security apparatus 302 could be a gate or arm that blocks vendor 140’s access. One or more sensors may be used to detect vehicle 116’s presence at security station 304. Vehicle 116 can transmit an identifier over short-range, wireless media to security station 304. The vehicle 116’s VIN may be used as the identifier. Security station 304 could include one or more network enabled computers that received the VIN number previously from input module 222. (See above). Security station 304 can match the VIN number received from vehicle 116 with its previous VIN number, and security station may permit vehicle 116 to enter premises (e.g. by opening gate 302 or lifting a mechanical arm 302. Other embodiments allow security station 304 to be placed at any exchange station 314a-314c. The verification process can take place when vehicle number 116 arrives at exchangestations 314a-314c.
“Vendor mapping information may include information about beacons 312, a-312, f, guidance segment 308, exchange facility 308 and exchange stations 314a-314f. Bluetooth-enabled beacons 312 a-312f can transmit the unique identification. Beacons 312a-312f may use Bluetooth Low Energy (Bluetooth LE) or Bluetooth Smart technology. Beacons 312 a-312 f could be iBeacons. The vendor mapping data could include the unique identifier transmitted by each beacon 312a-312f.
“Vendor mapping information may include instructions to TCU 118, mobile devices 130, and/or network elements 120 to guide vehicle 112 to the correct exchange station. Each exchange station may be designed to fit vehicles of different types, sizes, classes, and weights. Exchange station 314a could be used for pickup trucks; exchange station 314, b, for sedans; and exchange station 314, c, for smaller or mid-sized vehicles. You can modify the vendor mapping information provided in mapping module 210 based on your vehicle’s size, weight, type, and class. Vehicle 116. (For example, if vehicle is a 4-door sedan and the vendor mapping information includes instructions for vehicle 112 to drive to exchange station 314b once it arrives at vendor 140). Mapping module 220 may alter the vendor mapping information using the user profile information from module 204 or module 206. The vendor mapping information might include specific guidance segments 308 which vehicle 116 should be following. The vendor mapping information could include unique identifiers for the beacons 312a-312f of that vehicle 116 to ensure you arrive at the right exchange station.
“As vehicle116 enters vendor 140?s facility, sensors 112a and 112b in (vehicle 116) may detect signals transmitted from each beacon 312a-312f when vehicle is 116. TCU 118 can determine vehicle 116’s position relative to each beacon 312a-312f. This is based on the signal strength received by sensor 112.a and the signal received at sensor 112b. (Or the timing of the signal being detected by sensor 112.a versus sensor 112.b). TCU 118 might compare unique identifiers received from each beacon 312 a-312 f to the unique identifiers found in vendor mapping information 140. TCU 118 may use matching unique identifiers to determine vehicle 116’s position relative to beacons 312 a-312 f. TCU 118 and mobile device 130, as well as user 110, may direct vehicle 116 using the information in the vendor mapping information, beacons 312a-312f, guidance segments 308, and/or Exchange Stations 314a-314c.
“Guide segment 308 could include one or more infrared sensor/or marker on the driving surface at vendor 140. Vehicle 116 can be guided to exchange stations 314a-314c by using guidance segments 308. Sensors 112a and 112b detect guide segment 308 as vehicle 116 passes over guide segment 308. TCU118, mobile 130, network element 120 and/or user 110 can automatically guide vehicle 112 along guide segment 308 to one of the exchange stations 314a-314c. Vehicle 116 can also be equipped with sensors 112 a and 112 b that detect guide segments 308 when vehicle 116 drives over them. This information can be used by vehicle, TCU118, mobile 130, network element 120 and/or vehicle 116 to guide vehicle. TCU 118, mobile device 130, and/or the network element 120 may display step-by-step instructions on vehicle 116 for driver 110 (or other driver of vehicle 116) (e.g., “Follow the red line for 100 feet; (2) turn right now?). (1) Follow the red line for 100 ft; (2) Turn right now
TCU 118 can automatically guide vehicle 116 towards one of 314 a-314 C exchange stations. This is based on signals from beacons 312a-312f and/or guide section 308. The vendor mapping information could identify the exchange station to which vehicle 116 should be driven. Based on signals from beacons 312a-312f, guide segment 308, or exchange stations 314a-314c (using vendor mapping information), vehicle 116 could drive to exchange station 314. Vehicle 116 may be detected if it is parked at exchange station 314.
“If exchange station 314a and/or facility 314a detect vehicle 116 being parked at the correct location to receive/deliver goods, exchange facility 314a and/or station 314a may transmit to vehicle 116 a request for the first part of the transaction code (the portion that was received by vehicle 116 when it was first performed). Vehicle 116 can transmit a request for the second part of the transaction code to exchange facility 314 a and/or station 314a (the portion received from vendor 140 when the transaction first took place). Vehicle 116 can combine the first and second portions of the transaction codes from each other. This will perform a hash and compare it with security module 208. Vehicle 116 can proceed with delivery/pickup if the hashes match. The same process may be performed independently by exchange station 314a or exchange facility 310. This allows both vehicle 116 as well as exchange facility 310 to independently verify the transaction.
“If vehicle 116 verifies the transaction vehicle 116 can automatically open a receiving compartiment to receive the goods from exchange facility 314a/or deliver them to exchange station 314.a. If exchange station 314a and/or exchange facility310 verify the transaction, vehicle 116 may open a receiving compartment to receive the goods from exchange station 314a. Vehicle 116 can then leave vendor 140 and return home to user 110. Vehicle 116 may then leave vendor 140 and return to user 110.
A user with 130 mbs uses a mobile device to make an online transaction. The user makes the payment online and specifies a time and date (e.g. 8/14/2014 at 2:00 PM) when their vehicle will drop off dry cleaning at the vendor’s location. Vendor profile module206 provides the address of the drycleaner (1000 Washington Lane Richmond, Va. 23219) to mobile device 130. It also includes the vehicle number (vehicle 116) via TCU 118 and/or network element 120. Mapping module 220 provides vendor mapping information to the drycleaner’s location on mobile device 130 or vehicle 116. The drycleaner will be notified of the approximate date and time of drop-off. The drycleaner will receive vehicle 116’s VIN through the user profile module 204.
“Security module208 creates two keys (e.g. key_A or key_B). Key_A/or Key_B could also be generated randomly. Key_A or Key_B could be determined based on the user?s address, the address of the vendor, and transaction information. Security module 208 generates a hash from key_A and/or key_B. Hash(Key_A+Key_B) The hash function may be one-way and provided to mobile devices 130, TCU118, 120, network element 120, vehicle116, dry cleaner, and vehicle 116. The security module 208 may provide key_A and hash(Key_A+Key_B), to mobile device 130, TCU-118, network element 120 and/or vehicle 112. The security module 208 could provide Key_B or Hash (Key_A+Key_B to drycleaner).
“In different embodiments, security module208 may create a third-key. The location coordinates of vehicle 116 at time of transaction may be used to create the third key. TCU 118 may give mobile device 130 GPS coordinates and transmit them to interface module 222. Mobile device 130, or mobile device 130, may also provide its own GPS coordinates for interface module 202. Security module 208 could create a third key by decrypting and/or hashing GPS coordinates from mobile device 130. TCU 118 could also store these coordinates.”
“Vehicle116 may drive to address of drycleaner (1000 Washington Lane Richmond, Va. 23219). Vehicle 116 could navigate there with a GPS-system (e.g. part of TCU 118). Mobile device 130 can navigate to the address and send directions to vehicle number 116. The vendor can wirelessly request vehicle 116’s identification (e.g. using Bluetooth signals) when vehicle 116 arrives at drycleaner. Vehicle 116 might provide its VIN number to the vendor. After the vendor has verified the VIN, vehicle 116 may be allowed to continue. Vehicle 116 may also give the vendor the location coordinates stored in TCU 118 (associated to the vehicle’s position at the time of transaction as described above) over short-range wireless frequency (e.g. Bluetooth). Vendor might receive the third security key from module 208. He or she may perform a hash function on the coordinates received from vehicle 116 and compare it to the third key (as an extra layer of authentication). Vehicle 116 may be allowed to continue if there is a match.
“Vehicle116 could use vendor mapping information to locate the drycleaner and navigate to the area where delivery will take place. Multiple beacons, such as beacons 312a-312f, and/or guidance segments (such guidance segment 308) may be used to locate the drycleaner’s address. Vehicle 116 may have vendor mapping information that includes the location and transmission information of these beacons/guidance sections. Vehicle 116 may be given specific directions and/or instructions in the vendor mapping information. Vehicle 116 can use the vendor mapping information once it is granted access to the drycleaner. This allows vehicle 116 to navigate to the exact delivery area using the built-in sensors of vehicle 116 (e.g. sensors 112a and 112b). Mobile device 130 can also detect beacons 312a-312f and/or guidance segment 308 and provide navigation directions to vehicle 116.
“Once vehicle number 116 has been parked in the delivery area, vehicle number 116 or mobile device 130 may transmit key_A (using a short-range transmission medium such as Bluetooth). The drycleaner can also transmit key_B from vehicle 116 to mobile device 130. Vehicle 116, and/or mobile 130 may combine key_A with key_B to perform a hash. The hash may be compared with the one received after the initial transaction (Hash(Key_A+Key_B)). Vehicle 116 may then proceed with delivery if the hashes match (e.g. by opening the door on vehicle 112 next to the dry-cleaning area in vehicle 116). The drycleaner can also combine Key_A with Key_B, and then perform a hash. This hash may be compared to the hash that was received after the initial transaction (Hash(Key_A+Key_B)). If the hashes match the drycleaner can automatically extract the dry-cleaning from vehicle 112 (e.g. using a mechanical arm). The drycleaner can compare the current date/time to the delivery date/time received at the time the transaction was completed. The drycleaner can refuse to authenticate vehicle 116 or receive dry cleaning if the difference is greater than a predetermined time, such as 1 hour. The drycleaner might refuse to allow vehicle 116 into the premises if it arrives earlier than expected.
“In various embodiments, vendor 140 may be mobile (e.g., a delivery truck). Vendor 140 could drive to an area and park. One or more beacons may broadcast unique signals to Vendor 140. Vehicle 116 can receive this information in vendor mapping information. Then vehicle 116 could drive to vendor 140. This embodiment may include vendor 140 as a mobile device. Mobile device 130 and the vendor’s mobile device can exchange authentication information. The process can be reversed in some embodiments. For example, vendor 140 could deliver goods or services directly to user 110. In some embodiments, vendor 140 and user 110 may be notified by mobile device 130 that a delivery has been made. Vendor 140 might confirm to interface module202 that vendor 140 delivered the goods to vehicle 116. Interface module202 may also transmit confirmation to mobile device 130. This process can also be reversed.
Referring to FIG. 4. An illustrative flowchart showing a method to facilitate a transaction and delivery using one of more autonomous vehicles. As there are many ways to implement methods in accordance with the present disclosure, this exemplary method 400 is only an example. FIG. 400 shows the method 400. 4. can be executed by any combination of different systems or modules. System 100, shown in FIG. 1, can be used to perform the method 400. 1, and FIG. 102, which shows the delivery server 102. 2. To illustrate the exemplary method in FIG. 2, we will refer to various elements of the delivery server 102 and system 100. 4. FIG. FIG. 4 shows one or more of the processes, decisions or methods, or subroutines, that were performed in an exemplary method 400. These processes, decisions and methods, as well as subroutines, are not always executed in the order shown in FIG. 4 and not each one of them is required. Referring to FIG. Referring to FIG. 4, an exemplary method 400 could begin at block 402.
“At block410, input module202 of delivery server102 may receive transaction information from user 110 (e.g. via mobile device 130 and vendor 140). User 110 might have dropped the motor off at a mechanic previously for repairs. A mechanic might send the user a notification letting them know that the motor is available for pickup at their location. A web portal may be accessed by interface module 200 to schedule a pickup time. The user can schedule the motor to be picked up at 2:00 PM on September 30, 2014. Interface module 202 allows the user to make payment. Transaction data can include one or more account numbers that are associated with a payment bank. The date and time of the pickup may be included in the transaction data. Transaction data can include the VIN (or license plate number) of the vehicle. This example shows that the vehicle used by the user may be a Toyota 4-Runner. Method 400 could be used to block 420.
“At block420, mapping module210 may give the vendor’s address. This example shows that interface module 202 and/or mapping module 210 may give the mechanic’s address to the mobile device of the user and/or the onboard computer in the vehicle. Mapping module 220 may provide vendor mapping information to users (e.g. at mobile device 130 or network element 120 and/or TCU118). The vendor mapping information could include information about the mechanic as well as specific instructions on where vehicle 116 should go after it has reached the mechanic’s place. Block 430 may contain security module 208 that can generate transaction codes. A transaction code may contain a first and second code. The code_1 code could be the first, and code_2 the second. Block 440 may see interface module 202 provide code_1 and code_2 for the mechanic. The code_1 may be sent to the user’s mobile phone and/or onboard computer of his Toyota 4-Runner. The security module 208 can generate a hash from code_1 and code_2 and give this hash to both you and your mechanic. The mechanic and the user may also be provided with the hash function by security module 208. Method 400 could block 450.
“At block 455, the user may drive his vehicle to the vendor’s address using the received address. The vehicle can navigate using turn-by-turn directions from mobile device 130, TCU118, and/or network elements 120. Vehicle 116 could navigate automatically (e.g. vehicle 116 might be self-driven). 110 user may drive vehicle number 116 to the mechanic. Block 460 may allow vehicle 116 to arrive at the mechanic. This vehicle will then be able to navigate to the vendor’s exchange station. Based on mapping module 210’s vendor mapping information, vehicle 116 could navigate to the correct station. Based in part on vehicle type, the vendor mapping information might have been generated. Vehicle 116, a Toyota 4-Runner pickup truck, may be directed to an exchange station by the vendor mapping information.
“The vendor mapping information could include the layout of the mechanic?s facility. Four beacons may be used to identify the mechanic’s location: beacon A, beacon B and beacon C. Each beacon can broadcast a unique identifier via Bluetooth Low Energy. The unique identifier transmitted by each beacon A-D may be included in the vendor mapping information. Location data may be included in the vendor mapping information relative to exchange stations. Instructions for driving to exchange station 1 may be included in the vendor mapping information. These instructions are suitable for pickup trucks. Transceivers may be included in exchange station 1, similar to beacons D-A.
“The 4-Runner user may have sensors that detect signals from beacons D and relay this information to TCU 118 or mobile device 130 and/or network element 120. Based on signals from beacons A-D, TCU 118, mobile 130 and/or network 120, the 4-Runner may display turn-by-turn directions that a user can follow. Based on signals from each beacon A-D, the 4-Runner can be driven autonomously to exchange station 1. Based on the strength of each received signal, the sensors on the 4-Runner could determine the 4-Runner’s location relative to each beacon. TCU 118 and mobile device 130 may guide the 4-Runner based upon the instructions in vendor mapping information, beacons A-D and guidance segments 308 and/or exchange stations 314, a-314 c. The 4-Runner may be parked at exchange station 1 to detect its presence. Method 400 could block 470.
“At block 471, the vehicle and exchange station/mechanic can perform mutual authentication. One or more network-enabled computers located at exchange station 1 could provide code_2 to vehicle and/or mobile devices 130. Security module 208 can also do this (e.g. security module208 may send code_2 to 130 after receiving a confirmation signal (mechanic from the vendor) that the vehicle arrived at the exchange station). These codes can be exchanged locally using bluetooth transmission signals. The code_1 may be provided by the 4-Runner/mobile device, and/or security module208 to the exchange station network enabled computer (and/or any other network-enabled computers associated with the mechanic). The vehicle/mobile device can perform the hashing of code_1 and code_2 to determine if it matches the hash from security module208. A mechanic network-enabled computer could do the same. The mechanic can deliver the motor to the 4-Runner if there is a match between the vehicle and the mechanic (e.g. using a mechanic arm, lift). The mechanic may allow the 4-Runner to leave their lot and then return to the owner. Block 480 may see the vehicle/mobile device or mechanic transmit a confirmation signal to interface module 200, indicating that the transaction is complete.
Referring to FIG. 5 is an illustration of a flowchart that illustrates a method to facilitate a transaction and delivery using one, or more autonomous vehicles. As there are many ways to implement methods in accordance with the present disclosure, this 500-word example is only an example. FIG. 500 shows the method 500. 5, can be executed by any combination of different systems or modules. System 100, shown in FIG. 1, may be used to perform the method 500. 1, and FIG. 102, which shows the delivery server 102. 2. To illustrate the exemplary method in FIG. 2, we will refer to various elements of the delivery server 102 and system 100. 5. FIG. 5 shows each block. FIG. 5 shows one or more of the processes, decisions or methods shown in FIG. 5 and not each one of them is required. Referring to FIG. Referring to FIG. 5, an exemplary method 500 could begin at block510.”
“Block 510: Input module 202 may receive transaction data (e.g. via mobile device 130 or vendor 140) from user 110. This could be similar to block 410 in FIG. 4. Mobile device 130 may transmit location data for vehicle 116 at T0 as part of the transaction. Location data could include GPS coordinates. Method 500 could block 520.
“At block520, delivery server102 may generate a transaction and a vendor code. The transaction code could include a first hash (VIN for vehicle 116+location data at T0) (received block 510). The vendor key code could include a second hash plus the time T0. Both the first and second hash could be of identical hash functions. Method 500 could block 530.
“At block 532, delivery server 102 might provide vendor 140 with the vendor key code and transaction code. Block 540: Delivery server 102 may provide the transaction code and pickup and delivery times, as well as the vendor location and vendor mapping information to vehicle (116) and/or mobile device (130). Vehicle 116 can save the vehicle’s location information at T0.
“Vehicle 116 may drive to vendor at block 550 (using vendor mapping and/or vendor location information). Block 560 may see vehicle 116 arrive at the exchange station. They will provide vehicle 116’s VIN and location data (at an exchange station) from T0 to vendor 140. These information can be transmitted wirelessly, such as Bluetooth. Vendor 140 will then do the first hash and compare the location data to time T0 with the transaction code from delivery server 102 in block 520. If the match is found, vendor 140 may then provide vehicle 116 or mobile device 130 the vendor key code. Block 570 will allow vehicle 116 to authenticate the vendor. This is done by performing the second hash (VIN+time T0) and comparing it with the vendor key. If validation succeeds, pickup/delivery can take place at block 580. Vehicle 116 unlocks/opens a door to allow goods to be picked up/delived at vendor 140’s exchange station.
“The various computing devices, including phones and network equipment, generally include computer executable instructions. The instructions can be executed by one or more processors. Computer-executable instruction can be compiled from programs written in a variety programming languages or technologies. This includes, but is not limited to, Java?. C, C++. Visual Basic. Java Script. Perl. A processor or microprocessor generally receives instructions from a memory or a computer-readable media, and executes them. This allows it to perform one or more of these processes. These instructions and other data can be stored on a variety computer-readable media and may be transmitted.
“Databases, data repository or other data stores, described herein, can include various types of mechanisms for accessing, retrieving, and storing various types of data. These include a hierarchical data base, a set files in a filesystem, an application database in proprietary format, a relational data management system (RDBMS), and many others. Each of these data stores is usually included in a computing device that uses a computer operating software such as the one mentioned above. They can be accessed via a network using any one or many of a variety. A file system can be accessed from any computer operating system. It may contain files in different formats. A RDBMS typically employs Structured Query Language, (SQL), in addition to a language that allows for the creation, storage, editing, and execution of stored procedures such as the PL/SQL language.
“The preceding specification describes various preferred embodiments with references to the accompanying illustrations. However, it will be apparent that modifications and changes can be made to the specification and that additional embodiments could be implemented without departing from wider scope of the invention as described in the claims. Accordingly, the specification and drawings should be considered in an illustrative not restrictive sense.
“Regarding the processes, systems and methods, heuristics etc. It should be noted that although these processes are described in an ordered sequence, the steps involved can be performed in any order. Although the steps of these processes are described in an ordered order, they can be performed in any order. You should also understand that some steps can be performed simultaneously and that additional steps may be added or omitted. The descriptions of the processes in this document are intended to illustrate certain embodiments and should not be taken as limiting the claims.
“Accordingly, it should be understood that the description above is meant to be illustrative only and not to limit. You will find many other embodiments and applications in the description. It is important to determine the scope not by looking at the description above, but rather with reference the attached claims and the full scope of equivalents which these claims cover. Future developments are anticipated and planned for the technologies described herein. The disclosed systems and methods will also be included in such future embodiments. The application can be modified and varied, so it is important to understand this.
“All terms in the claims are to be given their widest possible constructions and their normal meanings as understood in the technologies described, unless otherwise stated. Particularly, singular articles like?a? and?the? are not permitted. ?the,? ?said,? etc. Unless a claim contains an explicit limitation, it should be read to recite the elements indicated.
The Abstract of the Disclosure allows the reader to quickly determine the nature of the technical disclosure. This Abstract of the Disclosure is provided with the understanding that it won’t be used to limit or interpret the claims. Additionally, the Detailed Description above shows that different features have been grouped in different embodiments to simplify the disclosure. This disclosure method is not intended to imply that claimed embodiments need more features than those cited in the claims. The following claims show that inventive subject matter is not contained in all of the disclosed features. The following claims are hereby incorporated in the Detailed Description. Each claim is a separate subject matter.
Click here to view the patent on Google Patents.