CN111598370A

CN111598370A - Female safety risk prevention method and system

Info

Publication number: CN111598370A
Application number: CN201910130458.1A
Authority: CN
Inventors: 于留宝; 郎朗; 臧瑞瑞
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2019-02-21
Filing date: 2019-02-21
Publication date: 2020-08-28

Abstract

The embodiment of the application discloses a female safety risk prevention method, which comprises the following steps: acquiring related data of a current order, wherein the related data of the current order at least comprises data associated with the current order and/or state data when the current order is executed; judging whether the sexes of the service provider and the service requester of the current order are the same or not, and performing female safety risk judgment in response to the difference between the sexes of the service provider and the service requester of the current order; determining a female safety risk judgment result of the current order at least based on the related data of the current order; and executing set operation based on the female safety risk judgment result.

Description

Female safety risk prevention method and system

Technical Field

The application relates to the field of network appointment, in particular to a female safety risk prevention method and system.

Background

With the continuous development of the internet economy, the network car booking service is more and more popular at present. In a network car appointment service, security incidents involving female passengers/female drivers are also receiving increasing attention. A vicious event can adversely affect the personal safety of female passengers/drivers. In order to avoid the occurrence of female security incidents as much as possible, it is necessary to determine a method and a system for preventing female security risks, so that the service platform can effectively identify and timely stop the occurrence of female security incidents.

Disclosure of Invention

One of the embodiments of the present application provides a method for preventing female security risk. The method comprises the following steps: acquiring related data of a current order, wherein the related data of the current order at least comprises data associated with the current order and/or state data when the current order is executed; judging whether the sexes of the service provider and the service requester of the current order are the same or not, and performing female safety risk judgment in response to the difference between the sexes of the service provider and the service requester of the current order; determining a female safety risk judgment result of the current order at least based on the related data of the current order; and executing set operation based on the female safety risk judgment result.

In some embodiments, the data associated with the current order includes at least one of: identity information of the service provider, operation behavior information of the service provider on the platform, service time, travel information, identity information of the service requester, and operation behavior information of the service requester on the platform; the status data of the current order execution includes at least one of: location information, environmental data, driving information of the service requester and/or the service provider.

In some embodiments, the determining a female safety risk determination result during execution of the current order based on at least the relevant data of the current order further comprises: and processing the related data of the current order by using a risk judgment model, and determining a female safety risk judgment result.

In some embodiments, the risk assessment model is obtained by: acquiring a historical order; marking the orders of the historical orders, which comprise female safety events, as positive samples, and marking normal orders in the historical orders as negative samples; and training an initial model based on the related data and the marking result of the historical order to obtain the risk judgment model.

In some embodiments, the female security risk determination comprises a risk level of the order; the executing set operation based on the female safety risk determination result further includes: determining the order of the current order in the risk order to be processed based on the risk level of the current order; and determining to execute at least one risk verification operation based on the sequencing result of the current order.

In some embodiments, the risk verification operation includes, but is not limited to, an automated verification operation, or a telephonic interaction verification operation.

In some embodiments, the performing set operations based on the female safety risk determination result further includes: executing at least one risk processing operation based on the judgment result of the risk verification operation; the at least one risk handling operation includes at least one of: notifying the emergency contact; starting monitoring equipment in the vehicle; triggering a reporting mechanism of a user terminal, wherein the user terminal comprises a service provider terminal and/or a service requester terminal; and contacting service providers around the user terminal for assistance.

One of the embodiments of the present application provides a female security risk prevention system. The system comprises: the acquisition module is used for acquiring relevant data of the current order; the related data of the current order at least comprises data related to the current order and/or state data when the current order is executed; the judging module is used for judging whether the sexes of the service provider and the service requester of the current order are the same or not, and responding to the difference between the sexes of the service provider and the service requester of the current order to judge the female safety risk; the system is also used for determining the female safety risk judgment result of the current order at least based on the relevant data of the current order; and the execution module is used for executing set operation based on the female safety risk judgment result.

In some embodiments, the determining module is further configured to: and processing the related data of the current order by using a risk judgment model to determine a female safety risk judgment result.

In some embodiments, the female security risk determination comprises a risk level of the current order; the judging module is further configured to: determining the ranking of the current order in the pending risk order based on the risk level of the current order; and determining to execute at least one risk verification operation based on the sequencing result of the current order.

In some embodiments, the execution module is further to: executing at least one risk handling operation based on the judgment result of the risk verification operation; the at least one risk handling operation includes at least one of: notifying the emergency contact; starting monitoring equipment in the vehicle; triggering a reporting mechanism of a user terminal, wherein the user terminal comprises a service provider terminal and/or a service requester terminal; contacting service providers around the user terminal for assistance.

One of the embodiments of the present application provides a female security risk prevention device, which includes a processor, and is characterized in that the processor is configured to execute a female security risk prevention method.

One of the embodiments of the present application provides a computer-readable storage medium, where the storage medium stores computer instructions, and after a computer reads the computer instructions in the storage medium, the computer executes a method for preventing a female security risk.

Drawings

The present application will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and in these embodiments like numerals are used to indicate like structure, wherein:

FIG. 1 is a schematic diagram of an application scenario of a risk prevention system according to some embodiments of the present application;

FIG. 2 is a diagram illustrating exemplary hardware and/or software components of a mobile device 200 on which terminal 120 may be implemented according to some embodiments of the present application;

FIG. 3 is a block diagram of an exemplary processing device 110 shown in accordance with some embodiments of the present application;

FIG. 4 is an exemplary flow chart of a risk prevention method according to some embodiments of the present application;

FIG. 5 is a block diagram illustrating the architecture of a female risk prevention system according to some embodiments of the present application;

FIG. 6 is an exemplary flow chart of a method for female safety risk prevention according to some embodiments of the present application;

FIG. 7 is an exemplary flow chart of a method for female safety risk determination according to some embodiments of the present application;

FIG. 8 is an exemplary flow chart of a system update method according to some embodiments of the present application.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only examples or embodiments of the application, from which the application can also be applied to other similar scenarios without any inventive effort, as will be clear to a person skilled in the art. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.

It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, other words may be substituted by other expressions if they accomplish the same purpose.

As used in this application and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.

Flow charts are used herein to illustrate operations performed by systems according to embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, the various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or operations may be removed from the processes.

Embodiments of the present application may be applied to different traffic service systems, including but not limited to one or a combination of land, surface, aviation, aerospace, and the like. Such as a human powered vehicle, a vehicle, an automobile (e.g., a small car, a bus, a large transportation vehicle, etc.), rail transportation (e.g., a train, a bullet train, a high-speed rail, a subway, etc.), a boat, an airplane, a hot air balloon, an unmanned vehicle, etc. The application scenarios of the different embodiments of the present application include but are not limited to one or a combination of several of transportation industry, warehouse logistics industry, agricultural operation system, urban public transportation system, commercial operation vehicle, etc. It should be understood that the application scenarios of the system and method of the present application are merely examples or embodiments of the present application, and those skilled in the art will be able to apply the present application to other similar scenarios without inventive effort based on these drawings. Such as other similar tracked vehicles.

FIG. 1 is a schematic diagram of an application scenario of a risk prevention system 100 according to some embodiments of the present application.

As shown in FIG. 1, the risk prevention system 100 may determine the risk of a safety event on the trip and take countermeasures to reduce injury to the user. For example, the risk prevention system 100 may determine a female safety risk on the trip, for example. The risk prevention system 100 may be used in a service platform for the internet or other networks. For example, the risk prevention system 100 may be an online service platform that provides services for transportation. In some embodiments, the risk prevention system 100 may be applied to a network appointment service, such as a taxi call, a express call, a special call, a mini-bus call, a car pool, a bus service, a driver hiring and pick-up service, and the like. In some embodiments, the risk prevention system 100 may also be applied to designated drives, couriers, takeoffs, and the like. In other embodiments, the risk prevention system 100 may be applied to the fields of home services, travel (e.g., tourism) services, education (e.g., offline education) services, and the like. As shown in FIG. 1, the risk prevention system 100 may include a processing device 110, one or more terminals 120, a storage device 130, a network 140, and an information source 150.

In some embodiments, processing device 110 may process data and/or information obtained from terminal 120, storage device 130, and/or information source 150. For example, the processing device 110 may obtain location/trajectory information for the plurality of terminals 120 and/or characteristic information of parties (e.g., drivers and passengers) associated with the trip. Processing device 110 may process the information and/or data obtained as described above to perform one or more functions described herein. For example, the processing device 110 may determine the security risk based on the risk determination rule and/or risk determination model and determine to take corresponding countermeasures, such as alarming and/or providing offline support, according to the determination result. In some embodiments, the processing device 110 may obtain data related to at least one service order; the relevant data of the service order at least comprises the following two types: the service order characteristics, real-time status data during execution of the service order, and a history associated with at least one data in the service order. In some embodiments, the processing device 110 may process the relevant data of the service order based on at least a preset risk determination rule to determine a risk determination result of the service order. In some embodiments, the processing device 110 may perform a risk coping operation on the service order based on the risk determination result. In some embodiments, the processing device 110 may be a stand-alone server or a group of servers. The set of servers may be centralized or distributed (e.g., processing device 110 may be a distributed system). In some embodiments, the processing device 110 may be local or remote. For example, the processing device 110 may access information and/or material stored in the terminal 120, the storage device 130, and/or the information source 150 via the network 140. In some embodiments, the processing device 110 may be directly connected to the terminal 120, the storage device 130, and/or the information source 150 to access information and/or material stored therein. In some embodiments, the processing device 110 may execute on a cloud platform. For example, the cloud platform may include one or any combination of a private cloud, a public cloud, a hybrid cloud, a community cloud, a decentralized cloud, an internal cloud, and the like. In other embodiments, the processing device 110 may be one of the terminals 120 at the same time.

In some embodiments, processing device 110 may include one or more sub-processing devices (e.g., a single-core processor or a multi-core processor). By way of example only, processing device 110 may include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an Application Specific Instruction Processor (ASIP), a Graphics Processing Unit (GPU), a Physical Processing Unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a programmable logic circuit (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computer (RISC), a microprocessor, or the like, or any combination thereof.

In some embodiments, the terminal 120 may be a device with data acquisition, storage, and/or transmission capabilities, and may include any user or terminal that does not directly participate in a service, a service provider terminal, a service requester terminal, and/or a vehicle mounted terminal. The service provider may be a person, tool, or other entity that provides the service. The service requester may be an individual, tool or other entity that needs to obtain or is receiving a service. For example, for a car-order-on-the-net service, the service provider may be a driver, a third-party platform, and the service requester may be a passenger or other person or device (e.g., an internet-of-things device) that receives similar services. In some embodiments, the terminal 120 may be used to collect various types of data, including but not limited to data related to services. For example, the data collected by the terminal 120 may include data related to an order (e.g., order request time, departure/destination point, passenger information, driver information, vehicle information, etc.), data related to vehicle driving conditions (e.g., current speed, current acceleration, attitude of the device, road conditions, etc.), data related to a service trip (e.g., preset trip path, actual travel path, cost, etc.), data related to a service participant (service provider/service requester) (e.g., personal information of the participant, handling information of the terminal 120 by the service provider/service requester, various related data of the terminal device, etc.), and the like or any combination thereof. The collected data may be real-time or various types of historical data such as past usage history of the user, etc. The data may be collected by the terminal 120 through its own sensor, or may be collected by an external sensor, or may be read from a memory of the terminal, or may be read from a storage device 150 through the network 140. In some embodiments, the sensor may include a pointing device, a sound sensor, an image sensor, a temperature and humidity sensor, a position sensor, a pressure sensor, a distance sensor, a velocity sensor, an acceleration sensor, a gravity sensor, a displacement sensor, a moment sensor, a gyroscope, the like, any combination thereof, or the like. Various types of data collected by the terminal 120 may be used to determine a malignancy and/or an anomaly that may occur during subsequent service execution. For example, it may be determined whether there is a stay anomaly at a certain place (including during service execution and/or after completion of service), whether a signal is lost at a certain route section, whether service is ended in advance without reaching a service destination, whether there is a preset route, whether to travel to a remote area, whether to stay a plurality of times in a trip, whether the travel speed is slow, whether there is an offset route section, whether the travel time exceeds a threshold value, and the like, based on trajectory data. For example, it is possible to determine whether or not the vehicle is in danger of driving, such as a collision or a rollover, based on changes in the posture, speed, and/or acceleration of the vehicle. In some embodiments, the terminal 120 may include one or a combination of desktop computer 120-1, laptop computer 120-2, in-vehicle device 120-3, mobile device 120-4, and/or the like. In some embodiments, mobile device 120-4 may include a smart home device, a wearable device, a smart mobile device, an augmented reality device, and the like, or a combination thereof. In some embodiments, the wearable device may include a smart bracelet, smart footwear, smart glasses, smart helmet, smart watch, smart clothing, smart backpack, smart accessory, or the like, or any combination thereof. In some embodiments, the smart mobile device may include a smartphone, a Personal Digital Assistant (PDA), a gaming device, a navigation device, a POS machine, or the like, or a combination thereof. In some embodiments, the in-vehicle device 120-3 may include an on-board computer, an automotive data recorder, an on-board human-computer interaction (HCI) system, a tachograph, an on-board television, and so forth. In some embodiments, in-vehicle device 120-3 may obtain various component data and/or operational data of the vehicle, such as speed, acceleration, direction of travel, component status, vehicle surroundings, and the like. The acquired data may be used to determine whether a driving accident (e.g., a rollover, a crash), a driving malfunction (e.g., an engine or transmission malfunction causing the vehicle to be unable to move), etc. In some embodiments, the terminal 120 may be a device having a positioning technology for locating the position of the terminal 120. In some embodiments, the terminal 120 may transmit the collected data/information to the processing device 110 via the network 140 for subsequent steps. The terminal 120 may also store the collected data/information in its own memory or transmit it to the storage device 130 via the network 140 for storage. The terminal 120 may also receive and/or display notifications related to risk prevention generated by the processing device 110. In some embodiments, multiple terminals may be connected to each other, and various types of data may be collected together and preprocessed by one or more terminals. Storage device 130 may store data and/or instructions. In some embodiments, storage device 130 may store data/information obtained by terminal 120. The storage device 130 may also store historical transportation service data for historical events, such as order data for historical service orders for some events, service participant data, vehicle-related data, and the like, and trip data, and the like. In some embodiments, storage device 130 may store data and/or instructions for execution by, or used by, processing device 110 to perform the exemplary methods described in this application. For example, the storage device 130 may store a risk determination model that may determine whether a transportation service is at risk based on data/information related to the transportation service acquired by the processing device 110. In some embodiments, the storage device 130 may store various types of real-time or historical data of the user terminal, for example, historical records of the user related to historical services, such as historical ratings, and the like. In some embodiments, the storage device 130 may be part of the processing device 110 or the terminal 120. In some embodiments, storage 130 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), and the like, or any combination thereof. Exemplary mass storage may include magnetic disks, optical disks, solid state disks, and the like. Exemplary removable memory may include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Exemplary volatile read-only memory can include Random Access Memory (RAM). Exemplary RAM may include Dynamic RAM (DRAM), double-data-rate synchronous dynamic RAM (DDR SDRAM), Static RAM (SRAM), thyristor RAM (T-RAM), zero-capacitance RAM (Z-RAM), and the like. Exemplary ROMs may include Mask ROM (MROM), Programmable ROM (PROM), Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), compact disk ROM (CD-ROM), digital versatile disk ROM, and the like. In some embodiments, storage device 130 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, an internal cloud, a multi-tiered cloud, and the like, or any combination thereof. For example, some risk judgment algorithms or data in the present invention may be stored on a certain cloud platform, and are updated periodically, and the processing device 110 accesses these algorithms or data through a network, so as to implement unification and interaction of the algorithms or data of the whole platform. In particular, some historical data may be uniformly stored on one cloud platform of the platform so that a plurality of processing devices 110 or terminals 120 can access or update the data, thereby ensuring real-time performance and cross-platform use of the data. For example, the terminal 120 may publish its speed and positioning information to a certain cloud platform at any time, and the system may determine whether an abnormal condition occurs according to the feedback of multiple terminals 120.

