WO2020209789A1 - Internet of things architecture for device sharing - Google Patents

Internet of things architecture for device sharing Download PDF

Info

Publication number
WO2020209789A1
WO2020209789A1 PCT/SG2019/050201 SG2019050201W WO2020209789A1 WO 2020209789 A1 WO2020209789 A1 WO 2020209789A1 SG 2019050201 W SG2019050201 W SG 2019050201W WO 2020209789 A1 WO2020209789 A1 WO 2020209789A1
Authority
WO
WIPO (PCT)
Prior art keywords
motorized scooter
motorized
scooter
status
remote server
Prior art date
Application number
PCT/SG2019/050201
Other languages
French (fr)
Inventor
Le QI
Zhixin Yu
Alexis ZHENG
Original Assignee
Grabtaxi Holdings Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Grabtaxi Holdings Pte. Ltd. filed Critical Grabtaxi Holdings Pte. Ltd.
Priority to SG11202108912TA priority Critical patent/SG11202108912TA/en
Priority to PCT/SG2019/050201 priority patent/WO2020209789A1/en
Priority to CN201980095211.9A priority patent/CN113647122A/en
Priority to TW109111838A priority patent/TW202046755A/en
Publication of WO2020209789A1 publication Critical patent/WO2020209789A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B62LAND VEHICLES FOR TRAVELLING OTHERWISE THAN ON RAILS
    • B62KCYCLES; CYCLE FRAMES; CYCLE STEERING DEVICES; RIDER-OPERATED TERMINAL CONTROLS SPECIALLY ADAPTED FOR CYCLES; CYCLE AXLE SUSPENSIONS; CYCLE SIDE-CARS, FORECARS, OR THE LIKE
    • B62K11/00Motorcycles, engine-assisted cycles or motor scooters with one or two wheels
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • G06Q50/40
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/029Location-based management or tracking services

