CN117333268A

CN117333268A - Shared service user data processing method and device

Info

Publication number: CN117333268A
Application number: CN202311443292.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: 2018-11-27
Filing date: 2018-11-27
Publication date: 2024-01-02
Also published as: CN111222937A; CN111222937B

Abstract

The application provides a sharing service user data processing method, a device, electronic equipment and a storage medium, wherein the method comprises the following steps: receiving shielding request information input by a service requester, wherein the shielding request information is used for requesting that the service is not shared with a target sharing service party any more; according to the shielding request information, a shielding indication message is sent to a server, wherein the shielding indication message comprises: an identification of the service requester, an identification of the target sharing service provider. According to the method and the device, the shielding request information input by the service request party is obtained, and the shielding indication information is sent to the server according to the shielding request information, so that the server shields the target sharing service party which requests shielding by the service request party through the received shielding indication information. The method and the device realize the shielding indication information acquisition according to the shielding request information input by the service request party, so that the target sharing service party is shielded, and the experience comfort of a user when using the sharing service is effectively improved.

Description

Shared service user data processing method and device

The application is a divisional application of Chinese invention patent application with application date of 2018, 11, 27 and application number of 201811429204.1, named as a shared service user data processing method, a device, an electronic device and a storage medium.

Technical Field

The present invention relates to the field of screening technologies, and in particular, to a method and apparatus for processing shared service user data, an electronic device, and a storage medium.

Background

With the rapid development of the internet industry, the sharing economy taking the internet as a medium gradually takes up an extremely important position in the daily life of people, and great convenience is brought to the daily life of people by realizing the sharing service.

At present, under the economic sharing mode, sharing services relate to a plurality of fields such as transportation, house renting, logistics express delivery, life services and the like. For example, people can choose to share the service with other people when the traffic goes out, so that the problem of difficulty in driving is solved, the travel concept is changed, the traffic jam can be relieved, and energy conservation and emission reduction are realized. In addition, people can select to spell with other people to realize more economical and cost-effective service forms and the like during dining and shopping.

However, as the sharing service is more and more popular, there are more and more problems that users of the sharing service are not satisfied or contradicted with each other, resulting in poor use experience of users of the sharing service, and for the above problems, there is no effective way to solve the problem in the prior art.

Disclosure of Invention

In view of this, an object of the embodiments of the present application is to provide a method, an apparatus, an electronic device, and a storage medium for processing shared service user data, which can receive, by a terminal, shielding request information sent by a service requester, and send a shielding indication message to a server according to the shielding request information, so that the server shields a target shared service, solve a problem of poor shared service experience in the prior art, and achieve an effect of improving user shared service experience.

In a first aspect, an embodiment of the present application provides a method for processing shared service user data, including:

receiving shielding request information input by a service requester, wherein the shielding request information is used for requesting that the service is not shared with a target sharing service party any more; according to the shielding request information, a shielding indication message is sent to a server, wherein the shielding indication message comprises: an identification of the service requester, an identification of the target sharing service provider.

Optionally, receiving the mask request information input by the service requester includes:

if a plurality of selectable sharing service parties exist, displaying a selectable sharing service party selection interface, wherein the selectable sharing service party is a user sharing the same service with the service request party; and receiving each piece of selection information sequentially input by the service requester through the selectable sharing service party selection interface, wherein each piece of selection information is used for indicating a target sharing service party.

Optionally, after receiving each piece of selection information sequentially input by the service requester through the selectable shared service provider selection interface, the method includes:

judging whether the number of the shared service sides shielded by the service request side currently reaches a preset threshold value or not; if yes, determining that shielding fails; if not, the selection information is determined to be valid.

Optionally, the optional sharing service party selection interface includes: the identity of the optional shared service party, and the characteristic information of each optional shared service party.

Optionally, the characteristic information includes one or more of: joining service time information, joining service location information, joining service order information, exiting service time information, exiting service location information, exiting service order information.

Optionally, if there is a single optional shared service party, after receiving the shielding request information input by the service request party, the method further includes:

judging whether the number of the shared service sides shielded by the service request side currently reaches a preset threshold value or not; if yes, determining that shielding fails; and if not, determining that the shielding request information is valid.

Optionally, before sending the mask indication message to the server according to the mask request information, the method further includes:

Displaying a shielding confirmation interface; and receiving confirmation shielding information input by the service requester through a confirmation interface.

Optionally, after sending the mask indication message to the server according to the mask request information, the method further includes: receiving a query request input by a service requester, wherein the query request is used for requesting to query the shielding progress of a target sharing service provider; according to the query request, sending progress query information to the server, wherein the progress query information comprises: an identification of the service requester and an identification of the target sharing service provider; and receiving a query result sent by the server according to the progress query information.

Optionally, after receiving the mask request information input by the service requester, the method further includes:

judging whether the shielding request information meets a preset shielding condition or not, wherein the preset shielding condition comprises one or more of the following: the target sharing service party is not a proxy requesting service party, and the target sharing service party is not a screened user of the service requesting party.

Optionally, after receiving the mask request information input by the service requester, the method further includes: the target sharing service side is written into the mask list.

Optionally, the method further comprises: receiving shielding revocation request information input by a service requester, wherein the shielding revocation request information is used for requesting to restore the shared service with a target shared service party; according to the mask revocation request information, a mask revocation message is sent to the server, the mask revocation message including: an identification of the service requester, an identification of the target sharing service provider.

In a second aspect, an embodiment of the present application provides a method for processing shared service user data, including:

receiving a shielding indication message sent by a service requester terminal, wherein the shielding indication message is used for requesting that the service is not shared with a target sharing service party any more, and the shielding indication message comprises: an identification of the service requester and an identification of the target sharing service provider; and marking the target sharing service party as a shielding user of the service request party according to the shielding indication message.

Optionally, the method further comprises:

receiving a service request sent by a service requester terminal, wherein the service request is used for requesting sharing service; according to a preset algorithm, at least one sharable service to be selected of the service requesting party is obtained; acquiring sharable candidate services of a shielding user without a service requester; the target service of the service requester is selected from sharable candidate services of the masked user of the non-existence service requester.

Optionally, the method further comprises:

receiving a service request sent by a service requester terminal, wherein the service request is used for requesting sharing service; determining a target service of a service request party, wherein the target service does not currently exist a shared service party; one or more current sharing service parties are selected from the selectable sharing service parties, wherein the current sharing service party is not a screening user of the service requester.

Optionally, the method further comprises:

receiving progress query information sent by a service requester terminal, wherein the progress query information is used for requesting to query the shielding progress of a target sharing service party; the progress query information includes: an identification of the service requester and an identification of the target sharing service provider; acquiring a query result according to the progress query information; and sending the query result to the service requester terminal.

Optionally, the method further comprises:

receiving a shielding cancellation message sent by a service request side terminal, wherein the shielding cancellation message is used for requesting to restore the shared service with a target shared service side; the mask revocation message comprises: an identification of the service requester, an identification of the target sharing service provider.

In a third aspect, an embodiment of the present application provides a shared service user data processing apparatus, including: the device comprises an acquisition module and a sending module;

the acquisition module is used for receiving shielding request information input by the service request party, wherein the shielding request information is used for requesting that the service is not shared with the target sharing service party any more; the sending module is used for sending a shielding indication message to the server according to the shielding request information, wherein the shielding indication message comprises: an identification of the service requester, an identification of the target sharing service provider.

Optionally, the acquiring module is specifically configured to display a selectable shared service party selection interface if there are multiple selectable shared service parties, where the selectable shared service parties are users sharing the same service with the service requester; and receiving each piece of selection information which is sequentially input by the service requester through the selectable sharing service party interface, wherein each piece of selection information is used for indicating a target sharing service party.

Optionally, the apparatus further comprises a decision module; the judging module is used for judging whether the number of the shared service sides shielded by the service request side at present reaches a preset threshold value or not; if yes, determining that shielding fails; if not, the selection information is determined to be valid.

Optionally, the apparatus further comprises a decision module;

the judging module is further used for judging whether the number of the sharing service sides shielded by the service request side currently reaches a preset threshold value or not if a single selectable sharing service side exists; if yes, determining that shielding fails; and if not, determining that the shielding request information is valid.