In some embodiments, the storage device 130 may be connected to the network 140 to communicate with one or more components (e.g., the processing device 110, the terminal 120, the information source 150) in the risk prevention system 100. One or more components in the risk prevention system 100 may access data or instructions stored in the storage device 130 through the network 140. In some embodiments, the storage device 130 may be directly connected or in communication with one or more components (e.g., the processing device 110, the terminal 120, the information source 150) in the risk prevention system 100. In some embodiments, the storage device 130 may be part of the processing device 110.

Network 140 may facilitate the exchange of information and/or data. In some embodiments, one or more components in the risk containment system 100 (e.g., the processing device 110, the terminal 120, the storage device 130, and the information source 150) may send and/or receive information and/or data to/from other components in the risk prevention system 100 via the network 140. For example, the processing device 110 may obtain data/information related to a transportation service from the terminal 120 and/or the information source 150 via the network 140. For another example, the terminal 120 may obtain the determination model for determining whether the transportation service is at risk from the processing device 110 or the storage device 130 through the network 140. The obtained decision model may be implemented in application software of the terminal 120. After acquiring the data/information related to the transportation service, the terminal 120 may determine whether the transportation service has a risk and perform a risk handling operation, such as initiating a telephone alarm. In some embodiments, the network 140 may be any form or combination of wired or wireless network. By way of example only, network 140 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the Internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Public Switched Telephone Network (PSTN), a Bluetooth network, a ZigBee network, a Near Field Communication (NFC) network, a Global System for Mobile communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Time Division Multiple Access (TDMA) network, a General Packet Radio Service (GPRS) network, an enhanced data rates for GSM evolution (EDGE) network, a Wideband Code Division Multiple Access (WCDMA) network, a High Speed Downlink Packet Access (HSDPA) network, a Long Term Evolution (LTE) network, a User Datagram Protocol (UDP) network, a Transmission control protocol/Internet protocol (TCP/IP) network, Short Message Service (SMS) networks, Wireless Application Protocol (WAP) networks, ultra-wideband (UWB) networks, mobile communication (1G, 2G, 3G, 4G, 5G) networks, Wi-Fi, Li-Fi, narrowband Internet of things (NB-IoT), and the like, or any combination thereof. In some embodiments, the risk prevention system 100 may include one or more network access points. For example, risk prevention system 110 may include wired or wireless network access points, such as base stations and/or wireless access points 140-1, 140-2, through which one or more components of risk prevention system 100 may connect to network 140 to exchange data and/or information.

The information source 150 may be used to provide a source of information for the risk prevention system 100. In some embodiments, the information source 150 may be used to provide the risk prevention system 100 with information related to transportation services, such as weather conditions, traffic information, geographic information, legal information, news events, life information, life guide information, and the like. In some embodiments, the information source 150 may also be other third party platforms that may provide credit records, such as credit records, for the service requester and/or the service provider. In some embodiments, the information source 150 may be used to provide risk prevention system 100 with information related to risk prevention, such as driving safety tips, personal safety tips, property safety tips, and the like. The information source 150 may be implemented in a single central server, multiple servers connected by communication links, or multiple personal devices. When the information source 150 is implemented in a plurality of personal devices, the personal devices may generate content (e.g., referred to as "user-generated content"), for example, by uploading text, voice, images, and video to a cloud server. The information source may be generated by a plurality of personal devices and a cloud server. The storage device 130, the processing device 110 and the terminal 120 may also be sources of information at the same time. For example, the speed and location information fed back by the terminal 120 in real time can be used as an information source to provide traffic condition information for other devices to obtain.

Fig. 2 is a diagram illustrating exemplary hardware and/or software components of a mobile device 200 on which terminal 120 may be implemented according to some embodiments of the present application.

As shown in fig. 2, mobile device 200 may include a communication unit 210, a display unit 220, a Graphics Processing Unit (GPU)230, a Central Processing Unit (CPU)240, input/output 250, memory 260, memory 270, and sensors 280. In some embodiments, any other suitable component, including but not limited to a system bus or a controller (not shown), may also be included in mobile device 200.

In some embodiments, the operating system 262 (e.g., IOS) is moved^TM、Android^TM、 Windows Phone^TMEtc.) and one or more application programs 264 may be loaded from storage 290 into memory 260 for execution by CPU 240. The application 264 may include a browser or any other suitable mobile application for sending data/information associated with transportation services and receiving and presenting processing or other related information from the risk prevention system 100. For example, application 264 may be an online taxi appointment travel platform (e.g., a drip line)^TM) The user (e.g., service requester) may request the transportation service through the application 264 and send the request information to the backend server. User interaction with the information flow may be accomplished via the input/output 250 and provided to the processing device 110 and/or other components of the risk prevention system 100 via the network 140.

In some embodiments, mobile device 200 may also include a plurality of sensors 280. The sensors 280 may acquire data related to service participants (e.g., drivers/passengers), vehicles, and/or travel, etc. In some embodiments, the sensor may include a sound sensor, an image sensor, a temperature and humidity sensor, a position sensor, a pressure sensor, a distance sensor, a velocity sensor, an acceleration sensor, a gravity sensor, a displacement sensor, a moment sensor, a gyroscope, or the like, or any combination thereof. In some embodiments, the data acquired by the sensors may be used to subsequently determine whether a risk occurs and/or what risk occurs. For example, the sound sensor and the image sensor may collect conversations between the service participants and real-time scenes in the vehicle for determining whether a driver conflict or a property/personal safety event occurs, such as a physical conflict, drunk driving, robbery, sexual assault, sexual disturbance, etc. For another example, the position sensor and the displacement sensor may collect real-time position of the vehicle and/or travel track data of the vehicle, so as to determine whether a travel abnormality occurs, such as an abnormal stop, a travel deviation, an abnormal travel time, and the like. Also for example, the speed sensor, the acceleration sensor, and the gyroscope may acquire a real-time speed, a real-time acceleration, a deflection amount, a deflection frequency, and the like of the vehicle, so as to determine whether a driving safety accident, such as a collision, a rollover, and the like, occurs in the vehicle.

In some embodiments, the mobile device 200 may also communicate with the vehicle, for example, bluetooth communication, to acquire data collected by vehicle-mounted sensors installed inside or outside the vehicle, such as current state data and driving data of the vehicle, and combine the data acquired by the own sensor and the data acquired by the vehicle-mounted sensors for subsequent risk determination.

In some embodiments, the mobile device 200 may send the acquired data/information, including data acquired by its own sensors and data acquired by in-vehicle sensors, over the network 140 to the processing device 110 of the risk prevention system 100 for risk determination and disposal. In some embodiments, mobile device 200 may make the risk determination and treatment directly. For example, the application 264 may have a code or a module for risk assessment built therein, and may directly perform risk assessment and treatment. In some embodiments, the processing device 110 and/or the mobile device 200 of the risk prevention system 100 may also generate a security notification instruction according to the risk determination and/or treatment result. The mobile device 200 may remind the user of the current security status by receiving and executing the security notification command. For example, the mobile device 200 may implement the security notification by way of voice (e.g., through a speaker), vibration (e.g., through a vibrator), text (e.g., through a text message or a social application), flashing lights (e.g., through a flashing light or the display unit 220), or the like, or a combination thereof, for the purpose of alerting the user.

In some embodiments, a user of mobile device 200, e.g., a driver and/or passenger, may perform the risk determination process on their own. In particular, the driver and/or passenger may actively report the risk through the application 264 in the mobile device 200. For example, performing a particular operation on the mobile device 200, such as shaking or throwing, may initiate an alarm procedure. As another example, the interface of the application 264 may include a quick entry (e.g., alarm button, help button) that communicates directly with the back-end security platform, and the user may alert the police by clicking on the alarm button when determining that the user is in a dangerous situation. After alerting, the application 264 may also send the current location and travel information of the alerting user to the police to assist in rescue.

To implement the various modules, units, and functions thereof described herein, a computer hardware platform may be used as the hardware platform for one or more of the components described herein. A computer with user interface components may be used to implement a Personal Computer (PC) or any other type of workstation or terminal device. A computer can also function as a system if the computer is appropriately programmed.

Fig. 3 is a block diagram of an exemplary processing device 110 shown in accordance with some embodiments of the present application.

The processing device 110 may obtain data related to the transportation service for processing to determine a risk determination for the transportation service, and further determine a risk response method based on the risk determination. In some embodiments, the processing device 110 may further update the methods, such as rules, algorithms, models, and the like, used in the risk determination and handling process according to the risk confirmation and handling results, so as to achieve the optimal risk prevention and handling effects. As shown in fig. 3, processing device 110 may include a data acquisition module 310, a risk determination module 320, a risk management module 330, and an update module 340.

The data acquisition module 310 may be used to acquire data.

In some embodiments, the data acquisition module 310 may acquire data related to at least one service order. The service order may be a transportation service order, such as a freight transportation order, a travel service order, and/or the like, that is requested, executed, and/or completed at the current time. The data related to the service order may comprise order characteristics of the service order, status data during execution of the order, and a history related to at least one data of the service order. The order characteristics may be information directly documented in the service order including, but not limited to, identity information of the service provider, identification information of the vehicle associated with the service order, service time, trip origin, trip destination, trip path, identity information of the service requester, and the like, or any combination thereof. The status data during order execution may refer to status data of equipment related to the order during service order execution and/or environmental data of the user or the vehicle surroundings during order execution, including but not limited to location data of the terminal related to the service order, status data of the vehicle, environmental data of the vehicle interior and environmental data of the vehicle surroundings, and the like, or any combination thereof. The history record related to at least one data in the service order may be understood as a history record corresponding to a certain data in the current service order, such as a record of execution history service orders of the service provider, a credit record of the service provider, a record of participation history service orders of the service requester, a credit record of the service requester, and the like, or any combination thereof. In some embodiments, the data acquisition module 310 may communicate with the terminal 120, the storage device 130, and/or the information source 150 via the network 140 to acquire the data. After acquisition, the data acquisition module 310 may transmit the data to the risk determination module 320 for various types of risk determinations.

In some embodiments, the data acquisition module 310 may also acquire historical order data, which may include traffic service related data for which a risk event occurred. The historical data may be similar to the real-time data described above, while also including the specific types of risk events that occur for a particular transportation service. The risk event types may include robbery, personal security events, service cancellation exceptions, stay in journey exceptions, stay after journey exceptions, loss exceptions, miss exceptions, journey exceptions, driving hazards, and the like, or any combination thereof. In some embodiments, the historical order data may be used as training data to train a risk decision model or to determine risk decision rules. The resulting risk decision model or risk decision rule may be used to decide on the service order data to determine if there is risk. In some embodiments, the historical order data may be stored in the storage device 130, and the data acquisition module 310 may communicate with the storage device 130 over the network 140 to read the historical order data stored therein.

The risk determination module 320 may make a risk determination based on the acquired data.