Definitions

  • Various aspects of this disclosure generally relate to Internet of things (IoT), and more particularly, to an IoT architecture for device sharing.
  • IoT Internet of things
  • the Internet of things is the network of devices such as vehicles and home appliances that contain electronics, software, actuators, and connectivity which allows these things to connect, interact and exchange data.
  • the IoT involves extending Internet connectivity beyond standard devices, such as desktops, laptops, smartphones and tablets, to any range of traditionally non-intemet-enabled physical devices and everyday objects. Embedded with technology, these devices can communicate and interact over the Internet, and they can be remotely monitored and controlled.
  • Mobile device sharing is a transportation innovation that is growing rapidly across cities. It solves the“last mile” problem by providing users an alternative device at better estimated time of arrival (ETA) and price than cars in crowded cities, reduces carbon emission, and provides a smarter transportation network to cities around the world. The future of urban mobility is shared, seamless, smart and environmentally- sustainable. Motorized scooters would be a good addition to the active mobility landscape, serving unmet demands in the first-mile-last-mile (FMLM) travel segment.
  • FMLM first-mile-last-mile
  • a method, a computer readable medium, and an apparatus for operating a motorized scooter are provided.
  • the apparatus may be a part of the motorized scooter.
  • the apparatus may receive an unlock request from a remote server.
  • the apparatus may unlock itself in response to the unlock request.
  • the apparatus may continuously upload its status to the remote server based on a schedule when it is unlocked.
  • the apparatus may receive a lock request from the remote server.
  • the apparatus may lock itself in response to the lock request.
  • the apparatus may be a server.
  • the apparatus may receive, from a mobile device, a vehicle identifier of a motorized scooter.
  • the apparatus may retrieve a vehicle status of the motorized scooter based on the vehicle identifier.
  • the apparatus may generate an unlock request when the vehicle status is a normal usable status.
  • the apparatus may transmit the unlock request to the motorized scooter.
  • the apparatus may continuously receive, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule.
  • the apparatus may receive a message from the mobile device, the message requesting locking the motorized scooter.
  • the apparatus may generate a lock request in response to the message when the motorized scooter is in an unlocking status.
  • the apparatus may transmit the lock request to the motorized scooter.
  • the one or more aspects include the features hereinafter fully described and particularly pointed out in the claims.
  • the following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.
  • FIG. 1 is a diagram illustrating an example of a networking IoT system for device sharing.
  • FIG. 2 is a diagram illustrating an example of triple lock methods that include scanning Quick Response Code, geo-fence, and backend remote control.
  • FIG. 3 is a diagram illustrating an example of an IoT device.
  • FIG. 4 is a diagram illustrating an example of hardware structure of an IoT communication module.
  • FIG. 5 is a diagram illustrating an example of the components of an IoT system.
  • FIG. 6 is a flowchart of a method of operating a motorized scooter.
  • FIG. 7 is a conceptual data flow diagram illustrating the data flow between different means/components in an exemplary apparatus.
  • FIG. 8 is a diagram illustrating an example of a hardware implementation for an apparatus employing a processing system.
  • FIG. 9 is a flowchart of a method of managing motorized scooters.
  • FIG. 10 is a conceptual data flow diagram illustrating the data flow between different means/components in an exemplary apparatus.
  • FIG. 11 is a diagram illustrating an example of a hardware implementation for an apparatus employing a processing system.
  • processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoC), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure.
  • processors in the processing system may execute software.
  • Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.
  • the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium.
  • Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer.
  • such computer-readable media may include a random-access memory (RAM), a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.
  • RAM random-access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable ROM
  • optical disk storage magnetic disk storage
  • magnetic disk storage other magnetic storage devices
  • combinations of the aforementioned types of computer-readable media or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.
  • Bluetooth connection is the most common solution used. There are a few drawbacks came with the Bluetooth solution.
  • the Bluetooth solution lacks centralized control, which makes effective management of the devices almost impossible. No vehicle information such as Global Positioning System (GPS) location, vehicle status, battery level is maintained at the backend. This adds difficulty to daily operations and maintenance.
  • GPS Global Positioning System
  • compatibility problems of the Bluetooth solution is well known among mobile devices. As a result, the communication between the phones and the smart locks may malfunction in quite a few circumstances.
  • Third, the user experiences of the Bluetooth solution are far from satisfactory due to the significant latency incurred during the communication with the devices.
  • a networking IoT system is provided.
  • IoT devices have to maintain persistent connection round-the- clock (with possible retries to connect). This way, the IoT devices are free to upload any device information to the server side at any time.
  • the cloud service may store and maintain the status of all the devices in databases, which may be checked by the operations staff as per their permissions.
  • the server cluster may push certain commands to the IoT devices to proactively control their behaviors, such as locking/unlocking, forcing over-the-air (OTA) update, setting top speed, and stopping any abnormal behaviors.
  • OTA over-the-air
  • SIM subscriber identity module
  • FIG. 1 is a diagram 100 illustrating an example of a networking IoT system for device sharing.
  • the IoT system may include a server 102 and several IoT devices 110, 112 ..., 114.
  • the server 102 may include one or more computing devices (e.g., apparatus 1002/1002’ described below with reference to FIG. 10 or 11).
  • each of the IoT devices 110, 112 ..., 114 may be a motorized scooter.
  • each of the IoT devices 110, 112 ..., 114 may be the apparatus 702/702’ described below with reference to FIG. 7 or 8).
  • the server 102 and the IoT devices 110, 112 ..., 114 may maintain persistent connections round-the-clock (with possible retries to connect/re connect). Each of the IoT devices 110, 112 ..., 114 may upload its device information to the server 102. The server 102 may push commands to each of the IoT devices 110, 112 ..., 114 to control their behaviours, such as locking/unlocking, forcing over-the-air (OTA) update, setting top speed, and stopping any abnormal behaviors.
  • OTA over-the-air
  • binary data format may be used to carry out the communication between the IoT devices 110, 112 ..., 114 and the server 102.
  • This binary data fonnat may be proprietary and thus hard to decrypt.
  • end-to-end encryption may add an extra layer of security to the data transferred.
  • security check may be triggered when an IoT device tries to establish connections with the server 102, which only allows the right pair of International Mobile Equipment Identity (IMEI) and vehicle number to pass.
  • IMEI International Mobile Equipment Identity
  • binary compact data fonnat may make the data hard to crack and small in size. Also, the least amount of bytes may be used to present each data type accurately.
  • different endpoint calls may be combined into a single one whenever possible to reduce the latency of core flows such as unlocking/locking, that is to say, to carry out batch processing. For example, during unlocking, the commands to unlock the scooter, ask for vehicle location, set proper speed limit may be combined into one to issue to the scooter.
  • scanning Quick Response Code (QR code) to unlock a motorized scooter may be completed in under 5 seconds with reminder music; and this reminder music may be dynamically configured based on time, location and the identifier of the motorized scooter, e.g., Jingle Bells on Christmas Eve.
  • the locking/unlocking process may include several interactions, but still may be completed under 5 seconds.
  • a supplementary process may be added to establish regular checks (initiated from backend server) on the connection, lock status, and order status.
  • the supplementary process may be implemented to scan the full system and live order status every few seconds. In the situation where there is no order but the scooter unlocked, locking may be triggered (to prevent loss and theft). In situations where user order active but scooter locked, the user order may be terminated to prevent overcharging. This makes the system intelligent and capable of self-recovery from any issue caused by IoT connection failure.
  • Backend server retrieves vehicle status. If it is in normal usable status, then the unlock request is sent to IoT after conversion protocol;
  • IoT receives the unlock request and decides whether the unlock request is valid. If it is valid, it unlocks and plays the unlock music. If it is invalid, it returns unlock failure to the backend server.
  • B2 retrieve the vehicle status in the backend server. If the vehicle is unlocking status, the lock request will be sent to IoT after the conversion protocol.
  • IoT receives the lock instruction to determine whether the lock instruction is valid. If it is valid, it locks the vehicle and plays the lock music. If it is invalid, it returns lock failure to the backend server.
  • IoT uploads the current status to the backend server every 30 seconds when it is in unlocking status
  • the backend server After receiving the status via IoT upload, the backend server determines whether there is an illegal lock status, and if there is, generates the lock instruction to avoid illegal riding.
  • wireless mobile communication data and short message service (SMS) seamless switch backup communication ensures higher than 90% unlock successful rate.
  • SMS short message service
  • X seconds after the server issues unlocking/locking command to the IoT device the server would send an SMS message down to the IoT device if no networking response is given from the device side. And the same is applied for the uplink from IoT device to the server.
  • the X above may be dynamically adjusted at the backend server according to the real-time distribution of the unlocking durations among the sessions during a certain time period.
  • FIG. 2 is a diagram 200 illustrating an example of triple lock methods that include scanning QR code, geo-fence, and backend remote control.
  • triple lock methods may ensure higher than 95% lock rate.
  • the user may scan parking QR code associated with the parking location.
  • the backend server may check the parking location and the location of the IoT device.
  • the backend server may send a locking request to the IoT device to lock the motorized scooter.
  • the highest riding speed of the motorized scooter may be dynamically remote controlled, which ensures user safety.
  • top speed for scooters may be lowered in certain scenarios. Examples of these scenarios include: low speed zones for certain locations, low speed profiles for uncertified/beginner users, and low speed periods after dark.
  • fleet (or any individual scooter’s) top speed may be controlled based on specific user, geo-fence, lighting conditions, hours of day, weather condition, etc.
  • vehicle data may be tracked close to real time (e.g., every 30 seconds upload when vehicles are on trip, every 30 min upload when vehicle are not hired). This allows several additional functions to be performed on operations.
  • vehicle location, status, as well as basic information such as battery level may be tracked to aid fleet management.
  • operations personnel may be able to get real-time map and status information on high-risk scooters such as those that are low on battery power, and those that are not returned to proper parking lots by users.
  • a proprietary-designed app may facilitate the search of stray scooters by allowing operations personnel to tap on either the Chirp or Flash button features to sound the chime or switch on the headlights on scooters, to make it easier for staff to locate improperly parked scooters.
  • a new feature may be introduced within the operations management system to automate stray scooter alerts. For example, scooters that are not parked at the designated lots are being alerted in real time through the operations management system. This will help reduce stray recover time.
  • visualization of all stray scooters and their locations relative to deployment areas and proper parking lots may be presented onto a map.
  • the remotely triggered commands may include lock, unlock, and managing power, speed, IoT connection status, etc.
  • some embodiments may implement auto-on of headlights after dark for a selected fleet of scooters. Some embodiments may implement always-on headlight after dark for all rides.
  • the firmware of each motorized scooter may be dynamically upgraded based on time, location, and scooter identifier (ID) through encrypted over-air channel. And this over-the-air (OTA) upgrade may be executed automatically according to the preset conditions.
  • OTA over-the-air
  • Backend servers may actively issue forced OTA upgrade instructions to specified IoT or IoT timing retrieval (random distribution of retrieval time points for each IoT device) if there is a valid new version available for upgrading.
  • the IoT device After starting OTA upgrade, the IoT device downloads the matching version from OTA server. After downloading, it upgrades automatically to the latest version and completes the OTA upgrade process.
  • the OTA upgrade process may be initiated by server side.
  • the OTA upgrade capability may be implemented from the backend server. As a result, good stability may be achieved even with the additional challenges.
  • the OTA upgrade may be scheduled in specific times. This is very critical because it is undesirable to do OTA upgrade when fleet is in service. In some embodiments, it may be possible to schedule the OTA upgrade for a specific fleet during a specific time when the fleet is in maintenance or before-deployment. Also due to concern of jamming network during peak time (e.g., connection failures are likely to happen if the entire 5000 fleet performs OTA upgrade), an intelligent solution may be implemented to automatically optimize this OTA upgrade process for best stability and success rate. First, a few scooters within the fleet may be picked randomly to initiate OTA upgrade.
  • the system may automatically trigger the next batch (including determining the size of the next batch) and send alerts if needed during the process.
  • the size of each batch may be optimized for best results and success rate as well as to avoid network jam.
  • FIG. 3 is a diagram illustrating an example of an IoT device 300.
  • the IoT device 300 may be a motorized scooter equipped with an IoT communication module 302, which may be an external box attached to the motorized scooter.
  • the IoT communication module 302 may enable optimization of the operations or maintenance of the motorized scooter so that efficiency may be achieved.
  • the motorized scooter may be unlocked/locked by scanning the QR code.
  • the unlock time may be less than 5 seconds, and the success rate may be higher than 90%.
  • user riding data e.g., when you ride, where you are riding, how long you ride, etc.
  • the real-time data of the motorized scooter e.g., the speed, the power volume, how far has already ride, falling down on the ground or not, etc.
  • the real-time data of the motorized scooter e.g., the speed, the power volume, how far has already ride, falling down on the ground or not, etc.
  • customized human-machine interface e.g., unlock or lock reminder, alarm, etc.
  • the IoT communication module 302 may serve to track the scooters’ service status and location at any given time.
  • the IoT communication module 302 also makes it possible to transmit commands to the scooters via cloud server.
  • the IoT communication module 302 may contain an internal speaker for unlocking/locking indication and alerting the sensors for any abnormal activities detected (e.g., falling down, abnormal movement, etc.) to enhance operational efficiency.
  • the design of the antenna of the IoT communication module 302 may be optimized for sharing scenario.
  • the electronics of the IoT device 300 may be fail safe for electric failure and battery safety.
  • the design of the IoT device 300 is focused on optimizing for user experience (e.g., unlock, lock) so user spends as little time interacting with the app as possible.
  • the product is designed specifically for situations of theft and sabotage, which is known issues in the shared device industry.
  • FIG. 4 is a diagram illustrating an example of hardware structure of an IoT communication module 400.
  • the IoT communication module 400 may be the IoT communication module 302 described above in FIG. 3.
  • the IoT communication module 400 may include a communication module 402, a lock control module 404, an application processing module 406, a sensor module 408, an energy management module 410, a control module 412, a driver module 414, a chipset platform 418, and a system management module 416.
  • IoT firmware may support“cellular wireless data and SMS seamless backup” unlock method, which ensure the higher than 90% unlock successful rate.
  • IoT firmware may support triple lock methods (scanning QR code, geo-fence, and backend remote control) to ensure higher than 95% lock rate.
  • the highest riding speed may be dynamically remotely configured for each motorized scooter by the control module 412.
  • FIG. 5 is a diagram illustrating an example of the components of an IoT system 500.
  • the IoT system 500 may include a message queue 502, a Message Queuing Telemetry Transport (MQTT) server cluster 506, smart devices 508, MQTT host routing and message assembly/resolution component 510, a registration center 512, a core transaction layer 516, an app gateway 518, a consumer app 520, an operation gateway 522, and an operations app 526.
  • MQTT Message Queuing Telemetry Transport
  • the smart devices 508 may include several IoT devices described above with reference to FIGS. 1-4.
  • the highly optimized MQTT server cluster 506 or the extremely lightweight data protocol may be easily extended to support millions of connections to IoT devices.
  • the message queue 502 sits between the transaction system (e.g., the core transaction layer 516) and the MQTT server cluster 506, and all the communications between these two parties have to go through the message queue 502. This effectively eliminates the coupling between these two sets of systems, and the entire architecture benefits from the high scalability of the message queue 502.
  • the IoT system 500 may have theoretically as many frontend MQTT servers as possible.
  • the MQTT server cluster 506 connects directly with the IoT devices, and throw arbitrary number of messages received from the IoT devices to the message queue 502. Then, the multiple transaction systems sitting on the other side of the message queue 502 may choose to consumer the messages at any speed as they like, depending on their computing capacity at any given time, and may even decide to give up those messages that they do not care about.
  • the message queue 502 takes the role of routing various messages between the MQTT server cluster 506 and the core transaction layer 516.
  • micro- service backend transaction system makes every service decoupled from each other, thus enabling managing different aspects of vehicle data separately, which helps to improve the robustness and security of the entire set of services.
  • FIG. 6 is a flowchart 600 of a method of operating a motorized scooter.
  • the motorized scooter may be an IoT device described above with reference to FIGS. 1-5.
  • the method may be performed by an apparatus (e.g., apparatus 702/702’ described below with reference to FIG. 7 or 8).
  • the apparatus may be a motorized scooter.
  • the apparatus may be the IoT component of a motorized scooter.
  • the apparatus may receive an unlock request from a remote server.
  • an application program executing on a mobile device may scan a machine-readable optical label (e.g., a QR code) on the motorized scooter and send a vehicle identifier corresponding to the machine-readable optical label to the remote server.
  • the unlock request may be generated and transmitted, by the remote server, based on the vehicle identifier.
  • the unlock request may be generated when the motorized scooter is in normal usable status.
  • the apparatus may establish a wireless connection with the remote server based on a wireless communication identifier associated with the motorized scooter and a vehicle identifier of the motorized scooter.
  • the apparatus may unlock the motorized scooter in response to the unlock request.
  • the apparatus may receive a speed control command from the remote server.
  • the apparatus may set the maximum speed of the motorized scooter based on the speed control command.
  • the apparatus may continuously upload status of the motorized scooter to the remote server based on a schedule when the motorized scooter is unlocked.
  • the apparatus may receive a lock request from the remote server.
  • an application program executing on a mobile device may receive a user input to lock the motorized scooter, and send a message to the remote serve to request locking the motorized scooter in response to the user input.
  • the lock request may be generated by the remote server in response to the message when the motorized scooter is in an unlocking status.
  • FIG. 7 is a conceptual data flow diagram 700 illustrating the data flow between different means/components in an exemplary apparatus 702.
  • the apparatus 702 may be an IoT device (e.g., the IoT device 110, 112, 114, or 300, or the smart devices 508).
  • the apparatus 702 may include a reception component 704 that receives control commands from a remote server 750.
  • the reception component 704 may perfonn the operations described above with reference to 602 or 608 in FIG. 6.
  • the apparatus 702 may include a transmission component 710 that transmits status of the apparatus 702 to the remote server 750.
  • the transmission component 710 may perform the operations described above with reference to 606 in FIG. 6.
  • the reception component 704 and the transmission component 710 may collaborate to coordinate the communication of the apparatus 702.
  • the apparatus 702 may include a control component 706 that is configured to control the operation of the apparatus 702 based on the commands received from the reception component 704.
  • the control component 706 may perfonn the operations described above with reference to 604 or 610 in FIG. 6.
  • the apparatus 702 may include a data collection component 708 that is configured to collect status data of the apparatus 702 and provide the collected status data to the transmission component 710 for transmission to the remote server 750.
  • the data collection component 708 may perform the operations described above with reference to 606 in FIG. 6.
  • the apparatus 702 may include additional components that perform each of the blocks of the algorithm in the aforementioned flowchart of FIG. 6. As such, each block in the aforementioned flowchart of FIG. 6 may be performed by a component and the apparatus may include one or more of those components.
  • the components may be one or more hardware components specifically configured to carry out the stated processes/algorithm, implemented by a processor configured to perfonn the stated processes/algorithm, stored within a computer-readable medium for implementation by a processor, or some combination thereof.
  • FIG. 8 is a diagram 800 illustrating an example of a hardware implementation for an apparatus 702' employing a processing system 814.
  • the apparatus 702’ may be the apparatus 702 described above with reference to FIG. 7.
  • the processing system 814 may be implemented with a bus architecture, represented generally by the bus 824.
  • the bus 824 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 814 and the overall design constraints.
  • the bus 824 links together various circuits including one or more processors and/or hardware components, represented by the processor 804, the components 704, 706, 708, 710, and the computer-readable medium / memory 806.
  • the bus 824 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further.
  • the processing system 814 may be coupled to a transceiver 810.
  • the transceiver 810 is coupled to one or more antennas 820.
  • the transceiver 810 provides a means for communicating with various other apparatus over a transmission medium.
  • the transceiver 810 receives a signal from the one or more antennas 820, extracts information from the received signal, and provides the extracted information to the processing system 814, specifically the reception component 704.
  • the transceiver 810 receives information from the processing system 814, specifically the transmission component 710, and based on the received information, generates a signal to be applied to the one or more antennas 820.
  • the processing system 814 includes a processor 804 coupled to a computer- readable medium / memory 806.
  • the processor 804 is responsible for general processing, including the analyzation of data gathered by the apparatus itself through its own sensors and the execution of software stored on the computer-readable medium / memory 806.
  • the software when executed by the processor 804, causes the processing system 814 to perfonn the various functions described supra for any particular apparatus.
  • the computer- readable medium / memory 806 may also be used for storing data that is manipulated by the processor 804 when executing software.
  • the processing system 814 further includes at least one of the components 704, 706, 708, 710.
  • the components may be software components running in the processor 804, resident/stored in the computer readable medium / memory 806, one or more hardware components coupled to the processor 804, or some combination thereof.
  • FIG. 9 is a flowchart 900 of a method of managing motorized scooters.
  • Each of the motorized scooters may be an IoT device described above with reference to FIGS. 1-8.
  • the method may be perfonned by an apparatus (e.g., apparatus 1002/1002’ described below with reference to FIG. 10 or 11).
  • the apparatus may be a server that includes one or more computing devices.
  • the apparatus may receive, from a mobile device, a vehicle identifier of a motorized scooter.
  • an application program executing on the mobile device may scan a machine-readable optical label (e.g., a QR code) on the motorized scooter and send the vehicle identifier corresponding to the machine-readable optical label to the server.
  • the apparatus may establish a wireless connection with the motorized scooter based on a wireless communication identifier associated with the motorized scooter and a vehicle identifier of the motorized scooter.
  • the apparatus may retrieve the vehicle status of the motorized scooter based on the vehicle identifier.
  • the apparatus may generate an unlock request when the vehicle status is a normal usable status.
  • the apparatus may transmit the unlock request to the motorized scooter.
  • the apparatus may generate a speed control command limiting the maximum speed of the motorized scooter based on the vehicle status of the motorized scooter.
  • the apparatus may transmit the speed control command to the motorized scooter.
  • the apparatus may continuously receive, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule.
  • the apparatus may determine a time instance to upgrade the firmware of the motorized scooter based on the vehicle status of the motorized scooter.
  • the apparatus may upgrade the firmware of the motorized scooter at the determined time instance.
  • the apparatus may receive a message from the mobile device.
  • the message may request locking the motorized scooter.
  • the apparatus may generate a lock request in response to the message when the motorized scooter is in an unlocking status.
  • the apparatus may transmit the lock request to the motorized scooter.
  • the apparatus may determine whether there is an active order associated with the motorized scooter when the motorized scooter is unlocked.
  • the apparatus may transmit a lock request to the motorized scooter when there is no active order associated with the motorized scooter and the motorized scooter is unlocked.
  • the apparatus may determine whether an order associated with the motorized scooter is active when the motorized scooter is locked. The apparatus may terminate the order when the order is active and the motorized scooter is locked.
  • FIG. 10 is a conceptual data flow diagram 1000 illustrating the data flow between different means/components in an exemplary apparatus 1002.
  • the apparatus 1002 may be a server (e.g., the server 102 or the MQTT server cluster 506).
  • the apparatus 1002 may include one or more computing devices.
  • the apparatus 1002 may include a reception component 1004 that receives status data and/or vehicle ID from a motorized scooter 1050.
  • the reception component 1004 may further receive messages from a mobile device 1055 that executes consumer app.
  • the reception component 1004 may perfonn the operations described above with reference to 902, 910, or 912 in FIG. 9.
  • the apparatus 1002 may include a transmission component 1010 that transmits commands to the motorized scooter 1050.
  • the transmission component 1010 may perfonn the operations described above with reference to 908 or 916 in FIG. 9.
  • the reception component 1004 and the transmission component 1010 may collaborate to coordinate the communication of the apparatus 1002.
  • the apparatus 1002 may include a status management component 1006 that is configured to store and manage the status data and/or vehicle ID received from the reception component 1004.
  • the status management component 1006 may perfonn the operations described above with reference to 904 in FIG. 9.
  • the apparatus 1002 may include a command generation component 1008 that is configured to generate commands based on messages received from the reception component 1004 and status data provided by the status management component 1006.
  • the generated commands may be provided to the transmission component 1010 for transmission to the motorized scooter 1050.
  • the command generation component 1008 may perfonn the operations described above with reference to 906 or 914 in FIG. 9.
  • the apparatus 1002 may include additional components that perfonn each of the blocks of the algorithm in the aforementioned flowchart of FIG. 9. As such, each block in the aforementioned flowchart of FIG. 9 may be performed by a component and the apparatus may include one or more of those components.
  • the components may be one or more hardware components specifically configured to carry out the stated processes/algorithm, implemented by a processor configured to perform the stated processes/algorithm, stored within a computer-readable medium for implementation by a processor, or some combination thereof.
  • FIG. 11 is a diagram 1100 illustrating an example of a hardware implementation for an apparatus 1002' employing a processing system 1114.
  • the apparatus 1002 may be the apparatus 1002 described above with reference to FIG. 10.
  • the processing system 1114 may be implemented with a bus architecture, represented generally by the bus 1124.
  • the bus 1124 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 1114 and the overall design constraints.
  • the bus 1124 links together various circuits including one or more processors and/or hardware components, represented by the processor 1104, the components 1004, 1006, 1008, 1010, and the computer-readable medium / memory 1106.
  • the bus 1124 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further.
  • the processing system 1114 may be coupled to a transceiver 1110.
  • the transceiver 1 110 is coupled to one or more antennas 1120.
  • the transceiver 1110 provides a means for communicating with various other apparatus over a transmission medium.
  • the transceiver 1110 receives a signal from the one or more antennas 1120, extracts information from the received signal, and provides the extracted information to the processing system 1114, specifically the reception component 1004.
  • the transceiver 1110 receives information from the processing system 1114, specifically the transmission component 1010, and based on the received information, generates a signal to be applied to the one or more antennas 1120.
  • the processing system 1114 includes a processor 1104 coupled to a computer- readable medium / memory 1106.
  • the processor 1104 is responsible for general processing, including the analyzation of data gathered by the apparatus itself through its own sensors and the execution of software stored on the computer-readable medium / memory 1106.
  • the software when executed by the processor 1104, causes the processing system 1114 to perform the various functions described supra for any particular apparatus.
  • the computer-readable medium / memory 1106 may also be used for storing data that is manipulated by the processor 1104 when executing software.
  • the processing system 1114 further includes at least one of the components 1004, 1006, 1008, 1010.
  • the components may be software components running in the processor 1104, resident/stored in the computer readable medium / memory 1106, one or more hardware components coupled to the processor 1104, or some combination thereof.
  • Example 1 is a method or apparatus for operating a motorized scooter.
  • the apparatus may be a part of the motorized scooter.
  • the apparatus may receive an unlock request from a remote server.
  • the apparatus may unlock itself in response to the unlock request.
  • the apparatus may continuously upload its status to the remote server based on a schedule when the apparatus is unlocked.
  • Example 2 the subject matter of Example 1 may optionally include that the apparatus may further receive a lock request from the remote server, and lock itself in response to the lock request.
  • Example 3 the subject matter of Example 2 may optionally include that an application program executing on a mobile device may receive a user input to lock the apparatus, where the application program may send a message to the remote serve to request locking the apparatus in response to the user input, where the lock request may be generated in response to the message when the apparatus is in an unlocking status.
  • Example 4 the subject matter of any one of Examples 1 to 3 may optionally include that an application program executing on a mobile device may scan a machine- readable optical label on the apparatus and send a vehicle identifier corresponding to the machine-readable optical label to the remote server, where the unlock request may be generated and transmitted based on the vehicle identifier.
  • Example 5 the subject matter of Example 4 may optionally include that the unlock request may be generated when the motorized scooter is in normal usable status.
  • Example 6 the subject matter of any one of Examples 1 to 5 may optionally include that the apparatus may further receive a speed control command from the remote server, and set the maximum speed of itself based on the speed control command.
  • Example 7 the subject matter of any one of Examples 1 to 6 may optionally include that the apparatus may establish a wireless connection with the remote server based on a wireless communication identifier associated with the apparatus and a vehicle identifier of the apparatus.
  • Example 8 is a method or apparatus for managing motorized scooters.
  • the apparatus may be a server.
  • the apparatus may receive, from a mobile device, a vehicle identifier of a motorized scooter.
  • the apparatus may retrieve the vehicle status of the motorized scooter based on the vehicle identifier.
  • the apparatus may generate an unlock request when the vehicle status is a normal usable status.
  • the apparatus may transmit the unlock request to the motorized scooter.
  • Example 9 the subject matter of Example 8 may optionally include that the apparatus may further continuously receive, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule.
  • Example 10 the subject matter of any one of Examples 8 to 9 may optionally include that the apparatus may further: receive a message from the mobile device, the message requesting locking the motorized scooter; generate a lock request in response to the message when the motorized scooter is in an unlocking status; and transmit the lock request to the motorized scooter.
  • Example 11 the subject matter of any one of Examples 8 to 10 may optionally include that an application program executing on the mobile device may scan a machine-readable optical label on the motorized scooter and send the vehicle identifier corresponding to the machine-readable optical label to the apparatus.
  • Example 12 the subject matter of any one of Examples 8 to 11 may optionally include that the apparatus may further: generate a speed control command limiting the maximum speed of the motorized scooter based on the vehicle status of the motorized scooter; and transmit the speed control command to the motorized scooter.
  • Example 13 the subject matter of any one of Examples 8 to 12 may optionally include that the apparatus may further establish a wireless connection with the motorized scooter based on a wireless communication identifier associated with the motorized scooter and the vehicle identifier of the motorized scooter.
  • Example 14 the subject matter of any one of Examples 8 to 13 may optionally include that the apparatus may further: determine whether there is an active order associated with the motorized scooter when the motorized scooter is unlocked; and transmit a lock request to the motorized scooter when there is no active order associated with the motorized scooter and the motorized scooter is unlocked.
  • Example 15 the subject matter of any one of Examples 8 to 14 may optionally include that the apparatus may further: determine whether an order associated with the motorized scooter is active when the motorized scooter is locked; and terminate the order when the order is active and the motorized scooter is locked.
  • Example 16 the subject matter of any one of Examples 8 to 15 may optionally include that the apparatus may further: determine a time instance to upgrade a firmware of the motorized scooter based on the vehicle status of the motorized scooter; and upgrade the firmware of the motorized scooter at the determined time instance.
  • Combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C.
  • combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C.