Optionally, the device further comprises a display module; the display module is used for displaying a shielding confirmation interface; the acquisition module is also used for receiving the confirmation shielding information input by the service request party through the confirmation interface.

Optionally, the acquiring module is further configured to receive a query request input by the service requester, where the query request is used to request to query the shielding progress of the target sharing service provider; the sending module is further configured to send progress query information to the server according to the query request, where the progress query information includes: an identification of the service requester and an identification of the target sharing service provider; the acquisition module is also used for receiving the query result sent by the server according to the progress query information.

Optionally, the apparatus further comprises a decision module; the judging module is used for judging whether the shielding request information meets the preset shielding conditions or not, wherein the preset shielding conditions comprise one or more of the following: the target sharing service side non-proxy requesting service side and the target sharing service side non-service requesting side shield the user.

Optionally, the apparatus further comprises an adding module; and the adding module is used for writing the target sharing service side into the shielding list.

Optionally, the acquiring module is further configured to receive mask revocation request information input by the service requester, where the mask revocation request information is used to request to restore the service shared with the target sharing service provider; the sending module is further configured to send a shield revocation message to the server according to the shield revocation request information, where the shield revocation message includes: an identification of the service requester, an identification of the target sharing service provider.

In a fourth aspect, an embodiment of the present application provides a shared service user data processing apparatus, including: a receiving module and a marking module; the receiving module is configured to receive a mask indication message sent by a service requester terminal, where the mask indication message is used to request that a service is no longer shared with a target sharing service party, and the mask indication message includes: an identification of the service requester and an identification of the target sharing service provider; and the marking module is used for marking the target sharing service party as a shielding user of the service request party according to the shielding indication message.

Optionally, the method further comprises: the service acquisition module and the determination module; the receiving module is specifically used for receiving a service request sent by the service requester terminal, wherein the service request is used for requesting sharing service; the service acquisition module is used for acquiring at least one sharable service to be selected of the service requesting party according to a preset algorithm; acquiring sharable candidate services of a shielding user without a service requester; and the determining module is used for selecting the target service of the service requester from sharable candidate services of the shielding user of the non-existence service requester.

Optionally, the system further comprises a determining module, a receiving module and a receiving module, wherein the receiving module is further used for receiving a service request sent by the service requester terminal, and the service request is used for requesting sharing service; the determining module is also used for determining target service of the service request party, wherein the target service does not currently exist in the shared service party; one or more current sharing service parties are selected from the selectable sharing service parties, wherein the current sharing service party is not a screening user of the service requester.

Optionally, the system further comprises a data transmission module; the receiving module is also used for receiving progress query information sent by the service request party terminal, wherein the progress query information is used for requesting to query the shielding progress of the target sharing service party; the progress query information includes: an identification of the service requester and an identification of the target sharing service provider; the data sending module is used for obtaining a query result according to the progress query information; and sending the query result to the service requester terminal.

Optionally, the receiving module is further configured to receive a mask revocation message sent by the service requester terminal, where the mask revocation message is used to request to restore the service shared with the target sharing service party; the mask revocation message comprises: an identification of the service requester, an identification of the target sharing service provider.

In a fifth aspect, embodiments of the present application provide an electronic device, including: a processor, a storage medium, and a bus, the storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating over the bus when the electronic device is operating, the processor executing the machine-readable instructions to perform the steps of the shared services user data processing method as provided in the first or second aspect when executed.

In a sixth aspect, embodiments of the present application provide a storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the shared services user data processing method as provided in the first or second aspect.

According to the method and the device, the shielding request information input by the service request party is obtained, and the shielding indication information is sent to the server according to the shielding request information, so that the server shields the target sharing service party which requests shielding by the service request party through the received shielding indication information. The method and the device realize that the shielding indication information is acquired according to the shielding request information input by the service request party, so that the target sharing service party is shielded.

Drawings

The above and other objects, features and advantages of the present invention will become more apparent from the following description of embodiments of the present invention with reference to the accompanying drawings, in which:

FIG. 1 is a block diagram of a shared services user data processing system according to some embodiments of the present application;

FIG. 2 illustrates a schematic diagram of exemplary hardware and software components of an electronic device in accordance with some embodiments of the present application;

fig. 3 is a schematic flow chart of a method for processing shared service user data according to an embodiment of the present application;

FIG. 4 is a flowchart illustrating another method for processing shared service user data according to an embodiment of the present application;

FIG. 5 is a flowchart illustrating another method for processing shared service user data according to an embodiment of the present application;

FIG. 6 is a flowchart illustrating another method for processing shared service user data according to an embodiment of the present application;

fig. 7 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application;

fig. 8 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application;

fig. 9 is a schematic flow chart of a method for processing shared service user data according to an embodiment of the present application;

fig. 10 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application;

FIG. 11 is a flowchart illustrating another method for processing shared service user data according to an embodiment of the present application;

FIG. 12 is a flowchart of another method for processing shared service user data according to an embodiment of the present application;

fig. 13 is a schematic flow chart of a method for processing shared service user data according to an embodiment of the present application;

Fig. 14 is an interface schematic diagram in a shared service user data processing method according to an embodiment of the present application;

FIG. 15 is a schematic diagram of an interface in another method for processing shared service user data according to an embodiment of the present application;

FIG. 16 is a schematic diagram of an interface in another method for processing shared service user data according to an embodiment of the present application;

FIG. 17 is a schematic diagram of an interface in another method for processing shared service user data according to an embodiment of the present application;

FIG. 18 is a schematic diagram of an interface in another method for processing shared service user data according to an embodiment of the present application;

FIG. 19 is a schematic diagram of an interface in another method for processing shared service user data according to an embodiment of the present application;

FIG. 20 is a schematic diagram of a shared service user data processing apparatus according to an embodiment of the present application;

FIG. 21 is a schematic diagram of another shared service user data processing apparatus according to an embodiment of the present application;

FIG. 22 is a schematic diagram of another shared service user data processing apparatus according to an embodiment of the present application;

FIG. 23 is a schematic diagram of another shared service user data processing apparatus according to an embodiment of the present application;

FIG. 24 is a schematic diagram of a shared service user data processing apparatus according to an embodiment of the present application;

FIG. 25 is a schematic diagram of another shared service user data processing apparatus according to an embodiment of the present application;

FIG. 26 is a schematic diagram of another shared service user data processing apparatus according to an embodiment of the present application;

fig. 27 is a schematic structural diagram of another shared service user data processing apparatus according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it should be understood that the accompanying drawings in the present application are only for the purpose of illustration and description, and are not intended to limit the protection scope of the present application. In addition, it should be understood that the schematic drawings are not drawn to scale. A flowchart, as used in this application, illustrates operations implemented according to some embodiments of the present application. It should be understood that the operations of the flow diagrams may be implemented out of order and that steps without logical context may be performed in reverse order or concurrently. Moreover, one or more other operations may be added to the flow diagrams and one or more operations may be removed from the flow diagrams as directed by those skilled in the art.

In addition, the described embodiments are only some, but not all, of the embodiments of the present application. The components of the embodiments of the present application, which are generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, as provided in the accompanying drawings, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, are intended to be within the scope of the present application.

In order to enable one skilled in the art to use the present disclosure, the following embodiments are presented in connection with a specific application scenario "carpool service". It will be apparent to those having ordinary skill in the art that the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present application. Although the present application is primarily described in the context of a ride share, it should be understood that this is but one exemplary embodiment. The present application may be applied to any other scenario. For example, the application can be applied to sharing services such as house renting, group shopping, order takeaway and the like.

It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the presence of the features stated hereinafter, but not to exclude the addition of other features.

The terms "service requestor" and "target sharing service" are used interchangeably herein, a service requestor referring to a person, entity, or tool that may request shielding of a target user, and a target sharing service referring to a shielded person, entity, or tool. The service requester may be a passenger, driver, store, takeaway rider, etc., or any combination thereof.

FIG. 1 is a block diagram of a shared services user data processing system according to some embodiments of the present application. For example, the shared services user data processing system may be an internet service platform or the like for providing shared services such as carpooling, order takeaway, shopping, rental housing, and the like.