In some embodiments, the risk determination module 320 may use the determination rules to make a risk determination for the current state of the service order. In some embodiments, the decision rule may be a condition and/or threshold set based on the historical order data and/or experience. The threshold setting of the decision rule may be determined based on data statistics, and an intermediate result obtained in a training process of the risk decision model may also be used as the decision threshold. For example, the determination rule may be set to determine the risk of robbery and/or the risk of female safety events based on preset conditions such as whether the time of departure is late at night, whether the departure point is remote, whether the driver and/or passenger have a relevant history, whether the number of occurrences of sensitive words in the sensed data exceeds a preset value, and the like. For another example, it may be determined whether the vehicle has a driving risk such as a collision or a rollover based on sensor data (e.g., acceleration due to gravity) exceeding a preset threshold.

In some embodiments, the risk assessment module 320 may use a risk assessment model to make a risk assessment of the current state of the transportation service. The risk assessment model may be a machine learning model, such as a decision tree, trained via the acquired historical order data. For example, the model may be trained using data associated with the transportation service in the historical order data as input, and the type of risk that the transportation service is occurring as the correct criteria (Ground Truth). In some embodiments, the risk determination model may be a single overall determination model for determining whether one or more types of risks exist, including robbery, personal safety incident, cancellation exception, stop-in-journey exception, stop-after-journey exception, loss exception, miss-delivery exception, journey exception, driving hazard, and the like, or any combination thereof. In some embodiments, the risk decision model may include multiple models that are each specific to a particular risk event. For example, for the determination of the robbery risk, there may be a special robbery determination model to determine the current state of the transportation service. Similarly, other risk determinations may be performed with a specific corresponding model. The risk determination module 320 may utilize a combination of models to determine one or more risks. The combination mode of the models can be determined according to actual requirements. For example, in areas with poor security (e.g., urban and rural junctions), the decision may be made with emphasis on robbery and personal safety incidents. In a region with dense pedestrian flows such as a city center, the determination of travel abnormality can be emphasized.

In some embodiments, the determination result of the risk determination module 320 may include the presence or absence of risk and a quantitative representation of risk. For example only, the determination may be risk-free. Alternatively, the determination result may be the existence risk and the type of risk, a value representing the risk level, the risk probability, etc., for example, the determination result is (at risk, robbery-5 level) or (at risk, robbery-56%, abnormal stay-87%). In some embodiments, the risk assessment module 320 may aggregate the overall risk level and/or probability and output a assessment corresponding to the aggregate risk assessment, e.g., the assessment is (at risk, 74%). It should be noted that the form of the determination result described above is for illustrative purposes only, and the present application does not limit the form of the determination result.

The risk coping module 330 may perform a risk coping operation based on the risk determination result.

In some embodiments, risk management module 330 may further include a risk ranking unit 332, a risk confirmation unit 334, a risk handling unit 336, a continuous monitoring unit 338. The risk ranking unit 332 may rank the risk determination results based on a ranking rule. The ranking rules may be ranked according to one or more risk parameters (e.g., characteristic values such as dwell time in the risk of dwell anomaly) in different risks. The sorting rule may also sort according to the size of the risk probability and/or the rank in the decision result. The sorting rule may also be setting a sorting result threshold (e.g., a level threshold, a probability threshold, etc.), and sorting the risk determination results that meet different thresholds respectively. The ranking rule may also be based on the magnitude of some operation result (e.g., a weighted average) of a plurality of risk parameters. In some embodiments, the risk ranking unit 332 may rank the risk determination results using a ranking model. The ranking model may be a mathematical model, and the risk ranking results may be derived by formula calculation (e.g., weight calculation) based on the eigenvalues in the different risk categories and/or the eigenvalues of all risks, respectively. The ranking model may also be a machine learning model, which may be obtained after training based on feature data of the trigger risk. The risk confirmation unit 332 may input the risk determination result corresponding to the transportation service order into the trained risk ranking model to determine the ranking result. In some embodiments, the ranking results may represent a risk level ranking for the service order. In some embodiments, the ranking results may represent a risk probability level ranking of the service orders. In some embodiments, the ranking results determine subsequent countermeasures.

In some embodiments, risk ranking unit 332 may rank the different risks separately. For example, all orders with the same risk are sorted, and sorting results with different risks are obtained respectively. In some embodiments, the risk ranking unit 332 may also rank all risks comprehensively. For example, weights may be set for different risks, and orders with different risks may be comprehensively ranked according to the weights.

Risk confirmation unit 334 may perform risk confirmation. In some embodiments, risk validation unit 334 may validate the risk based on the ranking results of risk ranking unit 332. For example, a preset number of orders may be selected among the higher risk ranked orders for risk confirmation. In some embodiments, the risk confirmation unit 334 may confirm the risk directly based on the determination result of the risk determination module 320. For example, risk confirmation is performed for orders whose risk determination module 320 determines that the results (e.g., risk level, risk probability, etc.) are within a preset range. In some embodiments, risk confirmation element 334 may risk confirm all service orders directly.

In some embodiments, the risk confirmation operation may include risk confirmation by interacting with user information, risk confirmation by a worker going to the field, risk confirmation by obtaining in-vehicle audio or image information, risk confirmation based on traffic system broadcast information confirmation, and the like, or any combination thereof. The risk confirmation unit 334 may perform risk confirmation manually. For potentially risky orders, the risk prevention system 100 may present information related to the risk order and further determine the related risk information by manual means (e.g., manual customer service). In some embodiments, risk confirmation unit 334 may perform risk confirmation in an automated manner. For potentially risky orders, the automatic risk confirmation unit 334 may confirm the risk by means including Interactive Voice Response (IVR) outbound call, terminal screen pop, text application, Voice inquiry or Voice monitoring of the driver and/or passenger in the vehicle, in-vehicle Voice reporting, etc. In some embodiments, risk confirmation element 334 may also perform risk confirmation by way of human interaction with automation. For potentially risky orders, the risk confirmation unit 334 may perform risk confirmation by way of telephonic interaction.

Risk handling unit 336 may perform risk handling operations. The risk handling operations may include notifying emergency contacts, initiating driver-side and/or passenger-side data reporting, special person follow-up alerts, and the like, or any combination thereof. In some embodiments, risk handling unit 336 may determine the risk handling operation based directly on the risk determination. For example, risk handling unit 336 may perform risk handling on high risk orders and take different actions depending on the risk probability. For example, according to the algorithm, when the risk probability exceeds 20%, some action is taken, such as sending a prompt message to the user terminal to alert the user (driver or passenger) that there is some risk, requiring the user's attention. When the risk probability is higher (e.g. 90%), the termination of the service may be directly required. In some embodiments, risk handling unit 336 may determine a risk handling operation based on the system multiple risk ranking results. For example, risk handling unit 336 may perform risk handling, such as person to hand, on orders with a risk ranking order of the top 30%. In some embodiments, risk handling unit 336 may also determine a risk handling operation based on the risk confirmation result. For example, the risk handling unit 336 may perform a risk handling operation on an order that is confirmed to be at risk. The criteria and thresholds for system risk handling may be dynamically adjusted in accordance with real-time conditions and historical data and feedback in conjunction with the update unit.

In some embodiments, risk handling unit 336 may handle risks by methods of risk study. The risk handling unit 336 may obtain the service orders and the related service order data that satisfy the risk study condition, obtain the risk determination result of the service orders and the risk information related to various aspects of the service orders, and determine whether a risk event occurs in the service orders based on the risk determination result and the risk information.

In some embodiments, risk handling unit 336 may handle risks by means of risk rescues. The risk handling unit 336 may determine whether the service order satisfies the risk rescue condition based on the risk determination result, generate rescue information for satisfying the risk rescue condition, and transmit the rescue information. For example, for an order determined to be at risk, its risk information (e.g., risk type, risk level, etc.) may be obtained, and for an order whose risk level meets a preset threshold, rescue information may be generated to inform a surrounding driver to go for assistance or view.

The continuous monitoring unit 338 may perform continuous monitoring of the service orders. The continuous monitoring may be performed for service orders determined to be risk-free in the risk determination, or for partial service orders at the end of the risk ranking, or for service orders that are risk-free after risk confirmation. In some embodiments, the continuous monitoring unit 338 may determine the terminal associated with the service order to be continuously monitored based on information about the service order. The terminal may be a service provider terminal, a service requester terminal, a vehicle-mounted terminal, etc. The continuous monitoring unit 338 may obtain text, audio and/or image data reflecting the service order execution live through the terminal. Data acquisition may be achieved through various sensors installed on the terminal. For example, audio data may be acquired by a sound sensor (e.g., a microphone) and video data may be acquired by an image sensor (e.g., a camera). The acquired data may be used for risk determination and handling at a next time, e.g., after 10 s.

The update module 340 may update rules and/or models based on the risk handling operation results. The updated rules may include risk decision rules, risk ranking rules, and the like. The updated model may include a risk decision model, a risk ranking model, and the like. In some embodiments, the update module 340 may compare the risk confirmation result and/or the risk treatment result with the risk determination result/risk ranking result to obtain the difference therebetween. And updating a risk parameter and/or a risk parameter value in the decision/ranking rule according to the difference. In some embodiments, the update module 340 may retrain the risk assessment model as new sample data to update the parameters in the model for orders determined to have a risk event in the risk confirmation operation and/or the risk treatment operation. Meanwhile, the updating module 340 may retrain the risk ranking model according to the feature data of each order of the actual ranking result obtained by risk confirmation or risk response. In some embodiments, the updates to the rules and models may be made at predetermined intervals, such as a day, a week, a month, a quarter, and so forth. In some embodiments, the update module 340 may force the system to update in an active push manner.

It should be understood that the system and its modules shown in FIG. 3 may be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may then be stored in a memory for execution by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, on a carrier medium such as a diskette, CD-or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules of the present application may be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, for example, or by a combination of the above hardware circuits and software (e.g., firmware).

It should be noted that the above description is merely for convenience and should not be taken as limiting the scope of the present application. It will be understood by those skilled in the art that, having the benefit of the teachings of this system, various modifications and changes in form and detail may be made to the field of application for which the method and system described above may be practiced without departing from this teachings.

FIG. 4 is an exemplary flow diagram of a risk prevention method 400 according to some embodiments of the present application.

In some embodiments, one or more steps of method 400 may be implemented in system 100 shown in FIG. 1. For example, one or more steps in method 400 may be stored as instructions in storage device 130 and/or memory 270 and invoked and/or executed by processing device 110.

At step 410, data associated with at least one service order is obtained. Step 410 may be performed by data acquisition module 310.

In some embodiments, the service order may be a transportation service order, such as a cargo transportation order, a travel service order, and/or the like, that is requested, executed, and/or completed at the present time. The data related to the service order may comprise service order characteristics of the service order, real-time status data during execution of the service order, and a history associated with at least one data of the service order. In some embodiments, the service order characteristics further may include identity information of the service provider, identification information of a vehicle associated with the service order, a time associated with the service, a starting point of the service, a destination of the service, a path of the service, identity information of the service requester, and an estimated cost of the service. The service provider information may include age, gender, facial portrayal, contact, educational level, identification number, driver's license number, etc. The identification information of the vehicle associated with the service order may include a license plate number, a vehicle type, a vehicle brand, a vehicle body color, a vehicle age, a load capacity, and the like. The service related time may include a service order request time and/or a service order execution time. The service order request time may be a time when the service requester makes an order request, and the service order execution time may be a time when the service provider starts executing a service order. The identity information of the service requester may include age, gender, facial portrayal, contact details, education level, identity card number, etc. The order characteristics can also include estimated order completion time, estimated service cost and the like. In some embodiments, the real-time status data during order execution further may include real-time status data of an external environment during execution of the service order, positioning data associated with the service order, status data of a vehicle associated with the service order, and environmental data of an interior of the vehicle. The real-time status data of the external environment in the service order execution process may include real-time traffic conditions, traffic flow, road types, road event information, current location and location characteristics, and the like. The status data during the order execution may further include the operation content of the terminal by the user of the terminal (e.g., the service requester and/or the service provider) with respect to the terminal, and the like, and the location data related to the service order may include the location position, the mobile path, and the like of the terminal (e.g., the terminal device used by the service provider/service requester) related to the service participant. The status data related to the service order may include power level of the terminal, communication signal strength, sensor operating status, running status of an application on the terminal, and the like. The status data of the vehicle related to the service order may include a vehicle position, a vehicle speed, a vehicle acceleration, a vehicle posture, a driving track, a motion status (e.g., whether the vehicle is parked or not), and the like. The vehicle interior environment data may include in-vehicle audio data, in-vehicle image data, and the like. In some embodiments, the history associated with the at least one data in the service order further can include a record of other service orders of the service provider, a credit investigation record of the service provider, a record of other service orders of the service requester, a credit investigation record of the service requester, identification information of vehicles of other service orders of the service provider, service-related times of other service orders of the service provider, service origination points of other service orders of the service provider, service destinations of other service orders of the service provider, service paths of other service orders of the service provider, identification information of vehicles of other service orders of the service requester, service-related times of other service orders of the service requester, service origination points of other service orders of the service requester, service destinations of other service orders of the service requester, service delivery points of other service orders of the service requester, identification information of vehicles of other service orders of the service requester, service-related times, One or more of a service path of the service requester other service orders, a cost of the service requester other service orders, and a payment record of the service requester other service orders, among others. The records of the service provider's other service orders may include accumulated service completion times, accumulated service cancellation times, complaint times, banned times, reputation scores, rating levels, historical rating content, and the like. The records of other service orders of the service requester may include accumulated service request times, accumulated service cancellation times, accumulated service completion times, service fee payment conditions, credit score, rating level, historical rating content, and the like. The credit investigation records of the service provider/service requester may include credit records relating to debits, credit card consumptions, and the like. In some embodiments, the data acquisition module 210 may acquire the service order data by communicating with the terminal 120, the storage device 130, and/or the information source 150. For example, the terminal 120 may acquire sensing data and operation contents of the terminal 120 by the user in real time through various sensors mounted thereon. The data acquisition module 410 may perform data acquisition after communicating with the terminal 120. For another example, the data acquisition module 410 may access to read user characteristic data stored on the terminal 120 or the storage device 130. Also for example, the data acquisition module 410 may communicate with the information source 150 to acquire external association data.