Abstract

A method, a computer readable medium, and an apparatus for operating a motorized scooter are provided. The apparatus may be a part of the motorized scooter. The apparatus may receive an unlock request from a remote server. The apparatus may unlock itself in response to the unlock request. The apparatus may continuously upload its status to the remote server based on a schedule when it is unlocked. The apparatus may receive a lock request from the remote server. The apparatus may lock itself in response to the lock request.

Description

INTERNET OF THINGS ARCHITECTURE FOR DEVICE SHARING
TECHNICAL FIELD
[0001] Various aspects of this disclosure generally relate to Internet of things (IoT), and more particularly, to an IoT architecture for device sharing.
BACKGROUND
[0002] The Internet of things (IoT) is the network of devices such as vehicles and home appliances that contain electronics, software, actuators, and connectivity which allows these things to connect, interact and exchange data. The IoT involves extending Internet connectivity beyond standard devices, such as desktops, laptops, smartphones and tablets, to any range of traditionally non-intemet-enabled physical devices and everyday objects. Embedded with technology, these devices can communicate and interact over the Internet, and they can be remotely monitored and controlled.
[0003] Mobile device sharing is a transportation innovation that is growing rapidly across cities. It solves the“last mile” problem by providing users an alternative device at better estimated time of arrival (ETA) and price than cars in crowded cities, reduces carbon emission, and provides a smarter transportation network to cities around the world. The future of urban mobility is shared, seamless, smart and environmentally- sustainable. Motorized scooters would be a good addition to the active mobility landscape, serving unmet demands in the first-mile-last-mile (FMLM) travel segment.
[0004] The key of mobile device sharing is IoT communications. The success of mobile device sharing depends on how well these devices respond to user commands (by mobile app) or instructions from the cloud. Consumers are demanding on the experiences so any infonnation delay is going to add friction to the user experience. Security is a core requirement as the devices are intelligent assets being deployed in the wild on their own and potentially vulnerable to hacking, theft, as well as other forms of sabotage. SUMMARY
[0005] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified fonn as a prelude to the more detailed description that is presented later.
[0006] In an aspect of the disclosure, a method, a computer readable medium, and an apparatus for operating a motorized scooter are provided. The apparatus may be a part of the motorized scooter. The apparatus may receive an unlock request from a remote server. The apparatus may unlock itself in response to the unlock request. The apparatus may continuously upload its status to the remote server based on a schedule when it is unlocked. The apparatus may receive a lock request from the remote server. The apparatus may lock itself in response to the lock request.
[0007] In another aspect of the disclosure, a method, a computer readable medium, and an apparatus for managing motorized scooters are provided. The apparatus may be a server. The apparatus may receive, from a mobile device, a vehicle identifier of a motorized scooter. The apparatus may retrieve a vehicle status of the motorized scooter based on the vehicle identifier. The apparatus may generate an unlock request when the vehicle status is a normal usable status. The apparatus may transmit the unlock request to the motorized scooter. The apparatus may continuously receive, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule. The apparatus may receive a message from the mobile device, the message requesting locking the motorized scooter. The apparatus may generate a lock request in response to the message when the motorized scooter is in an unlocking status. The apparatus may transmit the lock request to the motorized scooter.
[0008] To the accomplishment of the foregoing and related ends, the one or more aspects include the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 is a diagram illustrating an example of a networking IoT system for device sharing.
[0010] FIG. 2 is a diagram illustrating an example of triple lock methods that include scanning Quick Response Code, geo-fence, and backend remote control.
[0011] FIG. 3 is a diagram illustrating an example of an IoT device.
[0012] FIG. 4 is a diagram illustrating an example of hardware structure of an IoT communication module.
[0013] FIG. 5 is a diagram illustrating an example of the components of an IoT system.
[0014] FIG. 6 is a flowchart of a method of operating a motorized scooter.
[0015] FIG. 7 is a conceptual data flow diagram illustrating the data flow between different means/components in an exemplary apparatus.
[0016] FIG. 8 is a diagram illustrating an example of a hardware implementation for an apparatus employing a processing system.
[0017] FIG. 9 is a flowchart of a method of managing motorized scooters.
[0018] FIG. 10 is a conceptual data flow diagram illustrating the data flow between different means/components in an exemplary apparatus.
[0019] FIG. 11 is a diagram illustrating an example of a hardware implementation for an apparatus employing a processing system.
DETAILED DESCRIPTION
[0020] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts. [0021] Several aspects of an IoT architecture for device sharing will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.
[0022] By way of example, an element, or any portion of an element, or any combination of elements may be implemented as a“processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoC), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.
[0023] Accordingly, in one or more example embodiments, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media may include a random-access memory (RAM), a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.
[0024] Most of the shared bike and scooter operations in the market have limited IoT capabilities. Bluetooth connection is the most common solution used. There are a few drawbacks came with the Bluetooth solution. First, the Bluetooth solution lacks centralized control, which makes effective management of the devices almost impossible. No vehicle information such as Global Positioning System (GPS) location, vehicle status, battery level is maintained at the backend. This adds difficulty to daily operations and maintenance. Second, compatibility problems of the Bluetooth solution is well known among mobile devices. As a result, the communication between the phones and the smart locks may malfunction in quite a few circumstances. Third, the user experiences of the Bluetooth solution are far from satisfactory due to the significant latency incurred during the communication with the devices.
[0025] To address the problems mentioned above, a networking IoT system is provided. In the IoT system, IoT devices have to maintain persistent connection round-the- clock (with possible retries to connect). This way, the IoT devices are free to upload any device information to the server side at any time. And the cloud service may store and maintain the status of all the devices in databases, which may be checked by the operations staff as per their permissions. Besides, when necessary, the server cluster may push certain commands to the IoT devices to proactively control their behaviors, such as locking/unlocking, forcing over-the-air (OTA) update, setting top speed, and stopping any abnormal behaviors. In addition, unified subscriber identity module (SIM) cards may be installed into all the IoT devices, which eliminates the potential compatibility problems. Lastly, the fully bidirectional networking channel, along with the extremely lean data packets transferred, enables super-fast communication between the server and the IoT devices and smooth user experiences of using the vehicles.
[0026] FIG. 1 is a diagram 100 illustrating an example of a networking IoT system for device sharing. In the example, the IoT system may include a server 102 and several IoT devices 110, 112 ..., 114. The server 102 may include one or more computing devices (e.g., apparatus 1002/1002’ described below with reference to FIG. 10 or 11). In some embodiments, each of the IoT devices 110, 112 ..., 114 may be a motorized scooter. In some embodiments, each of the IoT devices 110, 112 ..., 114 may be the apparatus 702/702’ described below with reference to FIG. 7 or 8).
[0027] In some embodiments, the server 102 and the IoT devices 110, 112 ..., 114 may maintain persistent connections round-the-clock (with possible retries to connect/re connect). Each of the IoT devices 110, 112 ..., 114 may upload its device information to the server 102. The server 102 may push commands to each of the IoT devices 110, 112 ..., 114 to control their behaviours, such as locking/unlocking, forcing over-the-air (OTA) update, setting top speed, and stopping any abnormal behaviors.
[0028] In some embodiments, binary data format may be used to carry out the communication between the IoT devices 110, 112 ..., 114 and the server 102. This binary data fonnat may be proprietary and thus hard to decrypt. In some embodiments, end-to-end encryption may add an extra layer of security to the data transferred. In some embodiments, security check may be triggered when an IoT device tries to establish connections with the server 102, which only allows the right pair of International Mobile Equipment Identity (IMEI) and vehicle number to pass.
[0029] In some embodiments, binary compact data fonnat may make the data hard to crack and small in size. Also, the least amount of bytes may be used to present each data type accurately. In some embodiments, different endpoint calls may be combined into a single one whenever possible to reduce the latency of core flows such as unlocking/locking, that is to say, to carry out batch processing. For example, during unlocking, the commands to unlock the scooter, ask for vehicle location, set proper speed limit may be combined into one to issue to the scooter.
[0030] In some embodiments, scanning Quick Response Code (QR code) to unlock a motorized scooter may be completed in under 5 seconds with reminder music; and this reminder music may be dynamically configured based on time, location and the identifier of the motorized scooter, e.g., Jingle Bells on Christmas Eve. In some embodiments, the locking/unlocking process may include several interactions, but still may be completed under 5 seconds.
[0031] There is always a risk of IoT connection failure (i.e., due to the failure of Internet connection). In some embodiments, a supplementary process may be added to establish regular checks (initiated from backend server) on the connection, lock status, and order status. In some embodiments, the supplementary process may be implemented to scan the full system and live order status every few seconds. In the situation where there is no order but the scooter unlocked, locking may be triggered (to prevent loss and theft). In situations where user order active but scooter locked, the user order may be terminated to prevent overcharging. This makes the system intelligent and capable of self-recovery from any issue caused by IoT connection failure.
[0032] An example of the unlocking process is described below:
Bl : User app scans the QR code and passes the vehicle number to the backend server;
B2: Backend server retrieves vehicle status. If it is in normal usable status, then the unlock request is sent to IoT after conversion protocol;
B3: IoT receives the unlock request and decides whether the unlock request is valid. If it is valid, it unlocks and plays the unlock music. If it is invalid, it returns unlock failure to the backend server.
[0033] An example of the locking process is described below:
Bl : The user clicks the lock button through the user app, which transmits the lock infonnation to the backend server;
B2: Retrieve the vehicle status in the backend server. If the vehicle is unlocking status, the lock request will be sent to IoT after the conversion protocol.
B3: IoT receives the lock instruction to determine whether the lock instruction is valid. If it is valid, it locks the vehicle and plays the lock music. If it is invalid, it returns lock failure to the backend server.
[0034] An example of the supplementary locking process is described below:
Bl : IoT uploads the current status to the backend server every 30 seconds when it is in unlocking status;
B2: After receiving the status via IoT upload, the backend server determines whether there is an illegal lock status, and if there is, generates the lock instruction to avoid illegal riding.
[0035] In some embodiments, wireless mobile communication data and short message service (SMS) seamless switch backup communication ensures higher than 90% unlock successful rate. In some embodi ents, X seconds after the server issues unlocking/locking command to the IoT device, the server would send an SMS message down to the IoT device if no networking response is given from the device side. And the same is applied for the uplink from IoT device to the server. The X above may be dynamically adjusted at the backend server according to the real-time distribution of the unlocking durations among the sessions during a certain time period.
[0036] FIG. 2 is a diagram 200 illustrating an example of triple lock methods that include scanning QR code, geo-fence, and backend remote control. In some embodiments, triple lock methods may ensure higher than 95% lock rate. In the example, at 204, the user may scan parking QR code associated with the parking location. At 206, the backend server may check the parking location and the location of the IoT device. At 208, if the parking location and the location of the IoT device matches, the backend server may send a locking request to the IoT device to lock the motorized scooter.
[0037] In some embodiments, the highest riding speed of the motorized scooter may be dynamically remote controlled, which ensures user safety. In some embodiments, top speed for scooters may be lowered in certain scenarios. Examples of these scenarios include: low speed zones for certain locations, low speed profiles for uncertified/beginner users, and low speed periods after dark. In some embodiments, fleet (or any individual scooter’s) top speed may be controlled based on specific user, geo-fence, lighting conditions, hours of day, weather condition, etc.
[0038] In some embodiments, vehicle data may be tracked close to real time (e.g., every 30 seconds upload when vehicles are on trip, every 30 min upload when vehicle are not hired). This allows several additional functions to be performed on operations. In some embodiments, vehicle location, status, as well as basic information such as battery level may be tracked to aid fleet management.
[0039] In some embodiments, operations personnel may be able to get real-time map and status information on high-risk scooters such as those that are low on battery power, and those that are not returned to proper parking lots by users. In some embodiments, a proprietary-designed app may facilitate the search of stray scooters by allowing operations personnel to tap on either the Chirp or Flash button features to sound the chime or switch on the headlights on scooters, to make it easier for staff to locate improperly parked scooters. In some embodiments, a new feature may be introduced within the operations management system to automate stray scooter alerts. For example, scooters that are not parked at the designated lots are being alerted in real time through the operations management system. This will help reduce stray recover time. In some embodiments, visualization of all stray scooters and their locations relative to deployment areas and proper parking lots may be presented onto a map.
[0040] In some embodiments, it may be possible to remotely trigger commands to the fleet. The remotely triggered commands may include lock, unlock, and managing power, speed, IoT connection status, etc. In an effort to increase safety of users and pedestrians, some embodiments may implement auto-on of headlights after dark for a selected fleet of scooters. Some embodiments may implement always-on headlight after dark for all rides.
[0041] In some embodiments, the firmware of each motorized scooter may be dynamically upgraded based on time, location, and scooter identifier (ID) through encrypted over-air channel. And this over-the-air (OTA) upgrade may be executed automatically according to the preset conditions.
[0042] An example of the OTA upgrade process is described below:
AT. Backend servers may actively issue forced OTA upgrade instructions to specified IoT or IoT timing retrieval (random distribution of retrieval time points for each IoT device) if there is a valid new version available for upgrading.
A2: After starting OTA upgrade, the IoT device downloads the matching version from OTA server. After downloading, it upgrades automatically to the latest version and completes the OTA upgrade process.
[0043] In some embodiments, the OTA upgrade process may be initiated by server side. To realize sustainability (in case of emergency OTA, hot fixes, and frequent needs of upgrade), the OTA upgrade capability may be implemented from the backend server. As a result, good stability may be achieved even with the additional challenges.
[0044] In some embodiments, the OTA upgrade may be scheduled in specific times. This is very critical because it is undesirable to do OTA upgrade when fleet is in service. In some embodiments, it may be possible to schedule the OTA upgrade for a specific fleet during a specific time when the fleet is in maintenance or before-deployment. Also due to concern of jamming network during peak time (e.g., connection failures are likely to happen if the entire 5000 fleet performs OTA upgrade), an intelligent solution may be implemented to automatically optimize this OTA upgrade process for best stability and success rate. First, a few scooters within the fleet may be picked randomly to initiate OTA upgrade. Depending on the result of the OTA upgrade for the first batch of scooters, the system may automatically trigger the next batch (including determining the size of the next batch) and send alerts if needed during the process. The size of each batch may be optimized for best results and success rate as well as to avoid network jam.
[0045] FIG. 3 is a diagram illustrating an example of an IoT device 300. In some embodiments, the IoT device 300 may be a motorized scooter equipped with an IoT communication module 302, which may be an external box attached to the motorized scooter. The IoT communication module 302 may enable optimization of the operations or maintenance of the motorized scooter so that efficiency may be achieved. For example, the motorized scooter may be unlocked/locked by scanning the QR code. The unlock time may be less than 5 seconds, and the success rate may be higher than 90%. In some embodiments, user riding data (e.g., when you ride, where you are riding, how long you ride, etc.) may be collected in real-time. In some embodiments, the real-time data of the motorized scooter (e.g., the speed, the power volume, how far has already ride, falling down on the ground or not, etc.) may be collected. In some embodiments, customized human-machine interface (e.g., unlock or lock reminder, alarm, etc.) may be provided to users.
[0046] In some embodiments, the IoT communication module 302 may serve to track the scooters’ service status and location at any given time. The IoT communication module 302 also makes it possible to transmit commands to the scooters via cloud server. In addition, the IoT communication module 302 may contain an internal speaker for unlocking/locking indication and alerting the sensors for any abnormal activities detected (e.g., falling down, abnormal movement, etc.) to enhance operational efficiency.
[0047] In some embodiments, the design of the antenna of the IoT communication module 302 may be optimized for sharing scenario. In some embodiments, the electronics of the IoT device 300 may be fail safe for electric failure and battery safety. The design of the IoT device 300 is focused on optimizing for user experience (e.g., unlock, lock) so user spends as little time interacting with the app as possible. The product is designed specifically for situations of theft and sabotage, which is known issues in the shared device industry.
[0048] FIG. 4 is a diagram illustrating an example of hardware structure of an IoT communication module 400. In some embodiments, the IoT communication module 400 may be the IoT communication module 302 described above in FIG. 3. In the example, the IoT communication module 400 may include a communication module 402, a lock control module 404, an application processing module 406, a sensor module 408, an energy management module 410, a control module 412, a driver module 414, a chipset platform 418, and a system management module 416.
[0049] In some embodiments, IoT firmware may support“cellular wireless data and SMS seamless backup” unlock method, which ensure the higher than 90% unlock successful rate. In some embodiments, IoT firmware may support triple lock methods (scanning QR code, geo-fence, and backend remote control) to ensure higher than 95% lock rate. In some embodiments, the highest riding speed may be dynamically remotely configured for each motorized scooter by the control module 412.
[0050] FIG. 5 is a diagram illustrating an example of the components of an IoT system 500. In the example, the IoT system 500 may include a message queue 502, a Message Queuing Telemetry Transport (MQTT) server cluster 506, smart devices 508, MQTT host routing and message assembly/resolution component 510, a registration center 512, a core transaction layer 516, an app gateway 518, a consumer app 520, an operation gateway 522, and an operations app 526.
[0051] The smart devices 508 may include several IoT devices described above with reference to FIGS. 1-4. The highly optimized MQTT server cluster 506 or the extremely lightweight data protocol may be easily extended to support millions of connections to IoT devices. The message queue 502 sits between the transaction system (e.g., the core transaction layer 516) and the MQTT server cluster 506, and all the communications between these two parties have to go through the message queue 502. This effectively eliminates the coupling between these two sets of systems, and the entire architecture benefits from the high scalability of the message queue 502. In some embodiments, the IoT system 500 may have theoretically as many frontend MQTT servers as possible. The MQTT server cluster 506 connects directly with the IoT devices, and throw arbitrary number of messages received from the IoT devices to the message queue 502. Then, the multiple transaction systems sitting on the other side of the message queue 502 may choose to consumer the messages at any speed as they like, depending on their computing capacity at any given time, and may even decide to give up those messages that they do not care about.
[0052] The message queue 502 takes the role of routing various messages between the MQTT server cluster 506 and the core transaction layer 516. In some embodiments, micro- service backend transaction system makes every service decoupled from each other, thus enabling managing different aspects of vehicle data separately, which helps to improve the robustness and security of the entire set of services.
[0053] FIG. 6 is a flowchart 600 of a method of operating a motorized scooter. The motorized scooter may be an IoT device described above with reference to FIGS. 1-5. The method may be performed by an apparatus (e.g., apparatus 702/702’ described below with reference to FIG. 7 or 8). In some embodiments, the apparatus may be a motorized scooter. In some embodiments, the apparatus may be the IoT component of a motorized scooter.
[0054] At 602, the apparatus may receive an unlock request from a remote server. In some embodiments, an application program executing on a mobile device may scan a machine-readable optical label (e.g., a QR code) on the motorized scooter and send a vehicle identifier corresponding to the machine-readable optical label to the remote server. The unlock request may be generated and transmitted, by the remote server, based on the vehicle identifier. In some embodiments, the unlock request may be generated when the motorized scooter is in normal usable status. In some embodiments, the apparatus may establish a wireless connection with the remote server based on a wireless communication identifier associated with the motorized scooter and a vehicle identifier of the motorized scooter.
[0055] At 604, the apparatus may unlock the motorized scooter in response to the unlock request. In some embodiments, the apparatus may receive a speed control command from the remote server. The apparatus may set the maximum speed of the motorized scooter based on the speed control command.
[0056] At 606, the apparatus may continuously upload status of the motorized scooter to the remote server based on a schedule when the motorized scooter is unlocked.
[0057] At 608, the apparatus may receive a lock request from the remote server. In some embodiments, an application program executing on a mobile device may receive a user input to lock the motorized scooter, and send a message to the remote serve to request locking the motorized scooter in response to the user input. The lock request may be generated by the remote server in response to the message when the motorized scooter is in an unlocking status.
[0058] At 610, the apparatus may lock the motorized scooter in response to the lock request. [0059] FIG. 7 is a conceptual data flow diagram 700 illustrating the data flow between different means/components in an exemplary apparatus 702. The apparatus 702 may be an IoT device (e.g., the IoT device 110, 112, 114, or 300, or the smart devices 508). The apparatus 702 may include a reception component 704 that receives control commands from a remote server 750. In one embodiment, the reception component 704 may perfonn the operations described above with reference to 602 or 608 in FIG. 6.
[0060] The apparatus 702 may include a transmission component 710 that transmits status of the apparatus 702 to the remote server 750. In one embodiment, the transmission component 710 may perform the operations described above with reference to 606 in FIG. 6. The reception component 704 and the transmission component 710 may collaborate to coordinate the communication of the apparatus 702.
[0061] The apparatus 702 may include a control component 706 that is configured to control the operation of the apparatus 702 based on the commands received from the reception component 704. In one embodiment, the control component 706 may perfonn the operations described above with reference to 604 or 610 in FIG. 6.
[0062] The apparatus 702 may include a data collection component 708 that is configured to collect status data of the apparatus 702 and provide the collected status data to the transmission component 710 for transmission to the remote server 750. In one embodiment, the data collection component 708 may perform the operations described above with reference to 606 in FIG. 6.
[0063] The apparatus 702 may include additional components that perform each of the blocks of the algorithm in the aforementioned flowchart of FIG. 6. As such, each block in the aforementioned flowchart of FIG. 6 may be performed by a component and the apparatus may include one or more of those components. The components may be one or more hardware components specifically configured to carry out the stated processes/algorithm, implemented by a processor configured to perfonn the stated processes/algorithm, stored within a computer-readable medium for implementation by a processor, or some combination thereof.
[0064] FIG. 8 is a diagram 800 illustrating an example of a hardware implementation for an apparatus 702' employing a processing system 814. In one embodiment, the apparatus 702’ may be the apparatus 702 described above with reference to FIG. 7. The processing system 814 may be implemented with a bus architecture, represented generally by the bus 824. The bus 824 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 814 and the overall design constraints. The bus 824 links together various circuits including one or more processors and/or hardware components, represented by the processor 804, the components 704, 706, 708, 710, and the computer-readable medium / memory 806. The bus 824 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further.
[0065] The processing system 814 may be coupled to a transceiver 810. The transceiver 810 is coupled to one or more antennas 820. The transceiver 810 provides a means for communicating with various other apparatus over a transmission medium. The transceiver 810 receives a signal from the one or more antennas 820, extracts information from the received signal, and provides the extracted information to the processing system 814, specifically the reception component 704. In addition, the transceiver 810 receives information from the processing system 814, specifically the transmission component 710, and based on the received information, generates a signal to be applied to the one or more antennas 820.
[0066] The processing system 814 includes a processor 804 coupled to a computer- readable medium / memory 806. The processor 804 is responsible for general processing, including the analyzation of data gathered by the apparatus itself through its own sensors and the execution of software stored on the computer-readable medium / memory 806. The software, when executed by the processor 804, causes the processing system 814 to perfonn the various functions described supra for any particular apparatus. The computer- readable medium / memory 806 may also be used for storing data that is manipulated by the processor 804 when executing software. The processing system 814 further includes at least one of the components 704, 706, 708, 710. The components may be software components running in the processor 804, resident/stored in the computer readable medium / memory 806, one or more hardware components coupled to the processor 804, or some combination thereof.
[0067] FIG. 9 is a flowchart 900 of a method of managing motorized scooters. Each of the motorized scooters may be an IoT device described above with reference to FIGS. 1-8. The method may be perfonned by an apparatus (e.g., apparatus 1002/1002’ described below with reference to FIG. 10 or 11). In some embodiments, the apparatus may be a server that includes one or more computing devices.
[0068] At 902, the apparatus may receive, from a mobile device, a vehicle identifier of a motorized scooter. In some embodiments, an application program executing on the mobile device may scan a machine-readable optical label (e.g., a QR code) on the motorized scooter and send the vehicle identifier corresponding to the machine-readable optical label to the server. In some embodiments, the apparatus may establish a wireless connection with the motorized scooter based on a wireless communication identifier associated with the motorized scooter and a vehicle identifier of the motorized scooter.
[0069] At 904, the apparatus may retrieve the vehicle status of the motorized scooter based on the vehicle identifier.
[0070] At 906, the apparatus may generate an unlock request when the vehicle status is a normal usable status.
[0071] At 908, the apparatus may transmit the unlock request to the motorized scooter. In some embodiments, the apparatus may generate a speed control command limiting the maximum speed of the motorized scooter based on the vehicle status of the motorized scooter. The apparatus may transmit the speed control command to the motorized scooter.
[0072] At 910, the apparatus may continuously receive, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule. In some embodiments, the apparatus may determine a time instance to upgrade the firmware of the motorized scooter based on the vehicle status of the motorized scooter. The apparatus may upgrade the firmware of the motorized scooter at the determined time instance.
[0073] At 912, the apparatus may receive a message from the mobile device. The message may request locking the motorized scooter.
[0074] At 914, the apparatus may generate a lock request in response to the message when the motorized scooter is in an unlocking status.
[0075] At 916, the apparatus may transmit the lock request to the motorized scooter. In some embodiments, the apparatus may determine whether there is an active order associated with the motorized scooter when the motorized scooter is unlocked. The apparatus may transmit a lock request to the motorized scooter when there is no active order associated with the motorized scooter and the motorized scooter is unlocked. In some embodiments, the apparatus may determine whether an order associated with the motorized scooter is active when the motorized scooter is locked. The apparatus may terminate the order when the order is active and the motorized scooter is locked.
[0076] FIG. 10 is a conceptual data flow diagram 1000 illustrating the data flow between different means/components in an exemplary apparatus 1002. The apparatus 1002 may be a server (e.g., the server 102 or the MQTT server cluster 506). The apparatus 1002 may include one or more computing devices. The apparatus 1002 may include a reception component 1004 that receives status data and/or vehicle ID from a motorized scooter 1050. The reception component 1004 may further receive messages from a mobile device 1055 that executes consumer app. In one embodiment, the reception component 1004 may perfonn the operations described above with reference to 902, 910, or 912 in FIG. 9.
[0077] The apparatus 1002 may include a transmission component 1010 that transmits commands to the motorized scooter 1050. In one embodiment, the transmission component 1010 may perfonn the operations described above with reference to 908 or 916 in FIG. 9. The reception component 1004 and the transmission component 1010 may collaborate to coordinate the communication of the apparatus 1002.
[0078] The apparatus 1002 may include a status management component 1006 that is configured to store and manage the status data and/or vehicle ID received from the reception component 1004. In one embodiment, the status management component 1006 may perfonn the operations described above with reference to 904 in FIG. 9.
[0079] The apparatus 1002 may include a command generation component 1008 that is configured to generate commands based on messages received from the reception component 1004 and status data provided by the status management component 1006. The generated commands may be provided to the transmission component 1010 for transmission to the motorized scooter 1050. In one embodiment, the command generation component 1008 may perfonn the operations described above with reference to 906 or 914 in FIG. 9.
[0080] The apparatus 1002 may include additional components that perfonn each of the blocks of the algorithm in the aforementioned flowchart of FIG. 9. As such, each block in the aforementioned flowchart of FIG. 9 may be performed by a component and the apparatus may include one or more of those components. The components may be one or more hardware components specifically configured to carry out the stated processes/algorithm, implemented by a processor configured to perform the stated processes/algorithm, stored within a computer-readable medium for implementation by a processor, or some combination thereof.
[0081] FIG. 11 is a diagram 1100 illustrating an example of a hardware implementation for an apparatus 1002' employing a processing system 1114. In one embodiment, the apparatus 1002’ may be the apparatus 1002 described above with reference to FIG. 10. The processing system 1114 may be implemented with a bus architecture, represented generally by the bus 1124. The bus 1124 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 1114 and the overall design constraints. The bus 1124 links together various circuits including one or more processors and/or hardware components, represented by the processor 1104, the components 1004, 1006, 1008, 1010, and the computer-readable medium / memory 1106. The bus 1124 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further.
[0082] The processing system 1114 may be coupled to a transceiver 1110. The transceiver 1 110 is coupled to one or more antennas 1120. The transceiver 1110 provides a means for communicating with various other apparatus over a transmission medium. The transceiver 1110 receives a signal from the one or more antennas 1120, extracts information from the received signal, and provides the extracted information to the processing system 1114, specifically the reception component 1004. In addition, the transceiver 1110 receives information from the processing system 1114, specifically the transmission component 1010, and based on the received information, generates a signal to be applied to the one or more antennas 1120.
[0083] The processing system 1114 includes a processor 1104 coupled to a computer- readable medium / memory 1106. The processor 1104 is responsible for general processing, including the analyzation of data gathered by the apparatus itself through its own sensors and the execution of software stored on the computer-readable medium / memory 1106. The software, when executed by the processor 1104, causes the processing system 1114 to perform the various functions described supra for any particular apparatus. The computer-readable medium / memory 1106 may also be used for storing data that is manipulated by the processor 1104 when executing software. The processing system 1114 further includes at least one of the components 1004, 1006, 1008, 1010. The components may be software components running in the processor 1104, resident/stored in the computer readable medium / memory 1106, one or more hardware components coupled to the processor 1104, or some combination thereof.
[0084] In the following, various aspects of this disclosure will be illustrated:
[0085] Example 1 is a method or apparatus for operating a motorized scooter. The apparatus may be a part of the motorized scooter. The apparatus may receive an unlock request from a remote server. The apparatus may unlock itself in response to the unlock request. The apparatus may continuously upload its status to the remote server based on a schedule when the apparatus is unlocked.
[0086] In Example 2, the subject matter of Example 1 may optionally include that the apparatus may further receive a lock request from the remote server, and lock itself in response to the lock request.
[0087] In Example 3, the subject matter of Example 2 may optionally include that an application program executing on a mobile device may receive a user input to lock the apparatus, where the application program may send a message to the remote serve to request locking the apparatus in response to the user input, where the lock request may be generated in response to the message when the apparatus is in an unlocking status.
[0088] In Example 4, the subject matter of any one of Examples 1 to 3 may optionally include that an application program executing on a mobile device may scan a machine- readable optical label on the apparatus and send a vehicle identifier corresponding to the machine-readable optical label to the remote server, where the unlock request may be generated and transmitted based on the vehicle identifier.
[0089] In Example 5, the subject matter of Example 4 may optionally include that the unlock request may be generated when the motorized scooter is in normal usable status.
[0090] In Example 6, the subject matter of any one of Examples 1 to 5 may optionally include that the apparatus may further receive a speed control command from the remote server, and set the maximum speed of itself based on the speed control command.
[0091] In Example 7, the subject matter of any one of Examples 1 to 6 may optionally include that the apparatus may establish a wireless connection with the remote server based on a wireless communication identifier associated with the apparatus and a vehicle identifier of the apparatus. [0092] Example 8 is a method or apparatus for managing motorized scooters. The apparatus may be a server. The apparatus may receive, from a mobile device, a vehicle identifier of a motorized scooter. The apparatus may retrieve the vehicle status of the motorized scooter based on the vehicle identifier. The apparatus may generate an unlock request when the vehicle status is a normal usable status. The apparatus may transmit the unlock request to the motorized scooter.
[0093] In Example 9, the subject matter of Example 8 may optionally include that the apparatus may further continuously receive, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule.
[0094] In Example 10, the subject matter of any one of Examples 8 to 9 may optionally include that the apparatus may further: receive a message from the mobile device, the message requesting locking the motorized scooter; generate a lock request in response to the message when the motorized scooter is in an unlocking status; and transmit the lock request to the motorized scooter.
[0095] In Example 11, the subject matter of any one of Examples 8 to 10 may optionally include that an application program executing on the mobile device may scan a machine-readable optical label on the motorized scooter and send the vehicle identifier corresponding to the machine-readable optical label to the apparatus.
[0096] In Example 12, the subject matter of any one of Examples 8 to 11 may optionally include that the apparatus may further: generate a speed control command limiting the maximum speed of the motorized scooter based on the vehicle status of the motorized scooter; and transmit the speed control command to the motorized scooter.
[0097] In Example 13, the subject matter of any one of Examples 8 to 12 may optionally include that the apparatus may further establish a wireless connection with the motorized scooter based on a wireless communication identifier associated with the motorized scooter and the vehicle identifier of the motorized scooter.
[0098] In Example 14, the subject matter of any one of Examples 8 to 13 may optionally include that the apparatus may further: determine whether there is an active order associated with the motorized scooter when the motorized scooter is unlocked; and transmit a lock request to the motorized scooter when there is no active order associated with the motorized scooter and the motorized scooter is unlocked. [0099] In Example 15, the subject matter of any one of Examples 8 to 14 may optionally include that the apparatus may further: determine whether an order associated with the motorized scooter is active when the motorized scooter is locked; and terminate the order when the order is active and the motorized scooter is locked.
[00100] In Example 16, the subject matter of any one of Examples 8 to 15 may optionally include that the apparatus may further: determine a time instance to upgrade a firmware of the motorized scooter based on the vehicle status of the motorized scooter; and upgrade the firmware of the motorized scooter at the determined time instance.
[00101] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
[00102] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean“one and only one” unless specifically so stated, but rather“one or more.” The word“exemplary” is used herein to mean“serving as an example, instance, or illustration.” Any aspect described herein as“exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term“some” refers to one or more. Combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ include any combination of A, B, and/or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as“at least one of A, B, or C,”“one or more of A, B, or C,”“at least one of A, B, and C,”“one or more of A, B, and C,” and“A, B, C, or any combination thereof’ may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module,” “mechanism,” “element,”“device,” and the like may not be a substitute for the word“means.” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase“means for.”