The shared services user data processing system may include one or more of a server 110, a network 120, a service requester terminal 130, a target shared service provider terminal 140, and a database 150, and a processor executing instruction operations may be included in the server 110.

In some embodiments, the server 110 may be a single server or a group of servers. The server farm may be centralized or distributed (e.g., server 110 may be a distributed system). In some embodiments, the server 110 may be local or remote to the terminal. For example, server 110 may access information and/or data stored in service requester terminal 130, target shared service provider terminal 140, or database 150, or any combination thereof, via network 120. As another example, the server 110 may be directly connected to at least one of the service requester terminal 130, the target sharing service provider terminal 140, and the database 150 to access stored information and/or data. In some embodiments, server 110 may be implemented on a cloud platform; for example only, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud (community cloud), distributed cloud, inter-cloud (inter-cloud), multi-cloud (multi-cloud), and the like, or any combination thereof. In some embodiments, server 110 may be implemented on an electronic device 200 having one or more of the components shown in fig. 2 herein.

In some embodiments, server 110 may include a processor. The processor may process information and/or data related to the service request to perform one or more functions described herein. For example, the processor may determine the target sharing service party based on a service request obtained from the service requester terminal 130. In some embodiments, a processor may include one or more processing cores (e.g., a single core processor (S) or a multi-core processor (S)). By way of example only, the Processor may include a central processing unit (Central Processing Unit, CPU), application specific integrated circuit (Application Specific Integrated Circuit, ASIC), special instruction set Processor (Application Specific Instruction-set Processor, ASIP), graphics processing unit (Graphics Processing Unit, GPU), physical processing unit (Physics Processing Unit, PPU), digital signal Processor (Digital Signal Processor, DSP), field programmable gate array (Field Programmable Gate Array, FPGA), programmable logic device (Programmable Logic Device, PLD), controller, microcontroller unit, reduced instruction set computer (Reduced Instruction Set Computing, RISC), microprocessor, or the like, or any combination thereof.

Network 120 may be used for the exchange of information and/or data. In some embodiments, one or more components in the shared services user data processing system (e.g., server 110, service requester terminal 130, target shared service provider terminal 140, and database 150) may send information and/or data to other components. For example, the server 110 may obtain a service request from the service requester terminal 130 via the network 120. In some embodiments, network 120 may be any type of wired or wireless network, or a combination thereof. By way of example only, the network 130 may include a wired network, a wireless network, a fiber optic network, a telecommunications network, an intranet, the internet, a local area network (Local Area Network, LAN), a wide area network (Wide Area Network, WAN), a wireless local area network (Wireless Local Area Networks, WLAN), a metropolitan area network (Metropolitan Area Network, MAN), a wide area network (Wide Area Network, WAN), a public switched telephone network (Public Switched Telephone Network, PSTN), a bluetooth network, a ZigBee network, a near field communication (Near Field Communication, NFC) network, or the like, or any combination thereof. In some embodiments, network 120 may include one or more network access points. For example, network 120 may include wired or wireless network access points, such as base stations and/or network switching nodes, through which one or more components of a shared services user data processing system may connect to network 120 to exchange data and/or information.

In some embodiments, the user of the target shared servicer terminal 140 may be a person other than the actual desirer of the service. For example, user a of the target shared servicer terminal 140 may use the target shared servicer terminal 140 to initiate a service request for the service actual requester B (e.g., user a may call his own friend B), or receive service information or instructions from the server 110, or the like. In some embodiments, "service requester terminal" and "target shared service provider terminal" may be used interchangeably.

Database 150 may store data and/or instructions. In some embodiments, database 150 may store data obtained from service requester terminal 130 and/or target shared servicer terminal 140. In some embodiments, database 150 may store data and/or instructions for the exemplary methods described in this application. In some embodiments, database 150 may include mass storage, removable storage, volatile Read-write Memory, or Read-Only Memory (ROM), or the like, or any combination thereof. By way of example, mass storage may include magnetic disks, optical disks, solid state drives, and the like; removable memory may include flash drives, floppy disks, optical disks, memory cards, zip disks, magnetic tape, and the like; the volatile read-write memory may include random access memory (Random Access Memory, RAM); the RAM may include dynamic RAM (Dynamic Random Access Memory, DRAM), double data Rate Synchronous dynamic RAM (DDR SDRAM); static Random-Access Memory (SRAM), thyristor RAM (T-RAM) and Zero-capacitor RAM (Zero-RAM), etc. By way of example, ROM may include Mask Read-Only Memory (MROM), programmable ROM (Programmable Read-Only Memory, PROM), erasable programmable ROM (Programmable Erasable Read-Only Memory, PEROM), electrically erasable programmable ROM (Electrically Erasable Programmable Read Only Memory, EEPROM), compact disk ROM (CD-ROM), digital versatile disk ROM, and the like. In some embodiments, database 150 may be implemented on a cloud platform. For example only, the cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, cross-cloud, multi-cloud, or other similar, or the like, or any combination thereof.

In some embodiments, database 150 may be connected to network 120 to communicate with one or more components in a shared services user data processing system (e.g., server 110, service requester terminal 130, target shared service provider terminal 140, etc.). One or more components in the shared services user data processing system may access data or instructions stored in database 150 via network 120. In some embodiments, database 150 may be directly connected to one or more components in the shared services user data processing system (e.g., server 110, service requester terminal 130, target shared service provider terminal 140, etc.); alternatively, in some embodiments, database 150 may also be part of server 110.

Fig. 2 shows a schematic diagram of exemplary hardware and software components of an electronic device according to some embodiments of the present application.

For example, a processor may be used on the electronic device 200 and to perform the functions herein.

The electronic device 200 may be a general purpose computer or a special purpose computer, both of which may be used to implement the service location acquisition methods of the present application. Although only one computer is shown, the functionality described herein may be implemented in a distributed fashion across multiple similar platforms for convenience to balance processing loads.

For example, the electronic device 200 may include a network port 210 connected to a network, one or more processors 220 for executing program instructions, a communication bus 230, and various forms of storage media 240, such as magnetic disk, ROM, or RAM, or any combination thereof. By way of example, the computer platform may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The methods of the present application may be implemented in accordance with these program instructions. The electronic device 200 also includes an Input/Output (I/O) interface 250 between the computer and other Input/Output devices (e.g., keyboard, display screen).

For ease of illustration, only one processor is depicted in the electronic device 200. It should be noted, however, that the electronic device 200 in the present application may also include multiple processors, and thus steps performed by one processor described in the present application may also be performed jointly by multiple processors or separately. For example, if the processor of the electronic device 200 performs steps a and B, it should be understood that steps a and B may also be performed by two different processors together or performed separately in one processor. For example, the first processor performs step a, the second processor performs step B, or the first processor and the second processor together perform steps a and B.

For simplicity of explanation, the embodiment of the present application is merely an illustration of a method for providing sharing service user data processing for a user by using an application program of a carpooling service, and in practical application, the embodiment of the present application is not limited to this.

Fig. 3 is a schematic flow chart of a method for processing shared service user data according to an embodiment of the present application, where an execution body of the embodiment may be a service requester terminal, as shown in fig. 3, and the method for processing shared service user data provided in the present application includes:

s101, receiving shielding request information input by a service requester, wherein the shielding request information is used for requesting that the service is not shared with a target sharing service party any more.

Alternatively, the service requester may input the shielding request information through an input device of the terminal, and the input device may be a touch display screen or a keyboard input. The mask request information is used to indicate that the target sharing service party is masked, and may also be denoted as "black out".

When a plurality of users share the same service, because of contradiction and conflict possibly occurring among the plurality of users due to various reasons (such as character mismatch, etc.), the user experience is poor, the target sharing service party is shielded through the shielding request information input by the received service request party, and after the background server records, the service request party and the shielded target sharing service party are not matched any more to share the service, thereby reducing the probability of occurrence of conflict and better improving the user experience.

For example: the service request party and the target sharing service party commonly use the same service, and the target sharing service party is not friendly to the service request party in the service using process, so that the service request party generates a certain dissatisfaction, and after the sharing service is finished, the service request party can select one or more target sharing service parties to be shielded through an application program on the terminal.