It should be noted that the service order data is acquired for a particular point in time. The data acquisition module 410 may continuously acquire real-time data associated therewith for the same transportation service order, and the acquired data may be different at different points in time. Meanwhile, the data acquisition module 410 may transmit the acquired data of the transportation service order to other modules of the processing device 110, such as the risk determination module 220, in real time to perform a risk determination operation for risk monitoring of all different phases of the order.

Step 420, processing the relevant data of the service order, and making a risk judgment on the service order. Step 420 may be performed by risk determination module 320.

In some embodiments, the risk determination may be a determination of whether the service order has a malignancy and/or anomaly occurring at the current time. The malignancy and/or exception condition may include a robbery, a personal safety event, an order cancellation exception, a stop-in-flight exception, a stop-after-travel exception, a lost-location exception, a not-delivered exception, a travel exception, a driving hazard, or the like, or any combination thereof. In some embodiments, the risk determination module 320 may make a risk determination for the service order based on a determination rule. The decision rule may be a condition and/or threshold set based on historical order data and/or experience. The historical order data may include order data for historical transportation services in which a malignancy and/or abnormal condition occurred. The historical order data categories may be the same or similar to the service order data described above, and may also include specific types of adverse events and/or anomalies that occur with respect to a transportation service order. In some embodiments, through statistical analysis of the historical order data, decision rules for a particular malignancy and/or abnormal situation may be determined. For example, the historical order data of the robbery event is analyzed systematically, so that the characteristics of low evaluation of service participants (such as passengers), late night order issuing time, remote order starting point position and the like can be obtained. Then, for the determination of the robbery malignancy, a determination rule such as an evaluation threshold, an issue time threshold, a start point position range threshold, etc. may be set. In some embodiments, the threshold setting of the decision rule may be determined from data statistics. Still referring to the above example, assume that through statistical analysis, historical service orders for a robbery malignancy occurred, with the order-issuing time centered at 1 point in the morning. The invoice time threshold may be set to 1 am. The risk determination module 320 may compare the obtained corresponding data of the service order with the determination rule and determine orders exceeding a threshold as risk orders. In some embodiments, there may be one or more decision rules for each type of malignancy or abnormality. When the risk determination module 320 performs the determination using the rule, the determination may be performed using a single rule, or may be performed using a combination of a plurality of rules, or may be performed using all the rules, which is not specifically limited in the present application.