Claims

CLAIMS WHAT IS CLAIMED IS:
1. A method of operating a motorized scooter, the method comprising:
receiving, at the motorized scooter, an unlock request from a remote server;
unlocking the motorized scooter in response to the unlock request; and
continuously uploading status of the motorized scooter to the remote server based on a schedule when the motorized scooter is unlocked.
2. The method of claim 1, further comprising:
receiving, at the motorized scooter, a lock request from the remote server; and locking the motorized scooter in response to the lock request.
3. The method of claim 1 or 2, further comprising:
receiving, at the motorized scooter, a speed control command from the remote server; and
setting a maximum speed of the motorized scooter based on the speed control command.
4. The method of any one of claims 1-3, further comprising:
establishing a wireless connection with the remote server based on a wireless communication identifier associated with the motorized scooter and a vehicle identifier of the motorized scooter.
5. A method of managing motorized scooters, the method comprising:
receiving, at a server from a mobile device, a vehicle identifier of a motorized scooter;
retrieving a vehicle status of the motorized scooter based on the vehicle identifier; generating an unlock request when the vehicle status is a normal usable status; and transmitting the unlock request to the motorized scooter.
6. The method of claim 5, further comprising:
continuously receiving, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule.
7. The method of claim 5 or 6, further comprising:
receiving, at the server, a message from the mobile device, the message requesting locking the motorized scooter;
generating a lock request in response to the message when the motorized scooter is in an unlocking status; and
transmitting the lock request to the motorized scooter.
8. The method of any one of claims 5-7, further comprising:
generating a speed control command limiting a maximum speed of the motorized scooter based on the vehicle status of the motorized scooter; and
transmitting the speed control command to the motorized scooter.
9. The method of any one of claims 5-8, further comprising:
detennining whether there is an active order associated with the motorized scooter when the motorized scooter is unlocked; and
transmitting a lock request to the motorized scooter when there is no active order associated with the motorized scooter and the motorized scooter is unlocked.
10. The method of any one of claim 5-9, further comprising:
determining whether an order associated with the motorized scooter is active when the motorized scooter is locked; and
terminating the order when the order is active and the motorized scooter is locked.
11. The method of any one of claims 5-10, further comprising:
detennining a time instance to upgrade a finnware of the motorized scooter based on the vehicle status of the motorized scooter; and
upgrading the finnware of the motorized scooter at the determined time instance.
12. An apparatus for operating a motorized scooter, the apparatus being a part of a motorized scooter, the apparatus comprising:
a memory; and
at least one processor coupled to the memory and configured to:
receive an unlock request from a remote server;
unlock the motorized scooter in response to the unlock request; and continuously upload status of the motorized scooter to the remote server based on a schedule when the motorized scooter is unlocked.
13. The apparatus of claim 12, wherein the at least one processor is further configured to:
receive a lock request from the remote server; and
lock the motorized scooter in response to the lock request.
14. The apparatus of claim 12 or 13, wherein the at least one processor is further configured to:
receive a speed control command from the remote server; and
set a maximum speed of the motorized scooter based on the speed control command.
15. The apparatus of any one of claims 12-14, wherein the at least one processor is further configured to:
establish a wireless connection with the remote server based on a wireless communication identifier associated with the motorized scooter and a vehicle identifier of the motorized scooter.
16. An apparatus for managing motorized scooters, the apparatus being a server, the apparatus comprising:
a memory; and
at least one processor coupled to the memory and configured to:
receive, from a mobile device, a vehicle identifier of a motorized scooter; retrieve a vehicle status of the motorized scooter based on the vehicle identifier;
generate an unlock request when the vehicle status is a normal usable status; and
transmit the unlock request to the motorized scooter.
17. The apparatus of claim 16, wherein the at least one processor is further configured to:
continuously receive, from the motorized scooter, the vehicle status of the motorized scooter based on a schedule.
18. The apparatus of claim 16 or 17, wherein the at least one processor is further configured to:
receive a message from the mobile device, the message requesting locking the motorized scooter;
generate a lock request in response to the message when the motorized scooter is in an unlocking status; and
transmit the lock request to the motorized scooter.
19. The apparatus of any one of claims 16-18, wherein the at least one processor is further configured to:
generate a speed control command limiting a maximum speed of the motorized scooter based on the vehicle status of the motorized scooter; and
transmit the speed control command to the motorized scooter.
20. The apparatus of any one of claims 16-19, wherein the at least one processor is further configured to:
determine whether there is an active order associated with the motorized scooter when the motorized scooter is unlocked; and
transmit a lock request to the motorized scooter when there is no active order associated with the motorized scooter and the motorized scooter is unlocked.
21. The apparatus of any one of claim 16-20, wherein the at least one processor is further configured to:
determine whether an order associated with the motorized scooter is active when the motorized scooter is locked; and
terminate the order when the order is active and the motorized scooter is locked.
22. The apparatus of any one of claims 16-21, wherein the at least one processor is further configured to:
determine a time instance to upgrade a fmnware of the motorized scooter based on the vehicle status of the motorized scooter; and
upgrade the fmnware of the motorized scooter at the detennined time instance.
PCT/SG2019/050201 2019-04-10 2019-04-10 Internet of things architecture for device sharing WO2020209789A1 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
SG11202108912TA SG11202108912TA (en) 2019-04-10 2019-04-10 Internet of things architecture for device sharing
PCT/SG2019/050201 WO2020209789A1 (en) 2019-04-10 2019-04-10 Internet of things architecture for device sharing
CN201980095211.9A CN113647122A (en) 2019-04-10 2019-04-10 Internet of things architecture for device sharing
TW109111838A TW202046755A (en) 2019-04-10 2020-04-08 Internet of things architecture for device sharing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2019/050201 WO2020209789A1 (en) 2019-04-10 2019-04-10 Internet of things architecture for device sharing