S102, sending a shielding indication message to the server according to the shielding request information.

The mask indication message may include: the identification of the service request party and the identification of the target sharing service party are used for recording the identification of the service request party by the server.

After receiving the shielding request information, the terminal sends a corresponding shielding indication message to the server according to the information indicated by the shielding request, so that the server records a target sharing service party shielded by the service requester according to the shielding indication message.

Alternatively, the identity of both the service requester and the target sharing service may employ a user account (the user may be obtained by registering with the application); or a user identity attribute, such as: encoding the terminal equipment of the user; or the time, place, etc. at which the user shared the service. The identity corresponding to the user may be different for different shared service types. The identity of the service requester may be unique to the same application, facilitating management by the server.

The server may maintain a corresponding database for each user that may be indexed by the identity of the user (e.g., the identity of the service requester) in which the identities of other users masked by the user are recorded. After receiving the shielding indication message, searching a database of the service request party, and adding the identification of the target sharing service party into the database. Alternatively, the database may be in a table format, but is not limited thereto.

According to the shared service user data processing method, the shielding indication information is sent to the server through the input shielding request information, so that the server can make shielding processing on a request for shielding a specific target shared service party sent by the service request party according to the shielding indication information, and the fact that the same service is not matched with the shielded target shared service party for the service request party in future shared service is achieved, and the experience of enjoying the service by the user is improved.

Fig. 4 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application. For a scenario with multiple optional sharing service parties, as shown in fig. 4, the receiving the mask request information input by the service requester may include:

S201, if a plurality of selectable sharing service parties exist, displaying a selectable sharing service party selection interface.

The selectable sharing service party is a user sharing the same service with the service request party, namely, can be a selectable object of the service request party selection shielding.

In the one-time sharing service, there may be a plurality of sharing service parties, for example: there are cases where 3 users share services together, that is, there may be a first sharing service party, a second sharing service party, a third sharing service party, etc., and of course, one user account may correspond to one or more objects actually enjoying services.

When one or more sharing service sides are shielded, the selection needs to be performed in the illustrated selectable sharing service side selection interface according to the need, the first sharing service side needs to be shielded, the first sharing service side is selected, the first sharing service side and the second sharing service side need to be shielded, and the first sharing service side and the second sharing service side are selected at the same time, which is not an example.

S202, receiving each piece of selection information sequentially input by a service requester through an optional sharing service party selection interface, wherein each piece of selection information is used for indicating a target sharing service party.

When a plurality of target sharing service parties need to be selected, selection information corresponding to the plurality of target sharing service parties needs to be sequentially input. For example, a plurality of selectable sharing service parties are displayed in a list form, each selectable sharing service party corresponds to a check box, and when the first sharing service party needs to be selected for shielding, the check box corresponding to the first sharing service party can be selected through a touch screen or a selection key, or an image identifier or a text identifier of the first sharing service party can be directly clicked to select.

In order to avoid that individual users maliciously shield other users, the distribution efficiency of the shared service is low, the number of other users shielded by each user can be set, that is, a preset threshold can be set, and the number of users shielded by each user cannot be larger than the preset threshold.

The user can trigger a shielding request after inputting the selection information each time, namely, the shielding of the selected target sharing service party is requested.

Fig. 5 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application, and after receiving each piece of selection information sequentially input by a service requester through an optional shared service provider selection interface, as shown in fig. 5, the method may further include:

S301, judging whether the number of the sharing service sides shielded by the service request side currently reaches a preset threshold value.

It should be noted that, if the shared service application program sets the preset threshold, when the masking preset threshold is reached, the user cannot continue the masking operation.

S302, if the shielding failure is met, determining that the shielding fails.

And S303, if the selection information is not reached, determining that the selection information is valid.

For example: in this embodiment, the preset threshold may be 50, and the number of currently shielded shared service parties of the service requester is 49, at this time, when one shared service party is selected and shielded, since the total number of shielding people does not reach the preset threshold, the input selection information is valid here, that is, the service requester may shield the selected shared service party, and when another shared service party needs to be shielded again, the shielding of another shared service party will fail because the total number of shielding people reaches the preset threshold.

That is, the terminal determines whether the shared service party shielded by the service requester reaches a preset threshold after receiving a selection message (the user selects a target shared service party each time), when there are a plurality of selectable shared service parties, if the service requester shields the plurality of target shared service parties, during the process of selecting a target shared service party, if the currently shielded shared service party reaches the preset threshold after selecting a certain target shared service party, the remaining selectable shared service parties cannot be selected, that is, cannot be shielded.

Further, the optional sharing service side selection interface includes: the identity of the optional shared service party, and the characteristic information of each optional shared service party.

It should be noted that, the identifier of the sharing service party may be encoded for a terminal device used by the sharing service party, or a registration account number (for example, a user ID) of the sharing service party, etc., where the identifier is used to indicate identity information of each optional sharing service party. The feature information of the optional sharing service party is feature information capable of distinguishing different users, for example, the feature information of each optional sharing service party can be the time, place and the like of joining the sharing service for the sharing service party, wherein the identification and the feature information of each optional sharing service party are unique, so that the service requester can be helped to confirm each sharing service party to accurately select.

Further, the characteristic information includes one or more of the following: joining service time information, joining service location information, joining service order information, exiting service time information, exiting service location information, exiting service order information.

It should be noted that, the service requester may perform comprehensive analysis according to the one or more pieces of information, and select a target sharing service provider that needs to be shielded.

Taking the "carpooling" scenario as an example, the feature information of the optional sharing service party may include: the service side boarding places and orders are shared. Firstly, preliminary selection is carried out according to the boarding places, and secondly, selection is carried out through the boarding sequence. Taking three users to spell a car together as an example: if the service requester gets on the first bus, the feature information of the shared service provider that can be displayed at the corresponding position of the shared service provider identifier of the first bus after the service requester is "get on 1 (2) th bus after me (referring to the service requester). If the service requester gets on the vehicle for the second time, the shared service provider identifier corresponding to the vehicle before the service requester may display the characteristic information of the shared service provider as "get on the vehicle before me". If the service requester gets on the bus in the third mode, the feature information of the sharing service provider can be displayed according to the getting-off sequence of the sharing service provider, for example, if the service requester gets off the bus in the second mode, the feature information of the sharing service provider, which can be displayed at the corresponding position of the shared service provider identifier that gets off the bus before the service requester, can be "get off before me"; if the service requester gets off the vehicle third, the feature information of the sharing service provider displayed if the corresponding position of the sharing service provider identifier of the 2 nd getting off before the service requester can be "get off the vehicle 2 nd before me". Of course, not limited to the above example, different feature information may be set according to actual situations to prompt, for example, display "get off at xx site" or the like.

By sharing the characteristic information of the service party, the service request party can quickly and accurately select the object to be shielded, so that the selected target object is shielded.

Further, if there is a single optional shared service party, after receiving the mask request information input by the service request party, the method further includes:

and judging whether the number of the shared service sides which are shielded by the service request side currently reaches a preset threshold value or not. If so, determining that the shielding fails. If not, the shielding request information is determined to be valid.

It should be noted that in some cases, there may be only 1 sharing service party, that is, there is only another sharing service party except the service requester, where the selection of the target sharing service party may not be performed through multiple selectable sharing service party display interfaces, but the selection of the target sharing service party may be performed directly. Or, without providing a selection interface, when the user selects to enter the shielding function, the target sharing service side is directly displayed to be selected, namely, the shielding request is triggered, the user only needs to further confirm, for example, a confirmation selection frame is displayed on the interface, the user can select through the terminal, and if the confirmation selection frame is selected, the terminal receives the shielding request information aiming at the target sharing service side.

Optionally, the process of determining whether the number of shared service providers currently shielded by the service requester reaches the preset threshold is the same as that in steps S301, S302, and S303, and will not be described in detail here.

Fig. 6 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application, where, as shown in fig. 6, before sending a mask indication message to a server according to mask request information, the method further includes:

s401, displaying a shielding confirmation interface.

S402, receiving confirmation shielding information input by the service requester through the confirmation interface.