In some embodiments, the risk determination module 320 may make a risk determination for the service order based on a risk determination model. The risk determination model may be a Machine learning model, including but not limited to a Classification and Logistic Regression (Logistic Regression) model, a K-Nearest Neighbor algorithm (K-Nearest Neighbor, kNN) model, a Naive Bayes (NB) model, a Support Vector Machine (SVM), a Decision Tree (Decision Tree, DT) model, a Random Forest (RF) model, a Regression Tree (Classification and Regression Tree, CART) model, a Gradient Boosting Decision Tree (Gradient Boosting Decision Tree, DT) model, an xgboost (extra Gradient), a light Gradient Boosting Machine (light Gradient Boosting Machine, lighting Machine, Gradient Boosting Machine (Boosting Machine, light Gradient), a Gradient Boosting Machine (light Gradient), a light Gradient Boosting network, and an Artificial Neural network (Artificial Neural network, and Artificial Neural network). The risk assessment model may be trained from data associated with the historical service order. For example only, the model may be trained with relevant data of historical service orders as input, and categories of corresponding specific malignancy or abnormal conditions as the correct criteria (Ground Truth). While the model parameters may be adjusted back according to the difference between the predicted output of the model (e.g., the predicted risk category) and the correct criteria. When a predetermined condition is satisfied, for example, the number of training samples reaches a predetermined number, the predicted accuracy of the model is greater than a predetermined accuracy threshold, or the value of the Loss Function (Loss Function) is less than a predetermined value, the training process is stopped, and the trained model is designated as the risk determination model. In some embodiments, the risk decision model may be a decision model for all types of malignancy or abnormal situations. The risk assessment module 320 may process the service order using the risk assessment model to determine if one or more types of malignancy or anomaly are present. In some embodiments, there may be one risk determination model for each type of malignancy or abnormality. For example, for the judgment of the robbery risk, a special robbery judgment model can be used for judging. Similarly, other risk determinations may be performed with a specific corresponding model. The risk determination module 320 may utilize a combination of models to determine one or more risks. The combination mode of the models can be determined according to actual requirements. For example, in areas with poor security (e.g., urban and rural junctions), the decision may be made with emphasis on robbery and personal safety incidents. In a region with dense traffic flows such as a city center, the determination of the travel abnormality can be emphasized. In some embodiments, the risk determination may be a determination of whether the service order has a malignancy and/or anomaly occurring at the current time. The malignancy and/or exception condition may include a robbery, a personal safety event, an order cancellation exception, a stop-in-flight exception, a stop-after-travel exception, a lost-location exception, a not-delivered exception, a travel exception, a driving hazard, or the like, or any combination thereof. In some embodiments, the risk determination module 320 may use the determination rules to make a risk determination for the service order. The decision rule may be a risk parameter threshold. The risk assessment module 320 may determine different risk parameters for different malignancy and/or abnormal situations. For a robbery event and/or a female security event, decision rules may be determined based on driver/passenger characteristics, order characteristics, sensed data, etc. to decide on risk. For example, the determination rule may be set based on whether the departure time is late at night, whether the departure point is remote, the age and sex of the driver and/or the passenger, whether the driver and/or the passenger have a history of relevance, whether the number of occurrences of sensitive words in the sensed data exceeds a preset value, and the like. For an abnormal cancellation event, a decision rule may be set based on whether the driver does not continue or no longer take the order for a long time after canceling the order in the trip (e.g., at the trip stage where billing begins and the destination is not reached), driver and/or passenger behavior data (e.g., location, path, etc.) after the order is canceled. For the stay abnormality during the journey, the risk determination may be performed by setting a determination rule based on the stay duration, the stay environment (the time period, the road condition, the traffic flow, the road information, the POI information, the surrounding environment, and the like), the stay frequency of the stay point (for example, there is a plurality of people staying at the current stay point), the stay point billing density, and the like. The post-trip stay exception can be classified into a post-destination exception and a non-post-destination exception. For the stop abnormality after the destination is ended, the determination rule may be set based on whether the driver continues to pick up the order for a long time while staying near the destination, the driver and/or passenger position stays at the end of the journey point, the stop environment (time zone, road condition, traffic flow, road information, POI information, surrounding environment, etc.), the stop frequency of the stop point (for example, there are many people currently stopping at the stop point), the stop point issuance density, and the like. For a post-end stop exception where the non-destination (e.g., distance from the end of the order exceeds a threshold), decision rules may be set based on whether the driver continues to pick up the order, driver and/or passenger position stops at the end of travel location, end location information, travel time, estimated time, etc. For the position loss abnormality, a determination rule may be set based on a position loss duration, a position loss environment (e.g., a lost point position, a path of a lost point, whether it is a high-frequency lost point), a driver situation (a mobile phone power amount, whether it is not a prompt order), and the like. For a non-delivery anomaly, decision rules may be set based on whether the order ending point is at the destination, ending point information (e.g., POI information, mileage, departure point traffic, distance to destination location, etc.), driver and/or passenger behavior, whether the driver continues to pick up orders, travel time, estimated time, etc. For the travel abnormality risk, a determination rule may be set based on a route deviation situation (e.g., deviation time, deviation distance), whether to travel to a remote area, the number of stops in the travel, the travel speed, the travel time, and the like, in combination with one or more of the above-described abnormality situations. For the driving risk, it may be determined whether the vehicle has a driving risk such as a collision, a rollover, or the like, based on the sensor data (e.g., speed, acceleration, or the like) exceeding a preset threshold value setting determination rule.

In some embodiments, the risk determination module 320 uses a risk determination model to make a risk determination for the service order. The risk determination model may be a Machine learning model, including but not limited to a Classification and logistic regression (logistic regression) model, a K-Nearest Neighbor algorithm (K-Nearest Neighbor, kNN) model, a naive bayes (NaiveBayes, NB) model, a Support Vector Machine (SVM), a Decision Tree (Decision Tree, DT) model, a Random Forest (RF) model, a regression Tree (Classification and regression trees, CART) model, a Gradient Boosting Decision Tree (GBDT) model, an xgboost (xtorement Gradient), a Light Gradient Boosting Machine (Light Gradient Boosting Machine, lightweighted), a Gradient Boosting Machine (Vector, Boosting), a Gradient Boosting Machine (Light, library), a Light Gradient Boosting Machine (Light neural network, artificial neural network, and artificial neural network (artificial neural network, etc.).

In some embodiments, the risk decision model may be a decision model for all types of malignancy or abnormal situations. The risk assessment module 320 may process the service order using the risk assessment model to determine if one or more types of malignancy or anomaly are present. For example, a risk assessment model may have a classification function that processes and/or assesses input data in a classification manner to assess different types of risk and their associated risk information (e.g., risk level, risk probability, etc.). In some embodiments, there may be one risk decision model for each type of malignancy or anomaly. For example, for the judgment of the robbery risk, a special robbery judgment model can be used for judging. Similarly, other risk determinations may be performed with a specific corresponding model.

In some embodiments, the risk assessment model may be trained from the historical order data. As an example only, taking training a decision tree model for determining a robbery event as an example, the model construction and training process is briefly described. For the analysis result of the historical orders at the time of robbery, a plurality of characteristics of the trigger event, such as age, gender, the time of the order issuance, the starting and ending point position, the historical risk record and the like, can be determined. After the root nodes of the decision tree are constructed, an optimal feature may be selected to segment the training data into a plurality of subsets. And continuously selecting new optimal characteristics for each subset, and continuously segmenting until a plurality of leaf nodes with definite classifications are obtained. For example, a feature of the single-issue time (e.g., 1 am) may be selected to segment the training data at the root node. Training data with an order time earlier than 1 point in the morning will be classified into one category, and training data with an order time later than one point in the morning will be classified into another category. Segmentation may then continue by continuing to select a starting and ending point location (e.g., ending point located near municipality) until all training data has been correctly classified. The training is thus complete.

In some embodiments, the determination of the risk determination for the service order may include the presence or absence of risk and a quantitative representation of risk. For example only, the determination may be risk-free. Or, the determination result may be the existence of risk and a value representing the risk level, risk probability, etc., such as (risk, robbery-5 level) or (risk, robbery-56%, abnormal stay-87%). In some embodiments, the risk assessment module 320 may aggregate the ranking and/or probability of the overall risk and output an assessment corresponding to the aggregate risk assessment, e.g., the assessment is (at risk, 74%). It should be noted that the form of the determination result described above is for illustrative purposes only, and the present application does not limit the form of the determination result.

In some embodiments, the intermediate results generated during the training of the risk decision model may be used as decision thresholds for the decision rules. For example, taking training a decision tree model for determining a robbery event as an example, the dispatching time selected when the root node is forked is taken as an optimal feature for forking. The bifurcation threshold of the time node of issuance can be used as a decision threshold of the decision model when the bifurcation threshold reaches a stable value (i.e., the data of the root node can be divided into two correct classes) after repeated correction of multiple training.

Based on the risk determination result, a risk coping operation is performed for each service order, step 430. Step 430 may be performed by risk handling module 330. In some embodiments, the risk coping module 330 may perform different risk coping operations according to the risk determination result in step 420, which may include risk ranking operations, risk confirmation operations, risk handling operations, continuous monitoring, or any combination thereof.

The processing device 110 needs to process multiple service orders at the same time, and when the number of orders to be processed is large, the multiple orders need to be sorted to ensure that the orders with higher risk degree are processed in time. In some embodiments, the risk determination results of the service orders may be ranked, and in particular, one or more risk parameters may be determined based on the risk determination results, and the ranking may be performed based on the risk parameters. The risk parameter may be some data in the relevant data of the service order (for example, a characteristic value such as a stay time in a stay abnormality risk, and the longer the stay time is, the more dangerous the stay time is), or may be a risk type, a risk level, or a risk probability in a risk determination result.

In some embodiments, the risk ranking operation may be based on a ranking rule. The ranking rule may also rank the risk probabilities and/or the levels according to the determination results. The sorting rule may also be setting a sorting result threshold (e.g., a level threshold, a probability threshold, etc.), and sorting the risk determination results that satisfy different thresholds respectively. The ranking rule may be a ranking directly according to the magnitude of the risk probability contained in the risk decision result. The ranking rule may also be based on the magnitude of some operation result (e.g., a weighted average) of a plurality of risk parameters.

In some embodiments, the risk ranking operation may be performed based on a ranking model. The ranking model may be a mathematical statistical model, and the risk ranking results may be derived by formula calculations (e.g., weight calculations) based on the eigenvalues in the different risk categories and/or the eigenvalues of the total risk, respectively. The ranking model may also be a Machine learning model including, but not limited to, a Classification and Logistic Regression (Logistic Regression) model, a K-Nearest Neighbor algorithm (K-Nearest Neighbor, kNN) model, a Naive Bayes (Naive Bayes, NB) model, a Support Vector Machine (SVM), a Decision Tree (Decision Tree, DT) model, a Random Forest (RF) model, a Regression Tree (Classification and Regression Trees, CART) model, a Gradient Boosting Decision Tree (GBDT) model, an xgboost (xtransition Gradient), a Light Gradient Boosting Machine (Light Gradient Boosting Machine, lightm), a Gradient Boosting Machine (Boosting, summary), a Light Gradient Boosting Machine (alert and weighted), an Artificial Neural network (Artificial Neural network, so), and so on. The model can be obtained after training based on the characteristic data of the triggering risk. The risk handling module 330 may input the risk determination results of the plurality of service orders into the trained risk ranking model to determine the ranking results. In some embodiments, the risk handling module 330 may input some or all of the relevant data of the plurality of service orders with risks as the risk determination result into the trained risk ranking model to determine the ranking result. Depending on the sample data form of the model training.

In some embodiments, the risk handling module 330 may sort each type of risk separately, resulting in sorting results under different risk types. In some embodiments, risk handling module 330 may rank all risks comprehensively. For example, weights may be set for different risk categories, orders with different risks may be comprehensively ranked according to the weights, and a risk ranking result of all service orders may be determined. In some embodiments, risk coping module 330 may rank the service orders for which the risk determination results belong to a certain risk type combination. For example, service orders with risk determination results of robbery and personal safety events may be comprehensively ordered.

In some embodiments, risk coping module 330 may skip the risk ranking operation, processing each service order directly, including risk confirmation, risk handling, and/or continuous monitoring. It should be noted that the operations performed by risk handling module 330 may be different for different risk determination result service orders. For example, for high risk orders (e.g., with a risk probability greater than 50%), risk coping module 330 can perform risk handling operations, alert the user, and/or alert directly. For another example, the risk coping module 330 may perform risk confirmation on service orders other than high risk orders and immediately perform alarm and/or rescue coping when a real danger is confirmed. For non-risky service orders or non-risky orders after risk confirmation, the risk response module 330 may perform continuous monitoring to find risks in the first time. In some embodiments, the risk handling module 330 may also process all orders in the same manner. For example, all service orders are first risk confirmed and then subsequent operations are performed, or directly disposed of.

In some embodiments, the purpose of risk confirmation may be to determine the actual condition of the service order and/or to determine whether it is consistent with the decision made through the risk decision operation. In some embodiments, the risk confirmation operation may include risk confirmation by interacting with user information, risk confirmation by a worker going to the field, risk confirmation by obtaining in-vehicle audio or image information, risk confirmation based on traffic system broadcast information confirmation, and the like, or any combination thereof. The user may refer to a party to a service order, including a service provider and/or a service requester. The risk confirmation through interaction with the user information may be confirmation of the risk through ways including Interactive Voice Response (IVR) outbound call, terminal display screen pop-up, application text/Voice query, telephone interaction, and the like. For example, the user may be called out through an IVR to enter information, such as a cell phone number, on the user's terminal (e.g., terminal 120) to confirm that the user is in a safe state. The telephone interaction may be a communication by placing a call to the user to confirm the risk. The risk handling module 330 may obtain the telephone interactive content, and confirm whether the telephone receiver is the user, whether dangerous words appear in the telephone interactive content of the voice of the receiver, and the like through voice recognition, semantic recognition, tone recognition, and the like, so as to perform risk confirmation. For example, the driver and/or passenger may be confirmed to be at risk by telephonic communication with the driver and/or passenger. For another example, the driver can collect his/her ride voice information by calling an anonymous call (e.g., insurance promotion, building promotion, telephone shopping, etc.), and risk can be confirmed by recognizing the voice of the other party (e.g., anger, background sound, personal voiceprint, etc.). Also for example, non-risk parties may also be communicated telephonically (e.g., a driver may be considered telephonically interactive when determining that a passenger is at risk) to confirm risk. The confirmation of risk by staff to the field may be based on the location of the vehicle or participant of the service order, notifying staff nearby the location to go to confirmation. The risk confirmation by acquiring the audio or image information in the vehicle may be performed by automatically or manually confirming the risk after acquiring the audio and video in the vehicle through a sensor (e.g., an image sensor, a sound sensor, etc.) installed on a terminal (including a service provider terminal, a service requester terminal, a vehicle-mounted terminal, etc.). The risk confirmation based on the traffic system broadcast information confirmation can be that the service order risk occurrence authenticity to be subjected to risk confirmation is confirmed through the event occurrence place, time and event type in the traffic system broadcast information. In some embodiments, the risk confirmation operation may further include by manual confirmation. The manual risk confirmation may be to display various information of the service order requiring the risk confirmation to the background safety confirmation staff, such as a driving track, video and audio recording in the vehicle, the current position of the user, historical risk data of the user, historical risk cause, and the like, and the safety confirmation staff determines the relevant risk information, such as where the vehicle stops, the stopping time is multiple times, whether the driving track disappears, whether there is a physical and/or language conflict between users, and the like.

In some embodiments, the risk handling operations may include notifying emergency contacts, initiating driver-side and/or passenger-side data reporting, special person follow-up alerts, and the like, or any combination thereof. The emergency contact may be contact information (e.g., cell phone number) of a first-order contact that the passenger and/or driver added during registration and/or use of the on-demand service (e.g., via the passenger and/or driver's terminal, mobile application, etc.) if the passenger and/or driver encounters danger. For example, a quick portal (e.g., contact emergency contacts button, alarm button, help button) may be provided on the user terminal that communicates with the back-end security platform. When the user is in a dangerous condition, the user can click the emergency contact button, the terminal detects that the button is triggered and then can automatically send help seeking voice or text information to the emergency contact, and the current positioning information of the terminal can be automatically added into the information. Or the user can alert the police by clicking the alert button. After alarming, the terminal can also send the current position and the travel information of the alarming user to the police to assist rescue. The driver-side and/or passenger-side data may be audio, video, image, etc. data obtained by various sensors mounted on the mobile device of the driver and/or passenger, e.g., the terminal 120 or the mobile device 200. The processing device 110 may automatically retrieve the data. The user can also actively report the data. The special person follow-up alarm may be processing of alarming and the like in a way that a special person (e.g., a manual customer service) follows up. In some embodiments, risk handling module 330 may also perform risk handling operations on the service orders that have been risk validated. For example, assuming that an order is identified as being at risk, risk handling module 330 may perform a risk handling operation of alerting.

In some embodiments, the risk treatment may include risk studies. The risk coping module 330 may obtain the service orders satisfying the risk research and judgment condition and the related service order data, and obtain the risk judgment result of the service orders and the risk information related to various aspects of the service orders. The risk coping module 330 may send the above data to a processing device associated with the judge and obtain a manual judge result through the processing device associated with the judge. The risk judging condition may include that the service order has risk, the risk level or risk probability exceeds a judging threshold, the service order has not been risk confirmed, the service order has no risk after risk confirmation at a previous time (for example, "temporary safety" or "temporary alarm") but is judged to have risk at the current time, and the like. For a service order satisfying the risk judgment condition, the risk coping module 330 may obtain a risk judgment result of the service order (e.g., based on step 420) and risk information related to various aspects of the service order, including user information (e.g., current location, number of complaints of the user, etc.), vehicle location (e.g., remote area in the environment, etc.), trajectory data (e.g., deviation of the route from a common route, too long stay in a certain location, etc.), in-vehicle environment extraction information (e.g., recording, video, call, image, etc.), and external association information (e.g., traffic volume, etc.). After obtaining the information, risk management module 330 may send the data to a processing device associated with the judge. The processing equipment associated with the judge may, upon receiving the data, automatically make a judgment on the service order to determine whether a malignancy and/or an abnormal situation has occurred, or the judge may make the judgment by manipulating the processing equipment. In some embodiments, the risk management module 330 may generate a job order and assign the job order to a plurality of processing devices associated with a job clerk for a job to determine a result of the job. The decision work order may be displayed in a preset form (e.g., a list) in an interface (e.g., a processing interface of a processing device associated with the decision worker), and the background security decision worker may select or click on the list to view information contained in the decision work order, for example, to generate a risk determination result of a service order of the decision work order and risk information related to various aspects of the service order, and determine whether a malignant event and/or an abnormal situation occurs. Meanwhile, the information can also be in a highlighted form, such as changes of font color and thickness. In some embodiments, the risk management module 330 may first determine a service order satisfying the criteria and send the determination in the form of a systematic opinion along with the criteria work order to a processing device associated with the criteria person to assist in the determination.

In some embodiments, the risk disposition may also include risk rescue. Risk response pair module 330 may generate rescue information based on information related to the service order to be risk disposed and the risk determination result. Specifically, the risk coping module 330 may determine whether the service order satisfies the risk rescue condition based on the risk determination result. The risk handling module 330 may confirm the service order in the risk determination result in which the risk level and/or the risk probability exceed the rescue threshold, for example, 80%, 85%, or 90%, as satisfying the risk rescue condition. For service orders that satisfy the rescue conditions, risk coping module 330 can generate rescue information based on information related to the service orders. For example, the risk handling module 330 may generate rescue information based on the position of the vehicle, the vehicle information, the type of risk determined to occur, and the like, for example, a white vehicle with a license plate number of jing a12345, which is located near the east door of the central park, has an abnormal parking condition, is suspected of having a robbery event, and asks you to look up the rescue. After generating the rescue information, risk coping module 330 sends the rescue information to a processing device associated with the police, a terminal associated with the emergency contact, and/or a terminal associated with another service provider. When the processing device associated with the police sends rescue information, the police may be alerted at the same time. When the rescue information is sent to the terminal associated with the emergency contact, the reminding information can be sent at the same time to remind the emergency contact to give an alarm to the police, or the personal safety is ensured when checking and/or rescuing. The other service providers include service providers that are not more than a set distance threshold from a current execution location of the service order to be risk disposed. The current execution location may refer to a relevant party of the service order to be processed at risk at the current time, including the location of the user and the vehicle. In some embodiments, while the rescue information is being sent, a subsidy or reward information may also be sent, prompting a service provider (e.g., a driver) that the subsidy or reward may be available for viewing and/or rescue. In some embodiments, different numbers and types of drivers may be notified for different risk events. For example, the number of drivers notified of a rescue visit due to an abnormal stay event is much smaller than for a robbery event. While informing drivers who are heading for a rescue robbery event may be young drivers. In some embodiments, the rescue information may be sent in consideration of the distance of other drivers from the location where the risk event occurred and the road conditions.

In some embodiments, the risk coping process may delay processing. By collecting the user's security activities over the delay time, stress and impact on the risk processing devices (e.g., processing device 110) may be reduced. Because the processing device 110 needs to process multiple service orders at the same time, the delay processing can reduce the load of the processing device 110 and increase the processing speed of the orders. In some embodiments, after determining that the at-risk service order is ended, risk coping module 330 may obtain data reflecting user behavior associated with the service order and determine whether the user associated with the service order performs security behavior based on the data reflecting user behavior associated with the service order. Cancelling the determination that the service order is at risk if a security action occurs for a user associated with the service order. For example, if the service order determined to have the risk of abnormal parking in step 420 is a general risk level (e.g., the risk level and the risk probability are within the preset threshold range), the order may be continuously monitored, and if the driver continues to receive orders and/or the passenger continues to issue orders normally after the order is ended, the determination that the risk of abnormal parking exists may be cancelled, and the driver and/or the passenger may be determined to be safe. In some embodiments, orders determined to be at high risk may also be validated during the delay phase. For example, the verification may be performed by manual verification, automatic verification, phone-based interactive verification, etc., for example, to guide the passenger to confirm whether there is a security risk on the passenger terminal (e.g., sending information to be answered in APP, initiating a red packet robbing activity, etc.), automatically dial a service call, indirectly dial a call (e.g., obtaining relevant information by dialing a financial service call, etc.), contact friend verification, etc.

In some embodiments, a user may autonomously determine and report security risks. For example, a quick entry (e.g., an alert button, a help button) may be included in the interface of the application 380 that communicates directly with the on-demand service platform through which the user may report risk. For another example, the user may perform a particular operation on the mobile device 200, such as pressing, shaking, or throwing. A sensor (e.g., a sound sensor, an image sensor, a pressure sensor, a velocity sensor, an acceleration sensor, a gravity sensor, a displacement sensor, a gyroscope, etc., or any combination thereof) installed in the mobile device 200 detects that the specific operation is, an alarm procedure may be initiated to report a security risk. After receiving the report, the risk handling module 330 may determine the accuracy of the reported security risk (e.g., whether there is noise, etc.) and perform risk confirmation and risk handling.

In some embodiments, the risk management may also include continuous monitoring. The continuous monitoring may be performed on the service orders determined to be risk-free in step 420, or may be performed on the service orders at the end of the risk ranking, or may be performed on the service orders that are risk-free after risk confirmation. In some embodiments, risk handling module 330 may determine a terminal associated with a service order to be continuously monitored based on information about the service order. The terminal may be a service provider terminal, a service requester terminal, a vehicle-mounted terminal, etc. Risk management module 330 may obtain text, audio, and/or image data reflecting the service order execution live via the terminal. Data acquisition may be achieved through various sensors installed on the terminal. For example, audio data may be acquired by a sound sensor (e.g., a microphone) and video data may be acquired by an image sensor (e.g., a camera). The acquired data can be used for risk determination and disposal at the next time, for example, after 10 s.

It should be noted that risk determination and handling for an order is an ongoing process. When a particular order is determined to be safe at the current time or is determined to be safe during a risk management operation (e.g., a risk confirmation operation), continuous monitoring is still performed, and risk determination and management are repeated to determine whether a risk event will occur subsequently, for example, risk determination and subsequent steps are performed every predetermined time (e.g., 10 seconds). The risk assessment and handling process for the particular order may end until a threshold time has been reached after the end of the order, e.g., 10 minutes, 20 minutes, 30 minutes after the end of the order. Meanwhile, for the service order with risk determination result obtained in step 420 being risk-free, the risk handling module 330 may perform continuous monitoring on the service order.

Likewise, it will be appreciated that the processing operations in the risk management pair may be performed selectively. In some embodiments, the risk handling module 330 may sort all the service orders based on the risk determination result, and then selectively perform the subsequent operation according to the sorted result. For example, risk coping module 330 can select the top ranked service order to perform risk handling operations, the middle ranked service order to perform risk handling operations, and the bottom ranked service order to perform continuous monitoring operations. In some embodiments, risk coping module 330 may skip the sorting step, perform risk validation directly on all service orders and perform subsequent handling operations based on validation results. For example, non-risk service orders after risk confirmation can be continuously monitored, and corresponding risky orders can be selected to remind a user (such as abnormal parking of a vehicle) or directly give an alarm (such as robbery) according to the risk. In some embodiments, risk handling module 330 may handle all service orders based directly on the risk determination results. For example, risk handling module 330 may send an alert to an associated user of a service order for which the risk determination results in a low risk. For a service order with a high risk as a result of the risk determination, the risk handling module 330 may directly notify the police. For non-risky service orders, however, the risk management module 330 may continue to monitor to prevent subsequent risks from being discovered in the shortest amount of time. In some embodiments, risk coping module 330 may rank the service orders based on the risk determination results and directly handle the service orders based on the ranking results. For example, risk handling module 330 may process the top ranked service orders (e.g., high risk orders) first and continue processing the bottom ranked orders (e.g., low risk orders) after completion. In some embodiments, the risk handling module 330 may delay processing of the service order based on the risk determination. For example, the risk handling module 330 monitors for service orders that are determined to be at risk. Upon its conclusion, risk handling module 330 may obtain behavioral data of the user related to the order. If the user has a security action, such as the user associated with the high risk order continues to request transportation services after the order is completed, the risk handling module 330 may confirm the at-risk service order as a security order.

At step 440, rules and/or models are updated based on the risk response operation results. Step 440 may be performed by update module 340.

In some embodiments, the updated rules may include risk decision rules, risk ranking rules, etc., and the updated models may include risk decision models, risk ranking models, etc. In some embodiments, the update module 340 may obtain the difference according to the comparison between the risk confirmation result and/or the risk treatment result and the risk determination result. And updating the risk parameter values in the decision rule according to the difference. For example, the rule for determining the robbery event may be to determine according to the invoice time and the starting location, and set that the invoice time exceeds 12 pm and the travel destination is located in the neighborhood of city or county, which may cause the robbery risk. If the risk of the order with the robbery risk is confirmed, the order with the order issuing time between 12 o 'clock and 12 o' clock in the evening is found, and the robbery event does not occur. The updating module can change the judgment rule for judging the robbery time into the condition that the invoice sending time exceeds 12 o' clock and a half night and the travel end point is located in the adjacent city and county, so that the robbery risk is possibly generated. In some embodiments, the update module 340 may retrain the risk determination model as new sample data to update parameters in the model for orders determined to have a risk event in the risk confirmation operation and/or the risk treatment operation. Similarly, for the training of the risk ranking rules and the risk ranking model, the updating module 340 may also compare the risk ranking results with the risk confirmation results and/or the risk treatment results to obtain the differences and update. For example, a high risk order that is first in the rank in the sequence is determined to be risk free in a subsequent risk confirmation operation, the update module 340 may update the risk parameters used by the sequence. For the update of the risk ranking model, the updating module 340 may retrain the risk ranking model according to the feature data of each order of the actual ranking result obtained by risk confirmation or risk response, so as to achieve the purpose of updating. In some embodiments, updates to the rules and models may be made at predetermined intervals, such as, for example, a day, a week, a month, a quarter, and so forth.

It should be noted that the foregoing description is provided for illustrative purposes only, and is not intended to limit the scope of the present application. Many variations and modifications may be made to the teachings of the present invention by those of ordinary skill in the art in light of the present disclosure. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application. In some embodiments, one or more other optional operations may be omitted in exemplary method 400. For example, for a service order with a higher risk (e.g., a higher risk level, a higher risk probability, etc. than a preset threshold) as a result of the risk determination, the risk ranking operation and the risk confirming operation may be omitted, and the risk handling operation (e.g., alarming or transferring to a security personnel for judgment) may be performed directly. For another example, for a service order with a low risk (for example, the risk level, the risk probability, and the like are lower than the preset threshold) as a result of the risk determination, the monitoring waiting process may be performed (for example, data acquisition is continuously performed, and the risk determination is performed again after a preset time).

Fig. 5 is a block diagram of a female security risk prevention system 500 according to some embodiments of the present application.

All or some of the functional modules in the female security risk prevention system 500 may be run on the processing device 110. As shown in fig. 5, the female security risk prevention system 500 may include an obtaining module 510, a determining module 520, an executing module 530, and an updating module 540.

The obtaining module 510 may be configured to obtain relevant data of the current order, where the relevant data of the current order at least includes data associated with the current order and/or status data of the current order when executed. The acquisition module 510 may be implemented by the data acquisition module 310 in the processing device 110.

In some embodiments, the data associated with the current order includes at least one of: the service provider's identity information, the service provider's operational behavior information at the platform, the identification information of the vehicle associated with the service provider, the service time, the trip origin, the trip destination, the trip path, the service requester's identity information, and the service requester's operational behavior information at the platform. The obtaining module 510 may obtain data related to the order through the service requester terminal, the service provider terminal, and other sensors. In some embodiments, the obtaining module 510 may obtain data related to the current order and may also obtain data related to historical orders. Once an order is completed, the order may be considered a historical order. The data related to the historical orders can be used to train a risk assessment model and an ordering model. The risk judgment model can judge the risk of the female security event of the current order according to the related data of the current order. In some embodiments, the ranking based on the determination result may include ranking the determination result based on a ranking model. The ranking model may add weight to different characteristic parameters in the current order. And calculating the risk level of the order based on the weight, and sequencing the order according to the descending order of the risk level.

The determining module 520 may be configured to determine whether the sex of the service provider and the sex of the service requester of the current order are the same, and perform female security risk determination in response to that the sex of the service provider and the sex of the service requester of the current order are different; the method can also be used for processing the related data of the current order by using a risk judgment model and determining a female safety risk judgment result. The decision module 520 may be implemented by the risk decision module 320 in the processing device 110.

In some embodiments, the risk determination module 520 determines whether a woman is participating in the current itinerary based on the identity information of the service requester/service provider. The female may be a service requester (passenger) or a service provider (driver). In response to detecting information of a trip start in which a woman participates, the risk determination module 520 analyzes the acquired related information of the order, compares the characteristic parameters of the current order with the characteristic parameters of the historical order, and acquires a woman safety risk determination result. The risk assessment model can be obtained by the following method: acquiring a historical order; marking orders including female safety events in historical orders as positive samples, and marking normal orders in the historical orders as negative samples; and training an initial model based on the related data and the marking result of the historical order to obtain the risk judgment model. In some embodiments, the risk assessment model may be comprised of a plurality of independent assessment models. For example, the risk determination includes a sound/image determination model, a position determination model, a vehicle speed determination model, and a physiological determination model. The judgment object in each independent judgment model is different. In the sound/image determination model, the determination target is a feature parameter related to sound/image. In the position determination model, the determination target is a characteristic parameter related to the position. In the vehicle speed determination model, the determination target is a characteristic parameter related to the vehicle speed. In the physiological judgment model, a judgment target is a characteristic parameter related to physiology.

In some embodiments, the risk assessment model may include a distance assessment model. For example, in a history order, the distance between the passenger and the driver at the time of a female safety event is less than 1 meter, and 1m may be set as the distance threshold. During driving, the speed-related characteristic parameter is matched if the distance between the passenger and the driver is greater than a distance threshold. The distance between the passenger and the driver can be measured by a distance sensor installed in the service requester terminal and/or the service provider terminal.

An executing module 530 may be configured to execute a set operation based on the female safety risk determination result. The execution module 530 may be implemented by the risk management module 330 in the processing device 110.

In some embodiments, the operations that may be performed based on the risk determination result may include one or any combination of sorting, risk verification operations, or risk handling operations. The decision module 530 may include a risk ranking unit, a risk confirmation unit, a risk handling unit.

The risk ranking unit may be used to determine a ranking of the current order among the pending risk orders. The risk ranking unit may be implemented by the risk ranking unit 332 in the processing device 110. In some embodiments, the female security risk determination includes a risk level of the order. For example, when the characteristic parameter of the current order cannot match the negative sample, the risk level of the current order is 0. If the characteristic parameters of the current order are completely matched with the negative examples, the risk level of the current order is 10. The performing of the sorting process based on the determination result may include performing the sorting process based on a sorting rule on the determination result. For example, the ordering rule may be a big to small order by order risk level. The sorting process may also include sorting according to a particular class of characteristic parameters. In some embodiments, the ranking process may rank the decision based on a ranking model. The ranking model may add weight to different characteristic parameters in the current order. And calculating the risk level of the order based on the weight, and sequencing the order according to the descending order of the risk level.

And the risk confirmation unit can be used for determining to execute at least one risk verification operation based on the sequencing result of the order. The risk confirmation unit may be implemented by the risk confirmation unit 334 in the processing device 110. The risk verification operation may include, but is not limited to, one or any combination of automatic verification operation, manual verification operation, or telephone interactive verification operation. The risk verification operation may exclude risk false positives. The automatic verification operation may eliminate risk false positives by obtaining information about the vehicle surroundings. The manual verification operation can judge whether the female safety event risk exists through regulating and controlling manual customer service intervention. The phone interactive verification operation may verify whether the service provider and/or the service requester are at risk by sending a verification text message and/or dialing a verification phone.

A risk handling unit, configured to perform at least one risk handling operation based on the risk verification determination result. The risk handling unit may be implemented by a risk ranking process 336 in the processing device 110. The at least one risk handling operation may include at least one of: notifying the emergency contact; starting monitoring equipment in the vehicle; triggering a reporting mechanism of a user terminal, wherein the user terminal comprises a service provider terminal and/or a service requester terminal; and contacting service providers around the user terminal for assistance. For example, upon confirming that there is a risk of a female security event, the risk handling unit may notify other service requestors in the vicinity of the vehicle to assist via network 140. In some embodiments, the risk handling unit may take measures to delay triggering. Continuously monitoring the order with the judged result that the female safety risk exists; and (4) cancelling the female safety risk judgment of the order after confirming the safety behavior.

The update module 540 may update the risk assessment model. The update module 540 may be implemented by the update module 340 in the processing device 110.

In some embodiments, when an order is completed, the order may be considered a historical order. The risk handling unit may obtain historical order data and the historical order data. And determining a female safety risk judgment result by using the risk judgment model. And sequencing the historical orders by utilizing a sequencing model. And recording the confirmation result and the processing mode of the risk judgment model. By comparing the validation results of the risk assessment model with the actual validation results, the update module 540 can update the rules and models involved in the process.

It should be noted that the above description of the female risk prevention system and the modules thereof is merely for convenience of description and should not limit the present application to the scope of the illustrated embodiments. It will be appreciated by those skilled in the art that, given the teachings of the present system, any combination of modules or sub-system configurations may be used to connect to other modules without departing from such teachings. For example, in some embodiments, the number obtaining module 510, the determining module 520, the executing module 530 and the updating module 540 may be different modules in one system, or may be one module to implement the functions of two or more modules described above. For example, the determining module 520 and the executing module 530 may be two modules, or one module may have both matching and allocating functions. For example, each module may share one memory module, and each module may have its own memory module. Such variations are within the scope of the present application.

Fig. 6 is an exemplary flow chart of a method 600 for female security risk prevention according to some embodiments of the present application.

As shown in fig. 6, the female security risk prevention method 600 may include:

step 610, acquiring relevant data of an order; the relevant data of the order at least comprises data related to the current order and state data when the current order is executed.

In some embodiments, the obtaining module 510 may obtain data related to a current order, including at least data associated with the current order and status data of the current order as it executes. The relevant data of the current order comprises various data of the service requester for sending the order request, the service provider for responding the order request, the driving process and the travel after the travel is finished. The obtaining module 510 may obtain data related to the order through the service requester terminal, the service provider terminal, and other sensors. For example, a gyroscope is installed in the terminal, and the obtaining module 510 may determine the inclination degree of the vehicle through the gyroscope.

In some embodiments, the relevant data for the current order may include data associated with the current order and/or status data at the time the current order is executed. The current order data may be identity information of the service requester and/or service provider, travel information of the current order, operational behavior information of the service requester and/or service provider. The status data of the current order execution includes at least one of: location information, environmental data, driving information of the service requester and/or the service provider. The identity information of the service requester and/or service provider may include: name, gender, age, native place, identity document, score, etc. The travel information for the current order may include one or more form-related information and/or characteristics, such as a travel start point, a travel destination, a travel path, and the like. The operations of the service requester and/or the service provider to confirm, modify, cancel, etc. the order may be considered as the operation behavior information of the service requester and/or the service provider. The status data at the time of execution of the current order may be relevant information in the course of execution of the current order by the service provider. The location information may be the current location of the service provider and/or the service requester. The environmental information may be weather conditions, wind speed, visibility, etc. The driving information may include data such as the speed of the service provider (driver), the current location, the driving route, images and/or sounds of the interior of the vehicle during driving, and the physical condition of the service provider and/or the service requester.

Step 620, judging whether the sex of the service provider and the sex of the service requester of the current order are the same, and performing female safety risk judgment in response to the difference of the sex of the service provider and the sex of the service requester of the current order; and determining a female safety risk judgment result based on the related data of the current order.

In some embodiments, the determination module 520 may determine whether a female is engaged in the current itinerary based on the identity information of the service requester/service provider. In response to detecting the information of the start of the journey that women participate in, the determining module 520 analyzes the acquired relevant data of the current order, and acquires a female safety risk determining result based on the risk determining model or comparing the characteristic parameters of the current order with the characteristic parameters of the historical order. The risk assessment model can be obtained by the following method: acquiring a historical order; marking orders including female safety events in historical orders as positive samples, and marking normal orders in the historical orders as negative samples; training an initial model based on the related data and the marking result of the historical order to obtain the risk judgment model.

Step 630, determining the rank of the current order in the pending risk order based on the female security risk determination result.

In some embodiments, the female safety risk determination may include a risk level of the current order. In some embodiments, the female safety risk judgment result may be sorted based on a sorting rule. For example, the ranking rules may be ranked from large to small according to risk level. The greater the risk level of the pending order, the higher the likelihood of a female safety event. In some embodiments, the female safety risk determination results may be ranked based on a ranking model. The ranking model may add weight to different characteristic parameters in the current order. And calculating the risk level of the order based on the weight, and sequencing the order according to the descending order of the risk level.

And step 640, determining to execute at least one risk verification operation based on the sequencing result of the current order.

In some embodiments, the risk confirmation unit may determine to perform at least one risk verification operation based on the ranking results of the orders. The risk verification operation may include, but is not limited to, one or any combination of automatic verification operation, manual verification operation, telephone interactive verification operation, and the like. The risk verification operation may exclude risk false positives. The automatic verification operation may eliminate risk false positives by obtaining information about the vehicle surroundings. The manual verification operation can judge whether the female safety event risk exists through regulating and controlling manual customer service intervention. The phone interactive verification operation may verify whether the service provider and/or the service requester are at risk by sending a verification text message and/or dialing a verification phone.

And 650, executing at least one risk processing operation based on the judgment result of the risk verification operation.

In some embodiments, the risk handling unit may perform at least one risk handling operation based on the risk verification determination. In some embodiments, the at least one risk treatment operation may include at least one of: notifying the emergency contact; starting monitoring equipment in the vehicle; triggering a reporting mechanism of a user terminal, wherein the user terminal comprises a service provider terminal and/or a service requester terminal; and contacting service providers around the user terminal for assistance. For example, upon confirming that there is a risk of a female security event, the risk handling unit may automatically dial an alarm phone or notify a transit center. The risk handling unit may also notify other service requestors in the vicinity of the vehicle for assistance via network 140. In some embodiments, the risk handling unit may continuously monitor the order for which the determination is that there is a female safety risk, and confirm a female safety risk determination that the order is cancelled after the safety action occurs.

Step 660, updating the risk judgment model based on the judgment result and the treatment result of the risk verification operation.

In some embodiments, the update module 540 may update the risk judgment model based on the judgment result of the risk verification operation and the treatment result. Once an order is completed, the order may be considered a historical order. The risk handling unit may obtain historical order data and the historical order data. And determining a female safety risk judgment result by using the risk judgment model. And sequencing the historical orders by utilizing a sequencing model. And recording the confirmation result and the processing mode of the risk judgment model. By comparing the validation results of the risk assessment model with the actual validation results, the update module 540 can update the rules and models involved in the process.

Fig. 7 is an exemplary flow chart of a female safety risk determination method 700 according to some embodiments of the present application.

As shown in fig. 7, the method 700 for determining female security risk includes:

step 701, acquiring relevant data of a current order; the relevant data for the current order includes at least data associated with the current order and status data of the current order as it executes.

In some embodiments, the current order may comprise an order that is requested by a service requester (passenger) and completed by a service provider (driver) on a network appointment platform. The data associated with the current order may include one or more information and/or characteristics associated with the order. For example, the relevant data for the current order may include data associated with the current order and/or status data at the time the current order was executed. The data associated with the current order may be identity information of the service requester and/or service provider, travel information of the current order, operational behavior information of the service requester and/or service provider. The status data of the current order execution includes at least one of: location information, environmental data, driving information of the service requester and/or the service provider.

In some embodiments, the data associated with the current order includes at least one of: the service provider's identity information, the service provider's operational behavior information at the platform, the identification information of the vehicle associated with the service provider, the service time, the trip origin, the trip destination, the trip path, the service requester's identity information, and the service requester's operational behavior information at the platform.

The identity information of the service requester and/or service provider may include: name, sex, age, native place, identity card, score, etc. The identity document may include an identity card, passport, driver's license, household registration, social security number, or the like, which may prove the identity of the service requestor and/or the service provider. In some embodiments, the service provider's identity information may also include the license plate number of the driving vehicle, vehicle characteristics, vehicle model, and the like. The travel information for the current order may include one or more form-related information and/or characteristics, such as a travel start point, a travel destination, a travel path, and the like. In some embodiments, on the networked car booking platform, the service requester issues an order request including a trip start point and a trip destination. The trip start point may be obtained by the service requester entering or locating the location of the service requester terminal. The processing device 110 may also recommend travel destinations based on the user's historical orders. Order requests made by the service requester terminal (passenger side) are transmitted to the service provider terminal (driver side) and the processing device 110 via the network 140. The processing device 110 analyzes the trip start point and the trip destination in the order request to plan a trip path. The processing device 110 may send the travel path to a service requester terminal and/or a service provider terminal. The operations of the service requester and/or the service provider to confirm, modify, cancel, etc. the order may be considered as the operation behavior information of the service requester and/or the service provider.

The status data of the current order execution may be relevant information in the service provider's process of executing the current order. When the service requester terminal and/or the service provider terminal starts the location information service, the location information of the terminal can be acquired. The position information can be acquired by a satellite navigation system, inputting longitude and latitude and the like. The environmental data may be one or more environmental related information and/or characteristics during execution of the current order. For example, the environmental data may include weather data, road condition data, wind data, and the like. In some embodiments, the environmental data may also include the brightness and visibility of the surrounding environment during execution of the current order. The driving information may include one or more characteristics and/or information related to the driving process. For example, the travel information may include data such as a vehicle speed of a service provider (driver), a current position, a travel distance, an image and/or sound in the vehicle during travel, a physical condition of the service provider and/or the service requester, and the like.

Step 703, judging whether the sex of the service provider and the sex of the service requester of the current order are the same, and performing female safety risk judgment in response to the difference between the sex of the service provider and the sex of the service requester of the current order; and determining a female safety risk judgment result of the current order at least based on the order data.

In some embodiments, the determination module 520 may determine whether a female is engaged in the current itinerary based on the identity information of the service requester/service provider. In response to detecting the information of the start of the journey that women participate in, the determining module 520 may analyze the acquired related information of the order, compare the characteristic parameters of the current order with the characteristic parameters of the historical order, and determine the matching degree. The degree of matching may weigh the female safety risk of the current order. The decision module 520 may set a threshold to determine the female security risk decision for the current order.

In some embodiments, the risk assessment model may be utilized to process the data associated with the order to determine a female safety risk assessment result. The risk judgment model can be obtained by the following method: acquiring a historical order; marking orders of historical orders, including female safety events, as positive samples, and marking normal orders in the historical orders as negative samples; and training an initial model based on the related data and the marking result of the historical order to obtain the risk judgment model. In some embodiments, the algorithm that trains the initial model may be based on a manual feature-related algorithm and/or a deep-learning algorithm. The deep learning-based algorithm may include one or a combination of fast Region-based Convolutional Neural Network (fast R-CNN) algorithm, spatial pyramid Pooling Network (SPPnet) algorithm, Full Convolutional Network (FCN) algorithm, and the like. The neural network model is a function comprising at least one parameter. The neural network model is constructed based on a neural network algorithm. The neural network algorithm may be a linear regression algorithm, a logistic regression algorithm, a proximity algorithm, or the like. Based on the obtained historical orders, comparing the characteristic parameters of the historical orders with the characteristic parameters of the orders to be identified, determining the matching degree of the characteristic parameters of the orders to be identified and the characteristic parameters of the historical orders, and determining the similarity of the historical orders and the orders to be identified based on the matching degree of the characteristic parameters. And obtaining a judgment result when the similarity is compared with a preset threshold value. The preset threshold may be related to image, sound, vehicle speed, location, heart rate, etc.

In some embodiments, the risk assessment model may be comprised of a plurality of independent assessment models. For example, the risk determination includes a sound/image determination model, a position determination model, a vehicle speed determination model, and a physiological determination model. The judgment object in each independent judgment model is different. In the audio/image determination model, the determination target is a feature parameter related to audio/image. In the position determination model, the determination target is a characteristic parameter relating to the position. In the vehicle speed determination model, the determination target is a characteristic parameter related to the vehicle speed. In the physiological judgment model, a judgment target is a characteristic parameter related to physiology.

In some embodiments, the characteristic parameters in the risk assessment model may include images and/or sounds during driving. For example, service requester terminals, service provider terminals, and/or other devices installed in the vehicle that may record audio and/or video capture sounds and/or images during driving. The sound decibels and/or images during driving are recorded in the historical order. In the positive sample, the decibel change and/or the image change at the time of the female security event can be used as the characteristic parameter. And counting the decibel change and/or the image change, and setting a sound threshold and/or an action threshold. For example, if the decibel of the sound collected by the equipment is greater than the sound threshold value in the execution process of the current order, the sound is matched with the characteristic parameter of the sound. As another example, if the magnitude of the motion of the passenger and/or driver in the image is monitored to be greater than a motion threshold, the characteristic parameters associated with the image are matched.

In some embodiments, the characteristic parameters in the risk assessment model may include position information during driving. The service requester terminal, the service provider terminal, and/or other locating means may locate the position of the vehicle. The determining module 520 determines the deviation degree between the current position and the planned position. For example, if the driver's driving path is identical to the planned path, the degree of deviation is 0, and conversely, 1. In the historical order, the deviation degree of the negative sample is between 0 and 0.4, and the deviation degree of the positive sample is between 0.6 and 1. And setting a deviation threshold value to be 0.5, and if the deviation degree of the driving path of the current order and the planned path is greater than the deviation threshold value of 0.5, matching the characteristic parameters related to the position.

In some embodiments, the characteristic parameters in the risk assessment model may include driving information during driving. For example, in a historical order, the vehicle speed in the negative sample exceeds 70km/h, and the speed threshold of 70km/h may be set. During driving, if the vehicle speed is greater than the speed threshold, the speed-related characteristic parameters are matched. As another example, the physiological data (heart rate, pulse rate, body temperature, etc.) of the driver and/or passenger can be collected in real time by the portable device, and in the negative sample, the heart rate of the passenger and/or driver is greater than 100, and 100 can be set as the physiological threshold. During driving, if the heart rate of the passenger and/or driver is greater than a physiological threshold, a physiological related characteristic parameter is matched.

In some embodiments, the determining module 520 may adjust the preset threshold according to the identity information, the location information, and/or the environmental data. For example, a region may be divided into: the female safety event is more likely to occur in extremely remote areas, county areas, urban areas and luxurious areas, wherein the extremely remote areas and the remote areas need to be lowered by preset threshold values. For example, the predetermined threshold may be lowered when the planned path and/or the travel path passes through a remote area. For another example, the regions may be divided according to the number of times of occurrence of the illegal activity, and the preset threshold of the region with the large number of times of occurrence of the illegal activity is higher than the region with the low number of times of occurrence of the illegal activity. In some embodiments, the identity information of the service provider and/or service requestor may include historical trip score data, violation records, and the like. The determination module 520 may decrease the predetermined threshold when the service provider and/or the service requester have poor historical trip score data and/or illegal violation records and the probability of a female security incident increases. For example, the determining module 520 may adjust the preset threshold according to the environment data. The environmental data may include time data. When the trip is performed at night, the determination module 520 may decrease the preset threshold. In some embodiments, the degree of lowering the preset threshold may be set according to the actual application.

In some embodiments, the female security risk determination for the current order may include a risk level for the current order. For example, when the characteristic parameter of the current order cannot match the negative sample, the risk level of the current order is 0. If the characteristic parameters of the current order are completely matched with the negative examples, the risk level of the current order is 10.

Step 705, executing the set operation based on the female safety risk judgment result.

In step 705, the execution module 530 may execute a set operation based on the female safety risk determination result.

In some embodiments, the operations that may be performed based on the risk determination result may include one or any combination of sorting, risk verification operations, or risk handling operations. According to the female security risk judgment result obtained by the judgment module 520, the risk sorting unit 531 determines the sorting of the current order in the risk orders to be processed. Based on the sorting result, the risk confirming unit 532 performs a risk verification operation. The risk verification operations may include automatic verification operations, manual verification operations, telephonic interactive verification operations, and the like. In addition, risk handling unit 533 may perform risk handling operations. The risk handling operation may include notifying an emergency contact, turning on in-vehicle monitoring equipment, triggering a reporting mechanism of the terminal, and contacting service providers around the terminal for assistance.

In some embodiments, the female security risk determination may include a risk level of the order. In some embodiments, the performing the setting further comprises: based on the risk level of the order, a risk ranking unit determines a ranking of the order in pending risk orders; based on the ranking result of the order, the risk confirmation unit determines to perform at least one risk verification operation.

In some embodiments, the ranking based on the female safety risk determination result may include ranking the determination result based on a ranking rule. The ranking rules may be ranked from large to small according to risk level. The greater the risk level of pending orders, the higher the likelihood of a female security event occurring. The sorting process may also include sorting according to a particular class of feature parameters. For example, the ranking is performed according to the degree of matching of the characteristic parameters related to the sound.

In some embodiments, the ranking based on the female safety risk determination result may include ranking the determination result based on a ranking model. The ranking model may add weight to different characteristic parameters in the current order. In some embodiments, the corresponding weight may be set for the characteristic parameter according to the actual application situation. For example, in the ranking model, the weight of the characteristic parameter relating to sound may be set to be greater than the weight of the characteristic parameter relating to visibility.

In some embodiments, the risk verification operation may include, but is not limited to, one or any combination of an automatic verification operation, a manual verification operation, or a telephone interaction verification operation. The risk verification operation may exclude risk false positives. For example, automatic verification operation is performed according to the sorting result, when the current order is processed, the matched characteristic parameter is abnormal stay, and the risk confirmation unit can judge whether traffic jam occurs in a stay place according to the current traffic condition information. The traffic road condition information can be obtained by a traffic command center, traffic broadcasting and road condition information monitoring. As another example, the risk validation unit may perform a manual verification operation. The risk confirmation unit can regulate and control manual customer service intervention. The human customer service may listen/view the audio/video collected during driving to determine if a female safety event has occurred. As another example, the risk confirmation unit may perform a phone verification operation. The risk confirmation unit may send a verification text message and/or place a verification phone call to the service requester terminal (passenger) and/or the service provider terminal (driver) via the network 140. The passenger and/or driver need to reply with specific content to confirm that no female safety event has occurred.

In some embodiments, the at least one risk handling operation may include at least one of: notifying the emergency contact; starting monitoring equipment in the vehicle; triggering a reporting mechanism of a user terminal, wherein the user terminal comprises a service provider terminal and/or a service requester terminal; and contacting service providers around the user terminal for assistance. For example, the passenger and/or driver may set up an emergency contact in a network appointment platform. The risk confirmation unit confirms that the female safety event has occurred and the risk handling unit may contact the emergency contact. The contact may be a text message sent and/or a telephone call dialed over the network 140. If the monitoring equipment is installed in the driving vehicle, the risk handling unit can remotely start the monitoring equipment in the vehicle, and meanwhile, the artificial customer service is regulated and controlled to handle or the traffic management department is informed to monitor the abnormity of the current journey. As another example, the passenger and/or driver may trigger the reporting mechanism of the user terminal by clicking an emergency button in the service requester terminal and/or the service provider terminal or speaking a preset trigger phrase. The passenger and/or driver may set the trigger phrase in the net appointment platform. When a responsive trigger phrase is detected, the risk handling unit may automatically dial an alarm call or send an alarm message. As another example, if the occurrence of a female security event is detected, the risk handling unit may send information to a terminal near the driving vehicle over network 140 for assistance by surrounding service providers.

In some embodiments, the method further comprises: a delayed trigger process comprising: continuously monitoring the order with the judged result of female safety risk; and (4) determining the female safety risk of cancelling the order after confirming the safety behavior. The female safety risk can be judged by the characteristic parameters related to the position, and if the deviation degree of the actual path relative to the planned path is too large, the female safety risk can exist. The risk handling unit can continuously monitor orders with female safety risks by regulating and controlling the artificial customer service, and can cancel female safety risk judgment of the orders after the completion of the journey is confirmed and no safety event occurs.

It should be noted that the above description related to the flow 700 is only for illustration and explanation, and does not limit the applicable scope of the present application. Various modifications and changes to flow 700 may occur to those skilled in the art upon review of the present application. However, such modifications and variations are intended to be within the scope of the present application.

FIG. 8 is an exemplary flow diagram of a system update method 800 according to some embodiments of the present application.

As shown in fig. 8, the system update method 800 may include:

step 801, obtain historical order data.

In some embodiments, the update module 540 may obtain historical order data. In some embodiments, the historical orders may include orders that were once requested by a service requester (passenger) and completed by a service provider (driver) on a networked car appointment platform. The historical order data may include information and/or characteristics related to one or more historical orders. For example, the historical order data may include any combination of one or more of historical order number, historical order origin, historical order destination, historical order start time, historical order end time, the passenger initiating the historical order, the driver completing the historical order (including driver information, vehicle information, etc.), the type of historical order, the intrinsic value of the historical order, the pick-up cost of the historical order, and the like.

In some embodiments, once an order is completed, the order may be considered a historical order. The service requester terminal (e.g., passenger) and the service provider terminal (e.g., driver) may transmit the associated historical order data to a storage medium (e.g., storage device 130) of the system 100 via the network 140. The processing device 110 (e.g., the acquisition module 310) may obtain historical order data from a storage medium of the system 100.

In some embodiments, the historical order data may include historical orders for a past period of time (e.g., 6 hours, 12 hours, 1 day, 2 days, 3 days, 5 days, 7 days, 14 days, 1 month, 3 months, etc.). In some embodiments, the historical order data may include a number (e.g., 10, 50, 100, 500, 1000, 1 ten thousand, etc.) of historical orders that were most recently completed. In some embodiments, the historical orders may be orders within a certain area. For example, the starting point of all historical orders may be within a certain area; or the end points of all historical orders may be within a certain area; or the tracks of all historical orders are in a certain area; or all historical orders have a trajectory that is partially within a certain area, etc. The area may include a city, a region, a street, a predetermined area, etc.

Step 803, the historical order data is processed.

In some embodiments, risk handling unit 533 may process the historical order data. And determining a female safety risk judgment result by using the risk judgment model. And sequencing the historical orders by utilizing a sequencing model. And recording the confirmation result and the processing mode of the risk judgment model.

At step 805, the rules and models involved in the process are updated.

In some embodiments, risk handling unit 533 may update the rules and models involved in the processing. The risk handling unit 533 may compare the confirmation result of the risk judgment model with the actual confirmation result. For example, the risk assessment model assesses a decibel change caused by passing a whistling vehicle during driving as a female safety event. And after the confirmed result is compared with the actual result, updating the risk judgment model, and adding the frequency of the sound into the risk judgment model as a characteristic parameter. In some embodiments, the determination results may be ranked based on a ranking model. The ranking model may add weight to different characteristic parameters in the historical order. For example, for the characteristic parameter related to sound and the characteristic parameter related to visibility, the weight of the characteristic parameter related to sound in the ranking model is greater than the weight of the characteristic parameter related to visibility. The update module 540 may compare the ranking derived from the ranking model to the actual risk level ranking. If the visibility-related characteristic parameters have a greater effect on the occurrence of a female safety event than the voice-related characteristic parameters in the actual risk level ranking, the updating module 540 may adjust the ranking model such that the weight of the voice-related characteristic parameters is less than the weight of the visibility-related characteristic parameters. For another example, in a historical order, when an abnormal parking is detected, the risk verification operation taken is a manual verification operation, and the operation actually taken is an automatic verification operation. The update module 540 may update the operation in this case to an automatic verification operation.

It should be noted that the above description related to the flow 800 is only for illustration and explanation, and does not limit the applicable scope of the present application. Various modifications and changes to flow 800 may occur to those skilled in the art upon review of the present application. However, such modifications and variations are intended to be within the scope of the present application.

The beneficial effects that may be brought by the embodiments of the present application include, but are not limited to: (1) the female safety risk is judged on the order by acquiring the relevant data of the order, so that the order with the female safety risk can be found as soon as possible, the driving risk is reduced, and the driving safety is improved. (2) Corresponding operation is carried out according to the risk judgment result, so that risk precautionary measures under different conditions can be carried out according to risk conditions, pertinence is achieved, and meanwhile the working efficiency of the platform can be improved. It is to be understood that different embodiments may produce different advantages, and in different embodiments, any one or combination of the above advantages may be produced, or any other advantages may be obtained.

Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing detailed disclosure is to be considered merely illustrative and not restrictive of the broad application. Various modifications, improvements and adaptations to the present application may occur to those skilled in the art, although not explicitly described herein. Such alterations, modifications, and improvements are intended to be suggested herein and are intended to be within the spirit and scope of the exemplary embodiments of the present application.

Also, this application uses specific language to describe embodiments of the application. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the present application is included in at least one embodiment of the present application. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the present application may be combined as appropriate.

Moreover, those skilled in the art will appreciate that aspects of the present application may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereof. Accordingly, various aspects of the present application may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the present application may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.

The computer storage medium may contain a propagated data signal with the computer program code embodied therewith, for example, in baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, etc., or any suitable combination. A computer storage medium may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or any combination of the preceding.

Computer program code required for operation of various portions of the present application may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages, and the like. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).

Furthermore, unless explicitly stated in the claims, the order of processing elements and sequences, the use of alphanumeric characters, or the use of other names in the present application is not intended to limit the order of the processes and methods in the present application. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing server or mobile device.

Similarly, it should be noted that in the preceding description of embodiments of the application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to require more features than are expressly recited in the claims. Indeed, embodiments may have fewer than all of the features of a single embodiment disclosed above.

Some embodiments have been described using numbers to describe components, attributes, and quantities, it being understood that such numbers used in the description of the embodiments have been modified in some instances by the use of the modifier "about", "approximately" or "substantially". Unless otherwise indicated, "about", "approximately" or "substantially" indicates that the number allows a variation of ± 20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that may vary depending upon the desired properties of the individual embodiments. In some embodiments, the numerical parameter should take into account the specified significant digits and employ a general digit preserving approach. Although numerical ranges and parameters setting forth the breadth of the range are approximations in some embodiments of the application, the setting for such values is as precise as possible within the scope of the application, in particular embodiments.

For each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., cited in this application, the entire contents of which are hereby incorporated by reference into this application. Except where the application is filed in a manner inconsistent or contrary to the present disclosure, and except where the claim is filed in its broadest scope (whether present or later appended to the application) as well. It is noted that the descriptions, definitions and/or use of terms in this application shall control if they are inconsistent or contrary to the statements and/or uses of the present application in the material attached to this application.

Finally, it should be understood that the examples described herein are for the purpose of illustrating the principles of the examples herein. Other variations are also possible within the scope of the present application. Thus, by way of example, and not limitation, alternative configurations of the presently claimed embodiments can be considered in accordance with the teachings of the present application. Accordingly, the embodiments of the present application are not limited to only those embodiments explicitly described and depicted herein.

Claims

1. A method for female safety risk prevention, the method comprising:

acquiring related data of a current order, wherein the related data of the current order at least comprises data associated with the current order and/or state data when the current order is executed;

judging whether the sexes of the service provider and the service requester of the current order are the same or not, and performing female safety risk judgment in response to the difference between the sexes of the service provider and the service requester of the current order;

determining a female safety risk judgment result of the current order at least based on the related data of the current order;

and executing set operation based on the female safety risk judgment result.

2. The method of claim 1, wherein the data associated with the current order comprises at least one of:

identity information of the service provider, operation behavior information of the service provider on the platform, service time, travel information, identity information of the service requester, and operation behavior information of the service requester on the platform;

the status data of the current order execution includes at least one of:

location information, environmental data, driving information of the service requester and/or the service provider.

3. The method of claim 1, wherein determining a female safety risk determination during execution of a current order based at least on data associated with the current order further comprises:

and processing the related data of the current order by using a risk judgment model, and determining a female safety risk judgment result.

4. The method of claim 3, wherein the risk assessment model is obtained by:

acquiring a historical order;

marking the order of the historical orders, which comprises the female safety event, as a positive sample, and marking the normal order in the historical orders as a negative sample;

and training an initial model based on the related data and the marking result of the historical order to obtain the risk judgment model.

5. The method of claim 1, wherein the female security risk determination comprises a risk level of the order;

the executing set operation based on the female safety risk determination result further includes:

determining the ranking of the current order in the pending risk orders based on the risk level of the current order;

and determining to execute at least one risk verification operation based on the sequencing result of the current order.

6. The method of claim 5, wherein the risk verification operation includes, but is not limited to, an automatic verification operation, or a telephonic interactive verification operation.

7. The method of claim 5, wherein performing the set operation based on the female safety risk determination further comprises:

executing at least one risk handling operation based on the judgment result of the risk verification operation;

the at least one risk handling operation includes at least one of:

notifying the emergency contact;

starting monitoring equipment in the vehicle;

triggering a reporting mechanism of a user terminal, wherein the user terminal comprises a service provider terminal and/or a service requester terminal;

and contacting service providers around the user terminal for assistance.

8. A female safety risk containment system, the system comprising:

the acquisition module is used for acquiring relevant data of the current order; the related data of the current order at least comprises data related to the current order and/or state data when the current order is executed;

the judging module is used for judging whether the sexes of the service provider and the service requester of the current order are the same or not, and performing female safety risk judgment in response to the fact that the sexes of the service provider and the service requester of the current order are different;

the system is also used for determining a female safety risk judgment result of the current order at least based on the relevant data of the current order;

and the execution module is used for executing set operation based on the female safety risk judgment result.

9. The system of claim 8, wherein the data associated with the current order comprises at least one of:

the status data of the current order execution includes at least one of:

10. The system of claim 8, wherein the determination module is further configured to:

11. The system of claim 10, wherein the risk assessment model is obtained by:

acquiring a historical order;

12. The system of claim 8, wherein the female security risk determination includes a risk level of the current order;

the judging module is further configured to:

13. The system of claim 12, wherein the risk verification operation includes, but is not limited to, an automatic verification operation, or a telephonic interactive verification operation.

14. The system of claim 12, wherein the execution module is further to:

the at least one risk handling operation includes at least one of:

notifying the emergency contact;

starting monitoring equipment in the vehicle;

and contacting service providers around the user terminal for assistance.

15. A female safety risk prevention device comprising a processor, wherein the processor is configured to perform the female safety risk prevention method of any one of claims 1 to 7.

16. A computer-readable storage medium storing computer instructions, wherein when the computer instructions in the storage medium are read by a computer, the computer executes the method for preventing female security risk according to any one of claims 1 to 7.