Publications (1)

Publication Number Publication Date
WO2020209789A1 true WO2020209789A1 (en) 2020-10-15

Family

ID=72750518

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2019/050201 WO2020209789A1 (en) 2019-04-10 2019-04-10 Internet of things architecture for device sharing

Country Status (4)

Country Link
CN (1) CN113647122A (en)
SG (1) SG11202108912TA (en)
TW (1) TW202046755A (en)
WO (1) WO2020209789A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20220101221A (en) * 2021-01-11 2022-07-19 주식회사엘디전자 Shared electric scooter having low power communication terminal

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3137482A1 (en) * 2022-06-30 2024-01-05 Mma Remote control process for a fleet of self-service vehicles

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014052329A1 (en) * 2012-09-25 2014-04-03 Scoot Networks, Inc. Systems and methods for regulating vehicle access
FR3022672A1 (en) * 2014-06-18 2015-12-25 Kios FLEET MANAGEMENT SYSTEM FOR VEHICLES, IN PARTICULAR ELECTRIC SCOOTERS
US20160311334A1 (en) * 2015-04-22 2016-10-27 Swiftmile, Inc. Light Electric Vehicle Ride Share System and Method
US20160375825A1 (en) * 2015-06-26 2016-12-29 Xiaomi Inc. Method and device for managing self-balancing vehicle
CN106339919A (en) * 2016-08-22 2017-01-18 深圳易马达科技有限公司 Scooter rental system based on internet of things and scooter rental method thereof
WO2017217929A1 (en) * 2016-06-16 2017-12-21 Neuron Mobility Pte Ltd. Docking station for motorised vehicles
CN108566632A (en) * 2018-03-27 2018-09-21 东峡大通(北京)管理咨询有限公司 Processing method, terminal and the machine readable storage medium of motor bicycle

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014052329A1 (en) * 2012-09-25 2014-04-03 Scoot Networks, Inc. Systems and methods for regulating vehicle access
FR3022672A1 (en) * 2014-06-18 2015-12-25 Kios FLEET MANAGEMENT SYSTEM FOR VEHICLES, IN PARTICULAR ELECTRIC SCOOTERS
US20160311334A1 (en) * 2015-04-22 2016-10-27 Swiftmile, Inc. Light Electric Vehicle Ride Share System and Method
US20160375825A1 (en) * 2015-06-26 2016-12-29 Xiaomi Inc. Method and device for managing self-balancing vehicle
WO2017217929A1 (en) * 2016-06-16 2017-12-21 Neuron Mobility Pte Ltd. Docking station for motorised vehicles
CN106339919A (en) * 2016-08-22 2017-01-18 深圳易马达科技有限公司 Scooter rental system based on internet of things and scooter rental method thereof
CN108566632A (en) * 2018-03-27 2018-09-21 东峡大通(北京)管理咨询有限公司 Processing method, terminal and the machine readable storage medium of motor bicycle

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20220101221A (en) * 2021-01-11 2022-07-19 주식회사엘디전자 Shared electric scooter having low power communication terminal
KR102461492B1 (en) * 2021-01-11 2022-11-03 주식회사엘디전자 Shared electric scooter having low power communication terminal