In order to avoid misoperation of the user, the terminal receives the target sharing service party to be shielded selected by the service request party through the method, after the target sharing service party to be shielded is selected, the terminal displays a shielding confirmation interface for confirmation of the service request party, after confirmation, shielding operation is completed, and if the target sharing service party to be shielded is selected, and the shielding operation is not confirmed, the shielding operation is defaulted.

Optionally, the shielding confirmation interface may include a "confirmation" selection box, and the confirmation operation may be performed by touching a corresponding key or a key of the operation terminal.

Optionally, a secondary confirmation interface may be displayed, after receiving confirmation shielding information input by the service requester, the control interface jumps to the secondary confirmation interface, and a "confirmation" selection frame may be displayed on the secondary confirmation interface, so that confirmation operation may be performed by touching a corresponding key or a key of the operation terminal. After the service requester performs confirmation operation by touching the corresponding key or operating the key of the terminal, the terminal receives the secondary confirmation shielding information, namely the final confirmation is completed, and the target sharing user is recorded as the shielded user.

It should be noted that, setting the secondary acknowledgement can make the service requester have a reconsidered opportunity, so as to avoid a moment impulse or a wrong selection of the service requester. Optionally, the number of confirmation operations is not limited to two, so that the confirmation operations can be set according to actual situations, so as to realize a better user experience premise.

Fig. 7 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application, where, as shown in fig. 7, after sending a mask indication message to a server according to mask request information, the method further includes:

s501, receiving a query request input by a service requester, wherein the query request is used for requesting to query the shielding progress of a target sharing service provider.

It should be noted that, after the shielding is completed, the service requester may further check a specific shielding progress of the target sharing service provider by inputting a corresponding query request, for example: during the masking process, masking is complete, etc.

S502, sending progress query information to a server according to a query request, wherein the progress query information comprises: an identification of the service requester, an identification of the target sharing service provider.

S503, receiving the query result sent by the server according to the progress query information.

Optionally, the terminal sends progress query information to the server, and the server queries the target progress according to the progress query information and returns a query result to the terminal, so that a service requester can check conveniently and know whether the shielding is effective or not in time.

After receiving the shielding request information, the server records the shielding progress of the service requester on the target sharing service provider, if the identification of the target sharing service provider is not written into the shielding user database corresponding to the service requester at present, the server can feed back "in progress", and if the identification of the target sharing service provider is written into the shielding user database corresponding to the service requester, the server can feed back "completed".

Further, after receiving the mask request information input by the service requester, the method further includes:

judging whether the shielding request information meets the preset shielding condition.

Wherein the preset shielding conditions include one or more of the following: the target sharing service side non-proxy requesting service side and the target sharing service side non-service requesting side shield the user.

It should be noted that, not all the shielding requests satisfy the shielding condition, and when some of the following cases occur, the shielding will not satisfy the shielding condition, and the target object cannot be shielded. For example: when the target sharing service party is a proxy request service party, that is, the target sharing service party is a user for helping other people to call the vehicle, the user does not use the sharing service by himself, thus, the person to be shielded by the service request party is not the target sharing service party, but the people who take the vehicle together, and the proxy request service party can be shielded in order to avoid injuring innocent users by mistake.

Alternatively, the target shared service has been a user masked by the service requester. In an alternative implementation manner, when the user is shielded, the shielding operation can be performed on the user evaluation interface or the service complaint interface after the service is completed. Assuming that the target sharing service party is selected to be shielded in the user evaluation interface, the target sharing service party cannot be shielded again in the service complaint interface; or when the target sharing service party is shielded at the service complaint interface, the user evaluation interface cannot be shielded again.

In addition, when the system server fails, a situation that the target sharing service party is not selected may occur, and the shielding failure may also be caused. When the mask information satisfies a preset mask condition, the masking operation may be continued.

the target sharing service side is written into the mask list.

It should be noted that, the target sharing service side is written into the shielding list, so that the user can conveniently check the shielded user at any time, and the user can conveniently manage the shielded user in the list.

For example, after the terminal installs the application program, the user can check the shielded user in the shielding list only by logging in the account of the user. The masked list may display the identities of the users that have been masked, such as the user's account numbers, nicknames, avatars, and the like.

Optionally, the mask list may include: the list of the shielded shared service party, the list of the shielded service party, etc. can also be a user-defined list, and the method is not limited in particular. I.e. a plurality of different types of mask lists may be maintained simultaneously. In particular implementations, the terminal may provide a mask list under which the sub-lists are subdivided, different sub-lists storing different types of users that are masked, which sub-lists may be customized by the user. For example, the masked shared service side list is a sub-list for storing the masked shared service side in the above embodiment; in addition, the service provider may be masked, and the masked service provider list is also a sub-list, and the masked service provider may be stored.

For example: taking a car pooling as an example, the mask list may include: a masked driver list, a masked friend list; taking take as an example, the mask list may include: a masked store list, a masked rider list, etc.

Further, fig. 8 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application, and as shown in fig. 8, the method for processing shared service user data further includes:

S601, receiving shielding revocation request information input by a service requester, wherein the shielding revocation request information is used for requesting to restore the shared service with a target shared service party.

It should be noted that, the above-mentioned method sends a mask request indication to the server, so that the server masks the target sharing service side, and the mask is not permanently irrevocable. In this embodiment, the terminal may further receive mask revocation request information sent by the service requester, where the mask revocation request information is used to delete the masked user from the mask list, so that the service requester may share the same service with the target sharing service again.

Optionally, on the interface of the mask list, each masked user may have a "unmask" option for the service requester to select and confirm, and trigger to generate mask revocation request information for the target shared service provider after receiving the selection confirmation operation input by the service requester. Or the shielding list provides a deleting function, and when a user deletes a certain shielded target sharing service party through the shielding list of the terminal, the generation of shielding revocation request information aiming at the target sharing service party is triggered.

S602, according to the shielding revocation request information, a shielding revocation message is sent to a server, wherein the shielding revocation message comprises: an identification of the service requester, an identification of the target sharing service provider.

Optionally, the terminal sends a mask revocation message to the server according to the received mask revocation request information, and the server deletes the target sharing service party from the sharing service parties that have been masked by the service request party according to the mask revocation message, so that the service request party and the target sharing service party can share the service again in the process of matching the sharing service subsequently.

Alternatively, the server may delete the masked target shared servicer from the shared servicer that the service requester has masked after a preset period of time. For example, the preset time period may be 1 month, 4 months or 12 months, so that a certain service completion amount may be increased, and a situation that some service requesters may intentionally shield users for personal reasons, resulting in a loss of service quantity is avoided.

Fig. 9 is a schematic flow chart of a method for processing shared service user data, where an execution body of the method may be a background server of an application program.

As shown in fig. 9, the method for processing shared service user data includes:

s701, a shielding indication message sent by a service request party terminal is received.

The mask indication message is used for requesting that the service is no longer shared with the target sharing service party, and the mask indication message comprises: an identification of the service requester, an identification of the target sharing service provider.

Specifically, the server receives a shielding indication message sent by the service requester terminal, and shields the target sharing service party according to the shielding indication message, so that the target sharing service party can not share the service with the service requester.

S702, marking the target sharing service party as a shielding user of the service request party according to the shielding indication message.

Optionally, the server marks the target sharing service party requesting shielding by the service requester according to the received shielding indication message, so as to facilitate checking and not matching the same service with the target sharing service party for the service requester in the process of matching the sharing service later.

Alternatively, the marking method may be marking by creating a table, or may be setting a tag for the target sharing service side, and the marking method is not particularly limited herein.

In the alternative, the server may maintain a corresponding database for each user, which database may be indexed by the identity of the user (e.g., the identity of the service requester), with the identities of other users masked by the user being recorded in the database. After receiving the shielding indication message, searching a database of the service request party, and adding the identification of the target sharing service party into the database. Alternatively, the database may be in a table format, but is not limited thereto.

Further, fig. 10 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application, as shown in fig. 10, where the method further includes:

s801, a service request sent by a service requester terminal is received, wherein the service request is used for requesting sharing service.

S802, at least one sharable candidate service of the service requester is obtained according to a preset algorithm.