Also Published As

Publication number Publication date
CN113647122A (en) 2021-11-12
TW202046755A (en) 2020-12-16
SG11202108912TA (en) 2021-09-29

Similar Documents

Publication Publication Date Title
CN102089764B (en) A security module having a secondary agent in coordination with a host agent
CN105208132B (en) Intelligent terminal cloud management system
US20200051046A1 (en) Smart broadcasting method and apparatus
CN107111948B (en) Geo-proximity vehicle reminder and access system for security and package exchange efficiency
JP6120473B2 (en) Public transport vehicle driving prediction method, apparatus and device
US9031712B2 (en) Remote management and control of vehicular functions via multiple networks
US11820326B2 (en) Vehicle docking stations heartbeat and security
CN105306560B (en) Distributed terminal implements dynamic management platform
CN105227574B (en) A kind of electric vehicle positioning of compatible multiple terminals access chases after theft system and its method
TW201130352A (en) Dynamic reporting scheme for location based services
CN106060773B (en) Object positioning system, method and device
CN104517154A (en) E-bike reservation and renting system based on Internet of Things
US20170337088A1 (en) Managing application relationships in machine-to-machine systems
WO2020209789A1 (en) Internet of things architecture for device sharing
CN114257960A (en) Bluetooth connection method and device
CN111277622B (en) Vehicle sharing method and device, vehicle, computer equipment and storage medium
KR20160047181A (en) Tracing method for the lost using beacon and mobile terminal
US10543809B1 (en) Systems and methods for identifying unauthorized vehicle use
US11263894B1 (en) 5G mobile device based regional patrolling over highways
CN105447344A (en) Software authorization system and method based on Beidou satellite
US11694546B2 (en) Systems and methods for automatically assigning vehicle identifiers for vehicles
US20160007163A1 (en) Method and system for localization of objets in wireless spontaneous network
Hoque et al. Safari-taxi: Secure, autonomic, fault-resilient, and intelligent taxi hailing system
KR102427658B1 (en) Apparatus for managing bicycles using auxiliary batteries in shared bicycle service and method therefor
US20180205818A1 (en) Mechanism for indicating transport infrastructure compatibility to contactless application installers

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19923746

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19923746

Country of ref document: EP

Kind code of ref document: A1