After receiving the service request, the server selects a service party capable of providing service for the service request party within a certain range. For example, matching is performed according to the time and place of the service requester. One or more service parties may meet service conditions in the matching process, namely, the service party may be used as a sharable candidate service.

Taking the service of calling a car as an example, there may be one or more drivers that can provide the service according to the time and place of the service requester.

S803, the sharable candidate service of the shielding user without the service requester is obtained.

Among the sharable candidate services, there may already be other users that determine to be served. Taking the example of a taxi service, the surrounding drivers who can provide the service may have pulled other users, i.e. the service requester may be treated as a friend-making order. It is necessary to check, among drivers who can provide services, whether or not there is a masked user of the service requester in the order that has been confirmed. Assuming that one of the drivers that can provide service has received a list of service users a and that the service requester B has shielded user a, the driver is screened during dispatch and the driver that can provide service to the service requester B is selected from the other drivers.

S804, selecting the target service of the service requester from sharable candidate services of the shielding user of the non-existence service requester.

It should be noted that, the server side has marked the target sharing service side selected by the service requester. So that the service requester will not be matched with the target shared service party into the same service when requesting the service again.

And selecting the target service of the service requester from the sharable candidate services of the shielding users without the service requester, namely screening the service of the shielding users without the service requester according to the service object confirmed by the sharable candidate service, and further selecting the target service. For example, a screening user of a service requester has called a vehicle to provide service, then the service requester is not assigned the vehicle ride.

That is, the server receives a service request from a service requester terminal and matches a shared service for it according to the service request. For the service request of the same service requester, the server can match a plurality of shared services for the service requester, so that the server needs to delete the shared service containing the shielded user of the service requester from the plurality of matchable shared services in order to not match the service requester with the shielded user of the service requester, and then match a better target service for the service requester from the rest of matchable shared services, thereby improving the user experience.

Assuming that the service requester sends a service request through the terminal, at this time, all the shared services satisfying the service request condition of the service requester have other shared service providers added to the service, the service requester is used as a non-first added shared server to send the service request, and the server deletes the service containing the shielded user of the service requester from all the shared services satisfying the condition and matches the service from the rest of the shared services.

Further, fig. 11 is a schematic flow chart of another method for processing shared service user data according to an embodiment of the present application, as shown in fig. 11, where the method further includes:

and S901, receiving a service request sent by a service requester terminal, wherein the service request is used for requesting sharing service.

S902, determining a target service of a service requester, wherein the target service does not exist in the sharing service.

S903, selecting one or more current sharing service parties from the selectable sharing service parties, wherein the current sharing service party is not a shielding user of the service request party.

In this embodiment, the service requester is taken as the first user to join the sharing service.

Optionally, the server matches the shared service for the service requester according to the received service request, and may also match the shared service for the service requester at this time, because the service requester is the first user to join the shared service, so as to perform the shared service.

The server may select users that may share the service according to conditions such as time and place, then determine whether there are users screened by the service requester among the users that may share the service, if so, delete the users, and then screen the sharing service providers that are matched among the remaining users to share the service together. Thereby ensuring that the service requester does not match the screening user of the service requester to the same service.

Further, fig. 12 is a flow chart illustrating another method for processing shared service user data according to an embodiment of the present application, as shown in fig. 12, where the method further includes:

s1101, receiving progress query information sent by a service requester terminal, wherein the progress query information is used for requesting to query the shielding progress of a target sharing service party; the progress query information includes: an identification of the service requester, an identification of the target sharing service provider.

S1102, acquiring a query result according to the progress query information.

And S1103, sending the query result to the service requester terminal.

Note that the method in this embodiment corresponds to steps S501, S502, and S503 described above. The server receives progress query information sent by the terminal, queries the shielding progress of the target sharing service party according to the progress query information, and returns a query result to the terminal for the service request party to check the result.

Further, the method further comprises:

It should be noted that, in the above method, the terminal sends the mask revocation message to the server, and correspondingly, in this embodiment, the server receives the mask revocation message sent by the terminal, and revokes the target sharing service party from the mask list according to the mask revocation message, so as to recover the right of sharing the service with the service requester.

Referring to fig. 13 to 25, fig. 13 is a schematic flow chart of a method for processing shared service user data provided in the embodiment of the present application, so that the technical solution of the method for processing shared service user data in the foregoing embodiment of the present application is more clear, and the present application is described herein by using an application example of the method for processing shared service user data in a carpool, and using a service requester terminal as an execution subject. Assuming that the first user is a service requesting party, the second, third and fourth users are optional target sharing service parties, and the preset threshold value of the number of users currently shielded by the first user is 50.

As shown in fig. 13, the specific steps of masking a target sharing service party by using the sharing service user data processing method are as follows:

s2101, receiving shielding request information input by a service requester.

The mask request information is used to request that services no longer be shared with the target sharing service.

S2102, judging whether shielding request information meets a preset shielding condition or not; if yes, step S2108 is executed, and if no, step S2103 is executed.

S2103, judging whether a plurality of optional sharing service parties exist.

And S2104, if yes, displaying an optional sharing service side selection interface.

Wherein the optional shared service party is a user sharing the same service as the service requester.

S2105, receiving each piece of selection information sequentially input by the service requester through the selectable sharing service party selection interface, wherein each piece of selection information is used for indicating a target sharing service party.

S2106, if not, the selection information is directly input.

Alternatively, an optional sharing service party may be directly displayed on the interface to be selected, without the user inputting selection information. Further, S2109 may be performed, or S2110 may be performed directly.

S2107, judging whether the number of the sharing service sides shielded by the service request side currently reaches a preset threshold value.

S2108, if the result is reached, determining that the shielding fails.

S2109, if not, determines that the selection information is valid.

S2110, displaying a shielding confirmation interface.

S2111, receiving confirmation shielding information input by the service requester through a confirmation interface.

S2112, a shielding indication message is sent to the server according to the shielding request information.

Wherein the mask indication message includes: an identification of the service requester, an identification of the target sharing service provider.

S2113, a query request input by the service requester is received, wherein the query request is used for requesting to query the shielding progress of the target sharing service provider.

S2114, sending progress query information to the server according to the query request.

Wherein the progress query information includes: an identification of the service requester, an identification of the target sharing service provider.

S2115, receiving the query result sent by the server according to the progress query information.

S2116, the target sharing service side is written into the shielding list.

The shared service user data processing method is divided into three major parts, namely: user screening, screening progress queries and list presentation.

Fig. 14 is a schematic diagram of an interface in a sharing service user data processing method provided in an embodiment of the present application, in which a user a and at least one of a user b, a user c, and a user d spell the same vehicle, and the user a is not satisfied with at least one of the user b, the user c, and the user d, hope not to spell the vehicle together later, and click to enter a shielding interface through a user shielding (black drawing) entry of the pooling software, that is, the user dissatisfied entry to the pooling friend in fig. 14.

Fig. 15 and fig. 16 respectively show an interface schematic diagram in another shared service user data processing method provided in the embodiment of the present application, where a terminal determines that a user b or c or t that a user a wants to shield is not a user, and is not a user that has been shielded by a user a through other shielding interfaces. After the determination, since the user A may only share the car with any one of the users B, C and T, the user A may share the car with two or even three of the users. When the user is spelled with only one user, for example, the user is spelled with the second user, the user is directly checked to add the user to the blacklist, whether the number of the users shielded by the first user reaches the upper limit 50 is required to be judged, if so, the upper limit of the shielding name is 50, and if so, a prompt that the number of the users reaches the upper limit is popped up, and at the moment, the user of the first user is displayed to fail to shield the second user; if the user does not reach the standard, clicking the submit button, confirming the shielding of the user according to the displayed confirmation prompt information, clicking the confirmed shielding, and completing the shielding operation.

Fig. 17 is a schematic diagram of an interface in another method for processing shared service user data according to the embodiment of the present application, when a user a spells a vehicle with a user b, a user c, and a user d at the same time, if the user a needs to mask any multiple users of the three users, then the user to be masked needs to be selected at the shared service side selection interface according to the user information. As shown in fig. 17, if the user a gets on the 1 st car, the user information of the shared service side selection interface includes: the 1 st get-on behind me (referring to user A) and the 2 nd get-on behind me, the user A clicks and selects one or more users needing shielding according to the self situation and the displayed user prompt information.

Optionally, if the user a gets on the vehicle 2 nd, the user information of the shared service side selection interface includes: get on the car in front of me, get on the car in back of me; if the user gets on 3 rd bus, three cases are included, and when the user gets on 3 rd bus and gets off 1 st bus, the user information of the service side selection interface includes: get on 1 st in front of me, get on 2 nd in front of me; when the user is the 3 rd get-on or the 2 nd get-off, the user information of the service side selection interface is shared and comprises: get off before me and get off after me; when the user is the 3 rd get-on or the 3 rd get-off, the user information of the service side selection interface is shared and comprises: get off 1 st in front of me and get off 2 nd in front of me. This portion of the display interface is similar to the interface shown in fig. 17 described above and is not shown here.

At the moment, whether the number of the users shielded by the first user at present reaches the upper limit of 50 is also required to be judged, if so, the upper limit of the number of the shielding names is popped up to be 50, and the prompt that the number of the users reaches the upper limit is displayed, so that the first user fails to shield the users; if the number of the shielded users of the current user A is 49, the first user is shielded successfully according to the sequence of selecting the shielded users of the user A, the shielded users of the user A are shielded successfully, and the number of the shielded users of the user A reaches 50 at the moment after the user A is shielded successfully, the upper limit of the shielding names of the shielded users of the user A and the shielded users of the user A is 50, the prompt that the number of the users reaches the upper limit is popped up, and the shielding fails. Only when the number of the shielded users of the user A is less than or equal to 47, the shielding information of the user A for the user B, the user C and the user D is effective, and the shielding can be successfully performed. And likewise, after selecting the user needing shielding, clicking the submit button to display confirmation prompt information so as to ensure that the user A confirms to shield any number of users B, C and T, and clicking to confirm shielding, so that the shielding operation is completed.

Fig. 18 is a schematic interface diagram of another method for processing shared service user data according to an embodiment of the present application, as shown in fig. 18, after confirming the screening, the first user may also view the screening progress through the screening progress query interface. If the current mask request is still in process, then the processing is displayed, and the current mask request is completed, then the submission is displayed as successful.

Fig. 19 is a schematic diagram of an interface in another method for processing shared service user data according to an embodiment of the present application, where, as shown in fig. 19, an a user may also view masked user information through a mask list interface. The shielding list can be divided into a driver list and a friend-spelling list, wherein the driver list is a driver list shielded by the first user, the friend-spelling list is a friend-spelling list shielded by the first user, different lists are selected, and the information of the shielded user can be checked. Alternatively, the mask list is not limited to the driver list and the friend list, but may be a user-defined list.

In this example, the user identities of the first, second, third, and fourth users may be arbitrarily combined, for example, the second user may be a service requester, the first, third, and fourth user may be an optional target sharing service party, and the like, which is not particularly limited herein.

According to the shared service user data processing method, the shielding indication information is sent to the server through the shielding request information input by the user terminal, so that the server can make shielding processing on a request for shielding a specific target shared service party sent by the service request party according to the shielding indication information, the problem that a user does not want to share the same service again due to contradiction and conflict in the process of sharing the service is solved, and the shared service is ensured not to share the same service; in addition, after submitting the shielding request, the user can also inquire the shielding progress and know the shielding progress in time; meanwhile, the user shielding condition can be checked through the user shielding list, so that the experience degree of the user participating in the sharing service is better improved.

Fig. 20 is a schematic structural diagram of a shared service user data processing apparatus according to an embodiment of the present application, where, as shown in fig. 20, the apparatus includes: the acquisition module 310 and the transmission module 320.

The obtaining module 310 is configured to receive mask request information input by a service requester, where the mask request information is used to request that a service is no longer shared with a target sharing service party.

A sending module 320, configured to send a mask indication message to the server according to the mask request information, where the mask indication message includes: an identification of the service requester, an identification of the target sharing service provider.

Further, the obtaining module 310 is specifically configured to display a selectable shared service party selection interface if there are a plurality of selectable shared service parties, where the selectable shared service parties are users sharing the same service with the service requester; and receiving each piece of selection information which is sequentially input by the service requester through the selectable sharing service party interface, wherein each piece of selection information is used for indicating a target sharing service party.

Fig. 21 is a schematic structural diagram of another shared service user data processing apparatus according to an embodiment of the present application, as shown in fig. 21, and further includes a determining module 330.

A determining module 330, configured to determine whether the number of shared service providers currently screened by the service requester reaches a preset threshold; if yes, determining that shielding fails; if not, the selection information is determined to be valid.

Further, referring to fig. 21, in some embodiments, the determining module 330 is further configured to determine whether the number of sharing servers currently shielded by the service requester reaches a preset threshold if there is a single optional sharing server; if yes, determining that shielding fails; if not, the shielding request information is determined to be valid.

FIG. 22 is a schematic structural diagram of another shared services user data processing apparatus according to an embodiment of the present application, as shown in FIG. 22, further including a display module 340; a display module 340 for displaying a shielding confirmation interface; the obtaining module 310 is further configured to receive confirmation shielding information input by the service requester through the confirmation interface.

Further, the obtaining module 310 is further configured to receive a query request input by the service requester, where the query request is used to request to query the shielding progress of the target sharing service provider; the sending module 320 is further configured to send, according to the query request, progress query information to the server, where the progress query information includes: an identification of the service requester and an identification of the target sharing service provider; the obtaining module 310 is further configured to receive a query result sent by the server according to the progress query information.

Further, referring to fig. 21, in some embodiments, the determining module 330 is configured to determine whether the shielding request information meets a preset shielding condition, where the preset shielding condition includes one or more of the following: the target sharing service side non-proxy requesting service side and the target sharing service side non-service requesting side shield the user.

FIG. 23 is a schematic structural diagram of another shared service user data processing apparatus according to an embodiment of the present application, as shown in FIG. 23, further including an adding module 350; an adding module 350 is configured to write the target sharing service party to the mask list.

Further, the obtaining module 310 is further configured to receive mask revocation request information input by the service requester, where the mask revocation request information is used to request to restore the service shared with the target sharing service party; the sending module 320 is further configured to send a mask revocation message to the server according to the mask revocation request information, where the mask revocation message includes: an identification of the service requester, an identification of the target sharing service provider.

Fig. 24 is a schematic structural diagram of a shared service user data processing apparatus according to an embodiment of the present application, where, as shown in fig. 24, the apparatus includes: a receiving module 410 and a marking module 420; a receiving module 410, configured to receive a mask indication message sent by a service requester terminal, where the mask indication message is used to request that a service is no longer shared with a target sharing service party, and the mask indication message includes: an identification of the service requester and an identification of the target sharing service provider; and the marking module 420 is configured to mark the target sharing service party as a mask user of the service requester according to the mask indication message.

Fig. 25 is a schematic structural diagram of another shared service user data processing apparatus according to an embodiment of the present application, as shown in fig. 25, further including: a service acquisition module 430 and a determination module 440; the receiving module 410 is specifically configured to receive a service request sent by a service requester terminal, where the service request is used for requesting a sharing service; the service obtaining module 430 is configured to obtain at least one sharable service to be selected from the service requester according to a preset algorithm; acquiring sharable candidate services of a shielding user without a service requester; a determining module 440, configured to select a target service of the service requester from sharable candidate services of the shielded users of the non-existence service requester.

Further, referring to fig. 25, in some embodiments, the receiving module 410 is further configured to receive a service request sent by a service requester terminal, where the service request is used to request a sharing service; the determining module 440 is further configured to determine a target service of the service requester, where the target service does not currently exist in the shared service party; one or more current sharing service parties are selected from the selectable sharing service parties, wherein the current sharing service party is not a screening user of the service requester.

FIG. 26 is a schematic structural diagram of another shared service user data processing apparatus according to an embodiment of the present application, as shown in FIG. 26, further including a data sending module 450; the receiving module 410 is further configured to receive progress query information sent by the service requester terminal, where the progress query information is used to request to query a shielding progress of the target sharing service provider; the progress query information includes: an identification of the service requester and an identification of the target sharing service provider; the data sending module 450 is configured to obtain a query result according to the progress query information; and sending the query result to the service requester terminal.

Further, the receiving module 410 is further configured to receive a mask revocation message sent by the service requester terminal, where the mask revocation message is used to request to restore the service shared with the target sharing service party; the mask revocation message comprises: an identification of the service requester, an identification of the target sharing service provider.

The above device may be used to execute the method provided by the above method embodiment, and the specific implementation manner and technical effects are similar, and are not repeated here.

Fig. 27 is a schematic structural diagram of another shared service user data processing apparatus according to an embodiment of the present application, as shown in fig. 27, where the apparatus includes: a processor 510 and a memory 520, wherein: the memory 520 is used to store a program, and the processor 510 calls the program stored in the memory 520 to execute the above-described method embodiment. The specific implementation manner and the technical effect are similar, and are not repeated here.

The apparatus may be integrated into a device such as a terminal or a server, and is not limited in this application.

Optionally, the present invention also provides a program product, such as a computer readable storage medium, comprising a program for performing the above-described method embodiments when being executed by a processor.

It will be clearly understood by those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described system and apparatus may refer to corresponding procedures in the method embodiments, which are not described in detail in this application. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. The above-described apparatus embodiments are merely illustrative, and the division of the modules is merely a logical function division, and there may be additional divisions when actually implemented, and for example, multiple modules or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some communication interface, indirect coupling or communication connection of devices or modules, electrical, mechanical, or other form.

The modules described as separate components may or may not be physically separate, and components shown as modules may or may not be physical units, may be located in one place, or may be distributed over multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a non-volatile computer readable storage medium executable by a processor. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a usb disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk, etc.

The foregoing is merely a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes or substitutions are covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for processing shared service user data, comprising:

receiving shielding request information input by a service requester through an interactive interface aiming at a target sharing service, wherein the shielding request information is used for requesting that the service is not shared with at least one target sharing service party any more, and the target sharing service party shares the target sharing service with the service requester;

according to the shielding request information, a shielding indication message is sent to a server, wherein the shielding indication message comprises: the service request side is identified, and the target sharing service side is identified, wherein the identification of the target sharing service side is a user identity attribute.

2. The method of claim 1, wherein the interactive interface is a user rating interface or a service complaint interface.

3. The method of claim 1, wherein receiving the mask request information input by the service requester comprises:

if a plurality of selectable sharing service parties exist, displaying a selectable sharing service party selection interface, wherein the selectable sharing service party is a user sharing the same service with the service request party;

and receiving each piece of selection information which is sequentially input by the service requester through the selectable sharing service party selection interface, wherein each piece of selection information is used for indicating one target sharing service party.

4. The method of claim 3, wherein after receiving each piece of selection information sequentially input by the service requester through the selectable shared service provider selection interface, comprising:

judging whether the number of the shared service sides which are shielded by the service request side currently reaches a preset threshold value or not;

if yes, determining that shielding fails;

if not, the selection information is determined to be valid.

5. The method of claim 3, wherein the optional shared services selection interface includes a user identity attribute for each of the optional shared services.

6. The method of claim 5, wherein the user identity attribute comprises one or more of: joining service time information, joining service location information, joining service order information, exiting service time information, exiting service location information, exiting service order information.

7. The method of claim 1, wherein after receiving the mask request information input by the service requester if there is a single optional shared service provider, further comprising:

if yes, determining that shielding fails;

and if not, determining that the shielding request information is valid.

8. The method of any of claims 1-7, wherein before sending a mask indication message to a server according to the mask request information, further comprising:

displaying a shielding confirmation interface;

and receiving confirmation shielding information input by the service requester through the confirmation interface.

9. The method of claim 1, wherein after sending a mask indication message to a server according to the mask request information, further comprising:

receiving a query request input by a service requester, wherein the query request is used for requesting to query the shielding progress of the target sharing service provider;

according to the query request, sending progress query information to the server, wherein the progress query information comprises: the identification of the service request party and the identification of the target sharing service party;

And receiving a query result sent by the server according to the progress query information.

10. The method of claim 1, wherein after receiving the mask request information input by the service requester, further comprising:

judging whether the shielding request information meets a preset shielding condition or not, wherein the preset shielding condition comprises one or more of the following: the target sharing service side is not a proxy requesting service side, and the target sharing service side is not the service requesting side and shields users.

11. The method of claim 1, wherein after receiving the mask request information input by the service requester, further comprising:

and writing the target sharing service side into a shielding list.

12. The method as recited in claim 1, further comprising:

receiving shielding revocation request information input by a service requester, wherein the shielding revocation request information is used for requesting to restore shared service with a target shared service party;

and sending a shielding revocation message to a server according to the shielding revocation request information, wherein the shielding revocation message comprises: the identification of the service request party and the identification of the target sharing service party.

13. A method for processing shared service user data, comprising:

receiving a shielding indication message sent by a service request party terminal, wherein the shielding indication message is used for requesting to share a service with at least one target sharing service party, the target sharing service party and the service request party share the target sharing service, and the shielding indication message comprises an identification of the service request party and an identification of the target sharing service party, wherein the identification of the target sharing service party is a user identity attribute;

and marking the target sharing service party as a shielding user of the service request party according to the shielding indication message so as not to match the same service with the target sharing service party for the service request party in the process of matching the sharing service in the follow-up process.

14. The method as recited in claim 13, further comprising:

receiving a service request sent by the service requester terminal, wherein the service request is used for requesting sharing service;

according to a preset algorithm, at least one sharable service to be selected of the service requesting party is obtained;

acquiring the sharable candidate service of a shielding user without the service requester;

Selecting a target service of the service requester from the sharable candidate services of a masked user where the service requester does not exist.

15. The method as recited in claim 13, further comprising:

determining a target service of the service requester, wherein the target service does not currently exist a sharing service party;

one or more current sharing service parties are selected from the selectable sharing service parties, wherein the current sharing service party is not a screening user of the service requester.

16. The method as recited in claim 13, further comprising:

receiving progress query information sent by a service requester terminal, wherein the progress query information is used for requesting to query the shielding progress of the target sharing service provider; the progress query information includes: the identification of the service request party and the identification of the target sharing service party;

acquiring a query result according to the progress query information;

and sending the query result to the service requester terminal.

17. The method as recited in claim 13, further comprising:

Receiving a shielding cancellation message sent by a service request side terminal, wherein the shielding cancellation message is used for requesting to restore the shared service with a target shared service side; the mask revocation message comprises: the identification of the service request party and the identification of the target sharing service party.

18. A shared services user data processing apparatus, comprising: the device comprises an acquisition module and a sending module;

the acquisition module is used for receiving shielding request information input by a service requester through an interactive interface aiming at a target sharing service, wherein the shielding request information is used for requesting that the service is not shared with at least one target sharing service party any more, and the target sharing service party and the service requester share the target sharing service;

the sending module is configured to send a mask indication message to a server according to the mask request information, where the mask indication message includes: the service request side is identified, and the target sharing service side is identified, wherein the identification of the target sharing service side is a user identity attribute.

19. A shared services user data processing apparatus, comprising: a receiving module and a marking module;

The receiving module is configured to receive a mask indication message sent by a service requester terminal, where the mask indication message is used to request that a service is no longer shared with at least one target sharing service party, the target sharing service party shares the target sharing service with the service requester, and the mask indication message includes an identifier of the service requester and an identifier of the target sharing service party, where the identifier of the target sharing service party is a user identity attribute;

and the marking module is used for marking the target sharing service party as a shielding user of the service request party according to the shielding indication message so as not to match the same service with the target sharing service party for the service request party in the process of matching the sharing service in the follow-up process.

20. An electronic device, comprising: a processor, a storage medium and a bus, the storage medium storing machine-readable instructions executable by the processor, the processor and the storage medium communicating over the bus when the electronic device is running, the processor executing the machine-readable instructions to perform the steps of the shared services user data processing method of any of claims 1 to 17 when executed.

21. A storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the shared services user data processing method of any of claims 1 to 17.