Account management method, server and storage medium

Abstract

The embodiment of the invention provides an account management method, a server and a storage medium. In the method, an account group creation request sent by a terminal device is received, and the account group creation request comprises identifiers of a plurality of accounts and a target account group type; creating a target account group containing the plurality of accounts based on the target account group type, and determining intra-group identities of the plurality of accounts in the target account group; generating description data of the target account group based on the group identities of the plurality of accounts in the target account group, and storing the description data of the target account group in a preset storage space; wherein the target account group type is specified by an operator of the terminal device from a plurality of candidate account group types.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202511605437.2 (22) Application Date 2025.11.04 (71) Applicant Ant International Business (Shanghai) Co., Ltd. Address Room 1408, No. 447, Nanquan North Road, China (Shanghai) Pilot Free Trade Zone, Pudong New Area, Shanghai 200131 (72) Inventor Gan Shihuan (74) Patent Agency Beijing Liuli Intellectual Property Agency (General Partnership) 16049 Patent Attorney Zhu Lefang (51) Int.Cl. G06F 21 / 41 (2013.01) G06F 3 / 06 (2006.01) (54) Invention Title Account Management Method, Server and Storage Medium (57) Abstract This specification provides an account management method, server and storage medium through embodiments. In the method, a request to create an account group is received from a terminal device. The request includes identifiers of multiple accounts and a target account group type. A target account group containing the multiple accounts is created based on the target account group type, and the identities of the multiple accounts within the target account group are determined. Description data of the target account group is generated based on the identities of the multiple accounts within the target account group, and the description data of the target account group is stored in a preset storage space. The target account group type is specified by the operator of the terminal device from multiple candidate account group types. Claims 2 pages, Description 15 pages, Drawings 8 pages, CN 121412970 A 2026.01.27 CN 1 21 41 29 70 A 1. An account management method, comprising: receiving an account group creation request sent by a terminal device, the account group creation request including identifiers of multiple accounts and a target account group type, wherein the target account group type is specified by an operator of the terminal device from multiple candidate account group types; creating a target account group containing the multiple accounts based on the target account group type, and determining the group identity of the multiple accounts in the target account group; and generating description data of the target account group based on the group identity of the multiple accounts in the target account group, and storing the description data of the target account group in a preset storage space, the preset storage space being used to store description data of different account groups. 2. The method according to claim 1, wherein different candidate account group types support different group identity systems. 3. The method according to claim 2, wherein the plurality of candidate account group types include at least two of the following: a first candidate account group type that supports a first-level identity system with peer identities; a second candidate account group type that supports a second-level identity system with primary identities and sub-identities; or a third candidate account group type that supports a third-level identity system with super-primary identities, primary identities, and sub-identities.4. The method according to claim 1, wherein the plurality of accounts includes a first account, the first account having a unique identity within the target account group, and the first account having polymorphic identities within different account groups. 5. The method according to claim 1, wherein creating a target account group containing the plurality of accounts based on the target account group type, and determining the identities of the plurality of accounts within the target account group, includes: obtaining an account group creation strategy corresponding to the target account group type, the account group creation strategy representing the conditions that each account in the account group to be created must meet, and the allocation method of the identities of each account within the group; and creating the target account group based on the account group creation strategy, and determining the identities of the plurality of accounts within the target account group. 6. The method according to claim 1, wherein the description data of the target account group includes: group-level description data, used to describe the configuration information of the target account group; and account-level description data, used to describe the affiliation relationship of the plurality of accounts with the target account group and their identities within the group. 7. The method according to claim 1, wherein the method is applied to a first server, the plurality of accounts including: a first account registered on the first server and a second account registered on a second server, storing the description data of the target account group in a preset storage space, including: storing the description data of the target account group in the local storage space of the first server; and synchronizing the description data of the target account group to the second server so that the description data of the target account group is stored in the local storage space of the second server. 8. The method according to claim 7, wherein the first server integrates a first middleware, the second server integrates a second middleware, both the first middleware and the second middleware have persistent storage function and cache storage function, storing the description data of the target account group in the local storage space of the first server, including: storing the description data of the target account group in the local database of the first server and synchronizing it to the first middleware; synchronizing the description data of the target account group to the second server, including: synchronizing the description data of the target account group to the second middleware through the first middleware. 9. The method of claim 8, further comprising: in response to receiving a first query request corresponding to the target account group from a requesting device, querying description data of the target account group from the first middleware, and returning the description data of the target account group to the requesting device. 10. The method of claim 9, wherein the requesting device is the second server, and the first query...The request is sent by the second server when it cannot find the description data of the target account group in the second middleware. 11. The method of claim 8, wherein the method further comprises: in response to receiving a second query request corresponding to the target account group from a requesting device, querying the description data of the target account group from the local database of the first server, and returning the description data of the target account group to the requesting device. 12. The method of claim 1, wherein the account group creation request further comprises a task type associated with the account group to be created, and the method further comprises: creating a target task based on the task type, and determining the triggering conditions and execution strategy of the target task; and in response to detecting the triggering conditions, executing the target task within the target account group according to the execution strategy. 13. The method of claim 12, wherein each account in the target account group is an account responsible for managing resources, and the target task is a task for resource transfer between different accounts in the target account group. 14. The method according to claim 12, wherein the method further comprises: obtaining authorization information between different accounts in the target account group, the authorization information representing the authorization status of resource transfer; the step of creating a target task based on the task type comprises: creating the target task based on the task type and the authorization information between different accounts in the target account group. 15. A server, comprising: at least one storage medium storing at least one instruction set; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during runtime and executes the method according to any one of claims 1-14 according to the instructions of the at least one instruction set. 16. A computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, and when the at least one instruction set is executed by the at least one processor, it implements the method according to any one of claims 1-14. Claims 2 / 2 Page 3 CN 121412970 A Account Management Method, Server and Storage Medium Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to an account management method, server and storage medium. Background Technology

[0002] With the rapid development of Internet technology, a number of service platforms have emerged, including but not limited to e-commerce platforms and financial platforms that can serve both domestic and overseas markets. For non-individual users (such as merchants) who conduct business domestically and internationally through such platforms, users can register multiple accounts on the service platform. Each account can independently manage the business situation in a specific region (such as orders, inventory, marketing, and cash flow). The functions of different accounts may also vary depending on the localization needs of different regions.There are differences in compliance requirements, etc. Different users may have different numbers of accounts and different account functions. How to meet the personalized needs of different users for account management is an urgent problem that the platform needs to solve.

[0003] The content of the background technology section is only information known to the inventor and does not mean that the above information has entered the public domain before the date of this application, nor does it mean that it can be the prior art of this disclosure. Summary of the Invention

[0004] This specification provides an account management method, server and storage medium, which can preset multiple account group types to cover user needs. Users can select the appropriate account group type as needed to create account groups for relevant accounts, which is more flexible and can meet the personalized needs of users for account management.

[0005] In a first aspect, this specification provides an account management method, comprising: receiving an account group creation request sent by a terminal device, the account group creation request including identifiers of multiple accounts and a target account group type, wherein the target account group type is specified by an operator of the terminal device from multiple candidate account group types; creating a target account group containing the multiple accounts based on the target account group type, and determining the group identity of the multiple accounts within the target account group; and generating description data of the target account group based on the group identity of the multiple accounts within the target account group, and storing the description data of the target account group in a preset storage space, the preset storage space being used to store description data of different account groups.

[0006] In a second aspect, this specification also provides a server, comprising: at least one storage medium storing at least one instruction set; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and, according to the instructions of the at least one instruction set: receives an account group creation request sent by a terminal device, the account group creation request including identifiers of multiple accounts and a target account group type, wherein the target account group type is specified by an operator of the terminal device from multiple candidate account group types; creates a target account group containing the multiple accounts based on the target account group type; determines the group identity of the multiple accounts within the target account group; and generates description data of the target account group based on the group identity of the multiple accounts within the target account group, and stores the description data of the target account group in a preset storage space, the preset storage space being used to store description data of different account groups.

[0007] In a third aspect, this specification provides a computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, and when the at least one instruction set is executed by at least one processor, implements the account management method as described in the first aspect. Instruction manual, page 1 / 15, CN 121412970 A

[0008] Other functions of the account management methods, servers, and storage media provided in this specification will be partially listed in the following description. The inventive aspects of the account management methods, servers, and storage media provided in this specification can be fully explained by practice or by using the methods, servers, and combinations described in the detailed examples below. Brief Description of the Drawings

[0009] To more clearly illustrate the technical solutions in the embodiments of this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 shows a schematic diagram of an application scenario of account management provided according to an embodiment of this specification; Figure 2 shows a hardware structure diagram of a computing system provided according to an embodiment of this specification; Figure 3 shows a flowchart of an account management method provided according to an embodiment of this specification; Figure 4 shows a schematic diagram of different account groups provided according to an embodiment of this specification; Figure 5 shows a schematic diagram of description data of a target account group provided according to an embodiment of this specification; Figure 6 shows a supplementary schematic diagram of description data of a target account group provided according to an embodiment of this specification; Figure 7 shows a flowchart of synchronous description data provided according to an embodiment of this specification; Figure 8 shows another flowchart of synchronous description data provided according to an embodiment of this specification; Figure 9 shows a flowchart of adding an account to an account group provided according to an embodiment of this specification; Figure 10 shows a flowchart of querying description data provided according to an embodiment of this specification; Figure 11 shows another flowchart of querying description data provided according to an embodiment of this specification; and Figure 12 shows a schematic diagram of the execution of a target task provided according to an embodiment of this specification. Detailed Description

[0011] The following description provides specific application scenarios and requirements of this specification, intended to enable those skilled in the art to create and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0012] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” as used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean the associated integers, steps, operations, etc.The presence of operations, elements, and / or components does not preclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or the addition of other features, integers, steps, operations, elements, components, and / or groups to the system / method.

[0013] Considering the following description, these and other features of this specification, as well as the operation and function of related elements of the structure, and the economy of the combination and manufacture of components, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0014] The flowcharts used in this specification illustrate the operations implemented by the system according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in sequence. Instead, the operations may be implemented in reverse order or simultaneously. Page 2 / 15 of the specification, CN 121412970 A. Furthermore, one or more other operations may be added to the flowchart. One or more operations may be removed from the flowchart.

[0015] The application scenario of account management provided in this specification is described below with reference to FIG1.

[0016] Figure 1 illustrates an application scenario diagram of account management provided according to an embodiment of this specification. As shown in Figure 1, the application scenario 100 includes a terminal device 10 and a first server 20.

[0017] In some embodiments, the terminal device 10 can serve as a medium for interaction between users and the service platform. For example, the terminal device 10 is deployed with a client provided by the service platform, and users can perform related operations on the client. Users can be individuals, employees of enterprises or companies, ordinary consumers, or merchants; this specification does not limit this.

[0018] In some embodiments, the terminal device 10 can also serve as a tool for the operation and management of the service platform. For example, the terminal device 10 deploys a back-end system dedicated to staff, supporting service platform staff in processing user requests, monitoring service status, and optimizing operational strategies.

[0019] For example, the terminal device 10 may include mobile devices, tablets, laptops, built-in devices in motor vehicles, or similar content, or any combination thereof. In some embodiments, the mobile device may include smart home devices, smart mobile devices, virtual reality devices, augmented reality devices, or similar devices, or any combination thereof. In some embodiments, the smart home device may include smart TVs, desktop computers, or any combination thereof. In some embodiments, the smart mobile device may include a smartphone, personal digital assistant, gaming device, navigation device, etc., or any combination thereof. In some embodiments, the built-in device in the motor vehicle may include an in-vehicle computer, in-vehicle television, etc. In some embodiments, the terminalDevice 10 may include financial instruments. For example, the financial instruments may be a bank's self-service terminal, etc.

[0020] In the financial field, the service platform may be a platform that provides financial services. For example, the service platform may provide users with digital payment and fund management services. This specification mainly uses the financial field as an example for explanation; other fields are similar and will not be described in detail.

[0021] For example, a user may take a merchant as an example. The merchant may register multiple accounts serving different regions on the service platform and use the registered accounts to log in to the service platform to perform related operations. Each account may contain multiple balance accounts corresponding to different currencies, and each account may also contain multiple credit accounts corresponding to different currencies. Funds may be pre-deposited into the balance account, and the payment may be deducted from the balance account when making an actual payment. The credit account has a credit line or credit limit provided by a financial institution (such as a bank or wallet), and the credit line may be used as working capital. Taking an account as an example, the account may be used to conduct business in a specific region to meet the merchant's fund management (payment, collection, etc.) needs in that specific region. As merchants develop, the number of registered accounts gradually increases, and the functions of these accounts become more diversified. How to enable merchants to efficiently manage multiple accounts according to their individual needs is a crucial factor in evaluating the service level of a service platform.

[0022] The service platform can deploy multiple servers to provide account management services to users in different regions. The first server 20 is one of these servers.

[0023] For example, the first server 20 is the server located in the same partitioned region as the terminal device 10 among the multiple servers, and can provide related services to accounts registered on the first server 20. For instance, the first server 20 can be responsible for processing and managing the resource flow of each account, including but not limited to: managing the inflow and outflow of funds for each account, fund accounting processing, foreign exchange purchase or settlement, credit line granting, credit line deduction, credit line increase, etc.

[0024] In some embodiments, the first server 20 can establish association relationships between users' various accounts based on the operations of the operator (user or platform staff) on the terminal device 10. For example, the first server 20 establishes a master-sub association relationship for multiple accounts, with one master account among the multiple accounts, and all other accounts besides the master account being sub-accounts. Therefore, page 3 / 15 of the specification, CN 121412970 A, states that the first server 20 can set account management rules under the master-sub relationship for the multiple accounts. However, with the development of service platforms and the personalization of user needs, there are differences in the number of accounts registered by different users, account permissions, account functions, etc., and a single account relationship is difficult to meet the personalized needs of users for account management.

[0025] To overcome the above problems, this specification provides an account management method P300.

[0026] In some embodiments, the first server 20 may store data and instructions for implementing the account management method P300, and may execute or be used to execute the data and instructions. In some embodiments, the first server 20 may include a hardware device with data information processing capabilities and the necessary programs required to drive the hardware device to work.

[0027] For example, referring to FIG1, the first server 20 may receive an account group creation request sent by the terminal device 10. The account group creation request includes the identifiers of multiple accounts and the target account group type. Based on the target account group type, a target account group containing the multiple accounts is created, and the identity of the multiple accounts within the target account group is determined. Then, based on the identity of the multiple accounts within the target account group, description data of the target account group is generated, and the description data of the target account group is stored in a preset storage space.

[0028] Specifically, the technical details of the account management method P300 will be described in detail later and will not be repeated here.

[0029] FIG2 shows a hardware structure diagram of a computing system 200 provided according to an embodiment of this specification. The computing system 200 may be the first server 20 in FIG1.

[0030] As shown in FIG2, the computing system 200 may include at least one storage medium 230 and at least one processor 220. In some embodiments, the computing system 200 may also include a communication port 250 and an internal communication bus 210. Furthermore, the computing system 200 may also include an I / O component 260.

[0031] The internal communication bus 210 may connect different system components. For example, the internal communication bus 210 may connect the storage medium 230, the processor 220, the communication port 250, and the I / O component 260.

[0032] The I / O component 260 supports input / output between the computing system 200 and other components.

[0033] The communication port 250 is used for data communication between the computing system 200 and the outside world. For example, the communication port 250 may be used for data communication between the computing system 200 and a network. The communication port 250 may be a wired communication port or a wireless communication port.

[0034] In some embodiments, the network may be any type of wired or wireless network, or a combination thereof. For example, networks can include cable networks, wired networks, fiber optic networks, telecommunications networks, intranets, the Internet, local area networks (LANs), wide area networks (WANs), wireless local area networks (WLANs), metropolitan area networks (MANs), and public switched telephone networks (PSTNs).Network (PSTN), Bluetooth network™, ZigBee™, Near Field Communication (NFC) network, or similar networks.

[0035] In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations or Internet exchange points. Through this access point, one or more components of various devices corresponding to the computing system 200 can connect to the network to exchange data or information.

[0036] The storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 236. The storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set may include computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that perform the account management methods provided in this specification. Specification 4 / 15 Page 7 CN 121412970 A

[0037] Processor 220 may be communicatively connected to storage medium 230. Processor 220 is used to execute at least one instruction set described above. When computing system 200 is running, processor 220 reads the at least one instruction set and executes the account management method provided in this specification according to the instructions of the at least one instruction set.

[0038] Processor 220 may be in the form of one or more processors. In some embodiments, processor 220 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, etc., or any combination thereof.

[0039] For illustrative purposes only, only one processor 220 is shown in computing system 200 in Figure 2. However, it should be noted that the computing system 200 in this specification may also include multiple processors. Therefore, the operation and / or method steps disclosed in this specification may be executed by a single processor as described in this specification, or they may be executed jointly by multiple processors. For example, if processor 220 of the computing system 200 in this specification executes steps A and B, it should be understood that steps A and B...B can also be executed jointly or separately by two different processors 220 (e.g., the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).

[0040] FIG3 shows a flowchart of an account management method P300 provided according to an embodiment of this specification. The first server can execute the account management method P300.

[0041] As shown in FIG3, the account management method P300 includes the following steps.

[0042] S310: Receive an account group creation request sent by a terminal device. The account group creation request includes the identifiers of multiple accounts and the target account group type, wherein the target account group type is specified by the operator of the terminal device from multiple candidate account group types.

[0043] The operator of the terminal device can be a user of the service platform or a staff member of the service platform. This specification does not limit this. When the user has relevant needs, he / she can operate on the terminal device, so that the terminal device can generate an account group creation request in response to the user's operation and send the account group creation request to the first server.

[0044] For example, the user logs in to the first account on the terminal device and performs the operation of inviting other accounts through the first account. In response to an invitation operation, the terminal device can determine the registration server of the first account, or a server belonging to the same partitioned region as the terminal device, and send an account group creation request to the corresponding server. The first server can be understood as the registration server of the first account or a server belonging to the same partitioned region as the terminal device. The service platform can also default to creating the account group server. For example, if the service platform sets the first server as the default server for creating the account group, then regardless of which account the user uses to perform the invitation operation on the terminal device, the terminal device will send an account group creation request to the first server. Of course, the terminal device can also determine the recipient of the account group creation request in other ways, and this specification does not limit this.

[0045] When providing related services to users, the staff of the service platform can perform related operations on the terminal device, so that the terminal device can respond to the staff's operation and send an account group creation request to the first server.

[0046] For example, the staff logs into their management account on the terminal device, confirms that the user has multiple accounts, and learns that the user has a need to transfer resources between multiple accounts. At this time, the staff can initiate an account group creation operation on the terminal device. The terminal device responds to the creation operation by generating an account group creation request and determines the recipient of the account group creation request (such as a first server), thereby sending the account group creation request to the recipient. The first server can be a default server or a registration server for a user's account; this specification does not impose any restrictions on this. Specification 5 / 15 page 8 CN 121412970 A

[0047] When initiating related operations, the operator of the terminal device can specify the account group type of the target account group to be created, i.e., the target account group type, and can also specify multiple accounts to be created into a group. Therefore, the account group creation request sent by the terminal device to the first server can include the identifiers (IDs) of the multiple accounts and the target account group type.

[0048] The target account group type in the account group creation request can be an identifier representing the target account group type, which is not limited in this specification. When initiating related operations, the operator can select a suitable target account group type from multiple candidate account group types based on the user's characteristics, user needs, or the permissions and functions of the multiple accounts the user possesses.

[0049] In some embodiments, different candidate account group types among the multiple candidate account group types support different intra-group identity systems. Intra-group identity systems can also be understood as the way intra-group identities are divided. The service platform can preset multiple candidate account group types that can cover various user needs, providing multiple intra-group identity systems, so that the operator of the terminal device can flexibly select a suitable account group type as needed, facilitating subsequent enjoyment of high-quality account management services through the appropriate account group type.

[0050] For example, the multiple candidate account group types include at least two of the first candidate account group type, the second candidate account group type, or the third candidate account group type. The service platform can define the identity hierarchy structure of each account in different candidate account group types and the association type between each account through the identity field within the group. This is relatively flexible, and operators can choose to create appropriate account groups as needed. When the service platform develops new service products during its development process, and the new service products support new identity hierarchy structures, the service platform can create account groups for the new service products and reset the identities within the account groups without changing the basic pattern of establishing associations between accounts through account groups. This has strong adaptability and scalability.

[0051] The first candidate account group type is, for example, a peer-level type, which supports a first-level identity system with peer identities. An example of the first candidate account group type is account group 1 in Figure 4. Account group 1 includes a first account and a second account. Both the first account and the second account have peer identities and can have similar permissions and functions. The first server establishes a peer-to-peer relationship between the first account and the second account through account group 1, enabling resource transfer tasks between the first and second accounts that are of the same level, such as fund transfers. The first-level identity system is relatively simple; accounts within the group have similar permissions and functions, which simplifies the operation process of resource transfer tasks and lowers the operational threshold. When automatically managing accounts in this type of account group, the first server can disregard complex hierarchical relationships and permission allocation issues, reducing management costs and improving management efficiency.

[0052] The second candidate account group type is, for example, the master-sub type, supporting a two-level identity system of master and sub-identities.Account group types such as account group 2 in Figure 4 are candidate account group types. Account group 2 includes account 1, account 2, and account 3. Account 3 has a higher identity level in account group 2, and can have higher permissions and decision-making power, serving as the master account within account group 2 (i.e., the account with the master identity within the group). Account 1 and account 2 have lower identity levels in account group 2, serving as sub-accounts within account group 2 (i.e., the accounts with the sub-identity within the group). Account 1 and account 2 can have similar permissions and functions. The first server establishes master-sub relationships between account 1 and account 3, and between account 2 and account 3 through account group 2. This allows for resource transfer tasks between accounts of different identity levels within account group 2. For example, the first server can automatically aggregate the balances from account 1 and account 2 to account 3; or aggregate the credit limits from account 1 and account 2 to account 3, thereby increasing the total credit limit of account 3 and alleviating the user's financial difficulties. The two-level identity system supported by the second candidate account group type can clearly define the affiliation and responsibilities between different accounts. For example, the master account can uniformly manage and allocate the resources of the sub-accounts, realize the optimized configuration and sharing of resources, meet the needs of users in different scenarios, and provide users with more personalized and professional services. The service platform can also carry out more diversified services through the two-level identity system, attracting more users to register on the platform.

[0053] The third candidate account group type is, for example, the supermaster-master-sub type, which supports a three-level identity system of supermaster identity, master identity and sub-identity. The account group of the third candidate account group type is, for example, account group 3 in Figure 4. Account group 3 includes the first account, the third account and the fourth account. Among them, the third account has the highest identity level, the first account has the second highest identity level, and the fourth account has the lowest identity level. The first server establishes master-sub relationship between the third account and the first account, and between the first account and the fourth account through account group 3. The three-level identity system can provide more detailed permission division and management level, which can meet the refined management needs of users with a large number of accounts, and provide more professional and refined services. The super-master account (i.e., the account with the super-master identity within the group) can provide macro-management services to users, while the master account can provide local management services. For example, if a user is a merchant operating globally, the third account can record the cash flow of all the user's accounts, the first account can record the cash flow of accounts in a specific region, and the fourth account can record the cash flow of accounts linked to a specific store. Thus, the user can analyze the profitability of all stores globally through the third account, analyze the profitability of stores in a specific region through the first account, and analyze the profitability of a specific store through the fourth account, thereby determining global business adjustment strategies, etc.

[0054] In some embodiments, the multiple accounts in the account group creation request include a first account. The first account has a unique identity within the target account group, and the first account has polymorphic identities within different account groups.

[0055] Continuing to refer to Figure 4, the first account has a unique identity within account group 1, i.e., at the same level. That is to say, for a single account group, the identity of each account within the account group is unique, which can reduce the complexity of the identities of each account within the account group and avoid management problems caused by diverse identities within the group. The identity of the first account in account group 1 is different from its identity in account group 2 and account group 3. That is to say, the same account can have different identities in different account groups, so that the service platform can provide users with diversified services through different account groups, accurately meet the personalized needs of users, and be more flexible.

[0056] S320: Create a target account group containing the multiple accounts based on the target account group type, and determine the identities of the multiple accounts within the target account group.

[0057] If the account group creation request includes the identifiers of the first account and the second account, and the included target account group type supports a first-level identity system, then the target account group created by the first server refers to account group 1 in Figure 4. If the account group creation request includes the identifiers of the first account, the second account, and the third account, and the target account group type supports a two-level identity system, then the target account group created by the first server is referred to as account group 2 in Figure 4. If the account group creation request includes the identifiers of the first account, the third account, and the fourth account, and the target account group type supports a three-level identity system, then the target account group created by the first server is referred to as account group 3 in Figure 4.

[0058] In some embodiments, the first server obtains the account group creation strategy corresponding to the target account group type. The account group creation strategy characterizes the conditions that each account in the account group to be created needs to meet, and the allocation method of the identity within the group for each account. Then, the first server creates the target account group based on the account group creation strategy and determines the identity of multiple accounts in the account group creation request within the target account group.

[0059] For example, the target account group type supports a one-level identity system. The account group creation strategy corresponding to the target account group type may include, but is not limited to: all accounts in the account group to be created have the same level of identity; all accounts in the account group to be created have similar permissions or functions, etc.

[0060] For example, the target account group type supports a two-level identity system. The account group creation strategy corresponding to the target account group type may include, but is not limited to: only one account in the account group to be created can be the main account, and the remaining accounts are sub-accounts; the main account has higher permissions than the sub-accounts; the main account has more functions than the sub-accounts, etc.

[0061] For example, the target account group type supports a three-level identity system. The account group creation strategy corresponding to the target account group type may include, but is not limited to, the following: only one account in the account group to be created can be the main account, and the remaining accounts are sub-accounts; the main account has higher permissions than the sub-accounts; the main account has more functions than the sub-accounts, etc.

[0061] The creation strategy may include, but is not limited to: only one account in the account group to be created, which can be a super-master account; there can be one or more master accounts, and one or more sub-accounts; the permissions are sorted from high to low as super-master account, master account, and sub-account; the functions are sorted from many to few as super-master account, master account, and sub-account, etc.

[0062] The first server can determine whether the account group creation request is reasonable according to the account group creation strategy corresponding to the target account group type. If the account group creation request is unreasonable, the first server can refuse to create the target account group. If the account group creation request is reasonable, the first server can create the target account group based on the account group creation strategy.

[0063] In this embodiment, the preset account group creation strategy provides a unified standard and procedure for account group creation, avoiding confusion and inconsistency caused by arbitrary human operation. The account group creation strategy can clearly define the naming of the identities of each account in the account group, the naming of the account group, the number of accounts of each identity in the account group, and the conditions that the accounts need to meet, so that the creation of the account group is systematic and the first server can automate the creation process according to the same standard, shorten the creation time, and improve the efficiency, accuracy and standardization of account group creation.

[0064] When the target account group type supports a two-level identity system or a three-level identity system, the first server can determine the characteristics of each account by the identifiers of each account included in the account group creation request. For example, the first server can determine the identity of each account in the target account group by the permissions and functions of each account.

[0065] For example, if the target account group type supports a two-level identity system, and the permissions of the third account are greater than those of the first account, or the area managed by the third account is greater than the area managed by the first account, then the first server can determine that the identity of the third account in the target account group is the primary identity, and the identity of the first account in the target account group is the secondary identity.

[0066] For example, if the account group creation request is initiated by a user inviting other accounts through a third account, then the first server can determine that the third account's identity within the target account group is the primary identity, and the identities of other accounts within the target account group are secondary identities.

[0067] Alternatively, the account group creation request can also specify the identities of at least some accounts, so that the first server can determine the identities of each account within the target account group through the account group creation request. When the target account group type supports a three-level identity system, the method by which the first server determines the identity of each account within the group is similar and will not be repeated here. This specification does not limit the method by which the first server determines the identity of each account within the group.

[0068] S330: Based on the identities of the multiple accounts within the target account group, generate description data for the target account group, and store the description data of the target account group in a preset storage space. The preset storage space is used to store description data for different account groups.

[0069] The description data of the target account group can represent some configuration information of the target account group itself, including but not limited to: target account group ID, target account group name, target account group description, target account group creation template, target account group creation time, and target account group status. The description data of the target account group can also represent the association between each account in the target account group and the target account group, as well as the group identity of each account in the target account group.

[0070] In some embodiments, the description data of the target account group includes group-level description data and account-level description data. The group-level description data is used to describe the configuration information of the target account group. The account-level description data is used to describe the association between the multiple accounts and the target account group and their group identity information. The association between the multiple accounts and the target account group can also map the association between the multiple accounts.

[0071] For example, the description data of the target account group is shown in Figure 5. The group-level description data is the description data from the perspective of the account group. The target account group ID is used to uniquely identify the target account group. The target account group name can be a name given by the user to Group A on page 8 / 15 of the account manual (CN 121412970 A), for easy display to the user. The target account group description is used to explain, define, or supplement the relevant information of the target account group, making the target account group easier to understand, manage, and use. The creation template ID can uniquely identify the creation template of the account group of the target account group type, and can include creation rules or conditions that must be met to create an account. The status includes valid or invalid. Valid means that the target account group is currently available, and invalid means that the target account group is currently unavailable.

[0072] Continuing to refer to Figure 5, the account level description data is the description data from the account perspective, including but not limited to: the account group ID to which the account belongs, the account ID, and the account's identity within the group. If the target account group includes n accounts, where n is an integer greater than 1, then the description data of the target account group includes n account level description data, with each account corresponding to one account level description data. Taking the first account as an example, when the first account belongs to multiple account groups, the account level description data of the first account can correspond to multiple account group IDs, which is not limited in this specification. When the first server stores the description data of the target account group in the preset storage space, it can set the association between the group-level description data and the account-level description data.

[0073] In addition, the group-level description data may also include some other extended fields to facilitate subsequent supplementary descriptions of the target account group. The account-level description data may also include some other extended fields and redundant information. Extended fields facilitate subsequent supplementary descriptions of the account. Redundant information includes, but is not limited to: account subject, region, tenant, status, etc. If an account in the target account group is registered on another server, the first server can store the basic information of that account.This information facilitates data querying and the implementation of specific services.

[0074] In this embodiment, the preset storage space can store description data at different levels, which helps to establish a clear data architecture, facilitates quick querying by the first server, and thus better manages and maintains accounts and account groups. When data anomalies occur or historical operation situations need to be understood, they can be traced through description data at different levels.

[0075] For example, as shown in FIG6, the description data of the target account group may also include authorization information. The first server can generate authorization information based on the authorization status between each account when creating the target account group, or it can generate authorization information based on the authorization status of each account when performing specific tasks based on the target account group. This specification does not limit the timing of the first server generating and storing authorization information. Users can authorize each account in different ways (such as signing authorization, etc.), and this specification does not limit this. Taking account group 2 as an example, it includes 2 sub-accounts. The first server can obtain the authorization information of the first account to the third account, and the authorization information of the second account to the third account. The authorization information of the first account to the third account includes the target account group ID, the source account ID (i.e., the ID of the first account), the target account ID (i.e., the ID of the third account), whether authorization is granted, and the authorized function. Authorization includes, but is not limited to, information authorization and / or resource authorization. Information authorization is, for example, granting the permission to view information (such as bills). Resource authorization is, for example, granting the permission to transfer (or allocate) resources. The authorization function can specify whether the authorization is information authorization or resource authorization. The authorization information of the second account to the third account follows the same pattern and will not be described again.

[0076] In addition, the description data of the target account group may also include the execution strategy of the target task associated with the target account group. When the target task is a fund transfer task, the execution strategy can be a fund transfer strategy (as shown in Figure 6). The fund transfer strategy includes, but is not limited to: target account group ID, fund collection rules, the scope of the source account, the target account ID, status, etc. The fund collection rules include, but are not limited to: fund collection frequency, fund collection amount or percentage, etc. The scope of the source account can include the scope of sub-accounts that have been granted fund allocation permissions to the main account in the target account group. The target account ID can be the ID of the inflow of funds, i.e., the ID of the main account within the target account group. The first server can generate and store a fund transfer strategy based on the fund authorization status of each account within the target account group when creating the target account group, or it can generate and store a fund transfer strategy based on the authorization status of each account when performing a target task based on the target account group. This specification does not restrict the timing of the first server generating and storing the fund transfer strategy.

[0077] When the target task is another task, the execution strategy can also be other strategies not shown in Figure 6. This specification refers to page 9 / 15 of the specification, 12 CN 121412970 A.These will not be listed one by one. The execution policy can be the default policy or a policy defined by the operator of the terminal device, which will not be elaborated on in this specification. When the first server stores the description data of the target account group in the preset storage space, it can also set the association between the group-level description data, authorization information and related execution policies.

[0078] The storage method of the description data of the target account group is described below.

[0079] In some embodiments, the service platform is deployed with a global database, which is used to store relevant data that needs to be synchronized to each server deployed on the service platform. The description data of the account group generated by each server needs to be stored in the global database. The global database can be deployed on any server. For example, as shown in Figure 7, the global database is deployed on the first server. In this case, if the first server receives an account group creation request, and the multiple accounts in the account group creation request include the first account registered on the first server and the second account registered on the second server, then the first server generates the description data of the target account group and stores the description data of the target account group in the global database. Then, the global database synchronizes the description data of the target account group to the local storage space of the first server and the local storage space of the second server. The local storage space includes a database with persistent storage functionality and / or a database with cache storage functionality. If the second server receives an account group creation request, and the multiple accounts in the account group creation request include a first account registered on the first server and a second account registered on the second server, then the second server generates description data for the target account group and routes the description data of the target account group to the first server so that the first server stores the description data of the target account group in the global database. Then, the global database synchronizes the description data of the target account group to the local storage space of the servers (such as the first server and the second server) where each account is registered.

[0080] In some embodiments, the multiple accounts in the account group creation request include a first account registered on the first server and a second account registered on the second server. The first server stores the description data of the target account group in the local storage space of the first server and synchronizes the description data of the target account group with the second server so that the description data of the target account group is stored in the local storage space of the second server. Data synchronization ensures that the description data of the target account group stored on servers associated with accounts in the target account group remains consistent, providing users with accurate and unified services, avoiding task conflicts caused by data inconsistency, and also preventing data loss on one server, thus enabling data recovery.

[0081] For example, as shown in FIG8, the first server integrates a first middleware, and the first middleware and a local database (DB, with persistent storage capability) constitute the local storage space of the first server. The second server integrates...There is a second middleware, and the second middleware and the local database (with persistent storage capability) constitute the local storage space of the second server. Both the first middleware and the second middleware have caching storage functions. The first middleware and the second middleware can also have persistent storage functions to ensure the persistence of stored data. The first server and the second server can achieve data synchronization through the first middleware and the second middleware.

[0082] Specifically, the first server stores the description data of the target account group in the local database of the first server and synchronizes it to the first middleware. The first server synchronizes the description data of the target account group to the second middleware through the first middleware. The data synchronization method shown in Figure 8 can utilize the data synchronization function of the middleware, without writing complex data synchronization code, simplifying the data synchronization process, reducing the complexity of data synchronization, and improving the data synchronization efficiency. During initial storage, there is no need to find the server where the target database is deployed, which can avoid the risk of data explosion caused by the surge in the amount of data in the target database, and can also avoid the problem that the description data of the target account group cannot be found in the local storage space of the second server due to the slow data synchronization process in Figure 7.

[0083] The middleware can be a data synchronization component developed by the service platform itself, or a data synchronization component developed by other platforms. This specification does not limit this. Specification 10 / 15 pages 13 CN 121412970 A

[0084] In addition, for a target account group including a first account and a second account, the first server can also send the account-level description data of the second account to the second server, so that the second server can store the account-level description data of the second account in its local database. Alternatively, the first server can also send the description data of the target account group to the second server, so that the second server can store the description data of the target account group in its local database.

[0085] In some embodiments, after the operator performs an account group update operation on the terminal device, the terminal device sends an account group update request to the first server to request the addition or deletion of accounts in the created target account group. At this time, the group-level description data stored in the preset storage space may remain unchanged, but it is necessary to add or delete account-level description data.

[0086] For example, the account group update request is used to request the addition of a fourth account to account group 2, and the fourth account's identity within the group is a sub-identity. The terminal device can route the account group update request to the first server that created account group 2. Thus, the first server can generate account-level description data for the fourth account based on the account group update request, store the account-level description data of the fourth account in the local storage space of the first server, and also synchronize the account-level description data of the fourth account to the local storage space of the second server.

[0087] For example, as shown in Figure 9, the first server can store the account level description data of the fourth account in its local database and can also send the account level description data of the fourth account to the second server. The second server can store the received account level description data of the fourth account in its local database and can also synchronize the account level description data of the fourth account to the second middleware. The second middleware synchronizes the account level description data of the fourth account to the first middleware.

[0088] The first server can also synchronize the account level description data of the fourth account to the second server in other ways.

[0089] For example, the first server can store the account level description data of the fourth account in its local database and synchronize the account level description data of the fourth account to the first middleware. The first middleware synchronizes the account level description data of the fourth account to the second middleware. The first server can also send the account level description data of the fourth account to the second server, and the second server can store the received account level description data of the fourth account in its local database.

[0090] This method of synchronizing account-level description data to different servers allows the service platform to still perform related tasks using description data from other unrestricted servers, even when there are restrictions on data export in the regions where some servers are located. This avoids the service platform's normal service to users being affected by data export restrictions.

[0091] It should be noted that when all accounts in the target account group are registered on the first server, no data synchronization operation is required, achieving data isolation between different servers and ensuring data privacy and integrity. Since data storage and querying are both on one server, data query efficiency can be improved. When the target account group also includes accounts registered on other servers, data synchronization can be performed using a similar method described above, which will not be repeated here.

[0092] In some embodiments, in response to receiving a first query request corresponding to the target account group from the requesting device, the first server queries the description data of the target account group from the first middleware and returns the description data of the target account group to the requesting device. The first middleware has a caching storage function, and querying in the first middleware can improve query efficiency.

[0093] For example, the requesting device is a query device (terminal device used for querying) used by the querying personnel. The query device responds to the query user's query operation by generating a first query request. The query device can route the first query request to the first server that created the target account group, or to the first server belonging to the same partition as the query device. (See specification 11 / 15, page 14, CN 121412970 A). Thus, after receiving the first query request, the first server can query the description data of the target account group in the first middleware.The query device returns the description data of the target account group to the query device. The query device can render and display the query results to the query user.

[0094] For example, as shown in FIG10, the query device generates a first query request in response to the query user's query operation. The query device can route the first query request to a second server that belongs to the same partition area as the query device (e.g., the query operation performed by the query user through the second account). The second server is not the server that created the target account group. Due to data synchronization timeliness issues, the second server may not be able to find the description data of the target account group. In this case, the requesting device is the second server. After receiving the first query request from the query device, the second server queries the description data of the target account group in the second middleware. If it determines that the description data of the target account group cannot be found in the second middleware, it forwards the first query request to the first server. The first server can query the description data of the target account group in the first middleware and return the description data of the target account group (query result) to the second server. The second server returns the description data of the target account group (query result) to the query device.

[0095] That is to say, in this example, the first query request received by the first server is sent by the second server when the description data of the target account group cannot be found in the second middleware. This example expands the scope of data query. When the description data of the target account group has not yet been synchronized to the second server, a fallback query can be performed on the first server. This is suitable for query scenarios where the timeliness of the query is not critical, ensuring that users can find the information they need under any circumstances, without causing query failures or poor user experience due to data synchronization delays.

[0096] In some embodiments, in response to receiving a second query request corresponding to the target account group from the requesting device, the first server queries the description data of the target account group from its local database and returns the description data of the target account group to the requesting device.

[0097] For example, as shown in FIG11, the requesting device is a querying device that generates a second query request in response to the querying user's query operation. The requesting device can route the second query request to the first server that belongs to the same partitioned region as the requesting device, or to the first server that created the target account group. After receiving the second query request, the first server can query the description data of the target account group in its local database, thereby returning the description data of the target account group (query result) to the requesting device. This query method can avoid query failures and poor query experience caused by the target account group's description data not yet being synchronized from the local database to the first middleware, and is suitable for scenarios with high requirements for data query timeliness.

[0098] In the above example, the first query request and the second query request can correspond to different query interface identifiers, fromThe query device can select the appropriate query interface as needed based on the query timeliness requirements, which is relatively flexible. The query personnel can be users or service platform staff, and this specification does not restrict this.

[0099] In some embodiments, the account group creation request also includes the task type associated with the account group to be created. The first server creates a target task based on the task type and determines the triggering conditions and execution strategy of the target task. Then, in response to detecting that the triggering conditions of the target task are met, the first server executes the target task within the target account group according to the execution strategy of the target task. Different account groups can be associated with different task types, set different triggering conditions and execution strategies, thereby realizing differentiated and precise control of account groups and providing flexible and diversified task modes.

[0100] For example, when the first server creates a target account group based on the account group creation request, it can also create an associated task type for the target account group. The first server can also obtain the authorization information between different accounts in the target account group, and the authorization information represents the authorization status of resource flow. Then, the first server can create a target task based on the task type of the target task and the authorization information between different accounts in the target account group. The authorization information can be precise down to the resource transfer permissions of each account, and may include the upper limit of resource allocation, the scope of allocation objects, etc. This can effectively prevent unauthorized resource transfer behavior and improve the security of automated resource transfer.

[0101] The first server can obtain the authorization information between different accounts in the target account group from the preset storage space, and can also notify the user to perform account authorization operations in real time, thereby generating and storing the authorization information between different accounts in the target account group based on the user's authorization operation.

[0102] The task types associated with the target account group include, but are not limited to: fund transfer tasks or credit transfer tasks. The first server can create target tasks based on the type of accounts in the target account group, authorization information and the task types associated with the target account group, and determine the triggering conditions and execution strategies of the target tasks. For example, if all accounts in the target account group include credit accounts, and at least some sub-accounts in the target account group have authorized funds to the main account, then the first server can create credit transfer tasks for the target account group and their corresponding triggering conditions and execution strategies. For example, if all accounts in the target account group include balance accounts, and at least some sub-accounts in the target account group have authorized funds to the main account, then the first server can create a fund transfer task for the target account group, along with its corresponding triggering conditions and execution strategy.

[0103] For example, each account in the target account group is an account responsible for managing resources. Resources include, but are not limited to, fund balances or credit lines. The target task is a task that transfers resources between different accounts in the target account group.Users can set resource transfer strategies or rules for target account groups, so that resource transfer between accounts within the target account group can be automated without manual operation by the user, thus improving the user experience.

[0104] For example, the target task is to collect funds between different accounts in the target account group. Taking account group 2 as an example, the target task is to collect the funds of the second account and the first account into the third account. Referring to Figure 12, the triggering conditions of the target task may include: the current time reaches the preset collection time, and the balance of the source account changes. The source account includes the first account and the second account, and the balance is the fund balance of the balance account.

[0105] Continuing to refer to Figure 12, after at least one of the triggering conditions of the target task is met, the first server can obtain the execution strategy of the target task from the preset storage space. If the preset storage space does not have the execution strategy of the target task, the first server can generate and store the execution strategy of the target task in real time based on the authorization information of each account in the target account group. The execution strategy of the target task includes: target account group ID, fund collection rules, the scope of the source account, target account ID, execution strategy status, etc. Fund collection rules include, but are not limited to, preset collection amount, preset collection ratio, preset collection currency, etc. The first server can execute the target task based on the execution strategy of the target task.

[0106] Specifically, after the triggering condition of the target task is met or triggered, the first server can periodically collect the funds of the second account (source account) and the first account (source account) to the third account (target account) according to the preset collection frequency. When collecting funds, the first server can transfer the fund balance of the second account and the first account corresponding to the preset collection currency to the third account according to the preset collection amount or preset collection ratio. When collecting funds, the first server can also transfer funds according to the scope of the source account. For example, if the source account includes the second account but does not include the first account (such as when the first account has not granted the third account the right to transfer funds), then when collecting funds, only the funds of the second account need to be transferred to the third account as needed. The source account is the outflow of funds in the fund collection scenario.

[0107] If an account exists in multiple account groups, the first server can also preset the fund collection priority of multiple account groups. When the account balance changes, the first server allocates the funds of the account to the main account in at least one account group in sequence according to the fund collection priority. After the first server completes the fund collection, it can also generate a fund collection statement and store the fund collection statement in a preset storage space.

[0108] For example, the target task is to collect credit limits between different accounts in the target account group. Taking account group 2 as an example, the target task is to collect the credit limits of the second account and the first account into the third account, thereby increasing the total credit limit of the third account. The triggering conditions for the target task may include the restoration or change of the credit limit of each account.The timing of CN 121412970 A on pages 13 / 15 of the manual will not be detailed here. The execution strategy of the target task can refer to the example above, except that the resources being transferred are changed from the balance of funds to the quota.

[0109] The first server can also associate other types of tasks with the target account group. For the same type of task, the first server can also set different trigger conditions and execution strategies for different account groups, which will not be listed in this specification. In addition, multiple accounts in the target account group of this specification can also belong to different users, which is not limited in this specification.

[0110] It should be noted that in the process of describing the account management method P300 above, the financial field is used as an example, so the specific description uses the terms that are involved in this field, such as resource transfer, fund collection, quota collection, etc. If the account management method P300 is applied to other fields, the specific content involved in the account can be adjusted accordingly, which will not be listed here.

[0111] In summary, in the account management method and server provided in this specification, the service platform can preset multiple candidate account group types covering user needs, so that the operator of the terminal device can initiate an account group creation request of a specific account group type as needed according to the function and permissions of each account, realize the construction of one or more account groups, and manage related accounts at the granularity of account groups. This on-demand account group construction method allows an account to exist in multiple different types of account groups, which is more flexible and can meet the operator's personalized needs for account management.

[0112] In another aspect, this specification provides a computer-readable non-transitory storage medium storing at least one set of executable instructions for account management. When the executable instructions are executed by a processor, the executable instructions instruct the processor to implement the steps of method P300 described in this specification. In some possible embodiments, various aspects of this specification can also be implemented in the form of a program product, which includes program code. When the program product is run on the computing system 200, the program code is used to cause the computing system 200 to perform the steps of method P300 described in this specification. The program product used to implement the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on the computing system 200. However, the program product of this specification is not limited thereto. In this specification, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a readable storage medium include: having one or moreElectrical connections of multiple wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing operations of this specification may be written in any combination of one or more programming languages, including object-oriented programming languages—such as Java, C++, etc.—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the computing system 200, partially on the computing system 200, as a standalone software package, partially on the computing system 200 and partially on a remote computing device, or entirely on a remote computing device. Specification 14 / 15 pages 17 CN 121412970 A

[0113] The term "and / or" in the embodiments of this specification describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the related objects before and after are in an "or" relationship.

[0114] The terms "first," "second," etc., in this specification are used to distinguish similar or class-specific objects or entities, and do not necessarily imply a specific order or sequence.

[0115] Unless otherwise stated, "multiple" mentioned in this specification should be understood as two or more.

[0116] Specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than those shown in the embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or potentially advantageous.

[0117] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure may be presented by way of example only and may not be restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments of this specification.

[0118] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" means that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and should be understood that two or more references to "an embodiment" or "an embodiment" or "an alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be appropriately combined in one or more embodiments of this specification.

[0119] It should be understood that in the foregoing description of the embodiments of this specification, in order to aid in understanding a feature, and for the purpose of simplifying this specification, various features are combined in a single embodiment, drawing, or description thereof. However, this does not mean that the combination of these features is necessary, and those skilled in the art may well identify some of the devices as separate embodiments when reading this specification. That is, the embodiments in this specification can also be understood as an integration of multiple sub-embodiments. And it is also true when the content of each sub-embodiment is less than all the features of a single foregoing disclosed embodiment.

[0120] Every patent, patent application, publication of patent application, and other materials, such as articles, books, specifications, publications, documents, literature, etc. (excluding any historical examination documents associated therewith), cited in this disclosure are cited for all purposes related to this disclosure, for example, in the specification and claims of this disclosure. However, if there is any inconsistency or conflict between the description, definition, and / or terminology of the foregoing materials and the description, definition, and / or terminology used in this disclosure, the description, definition, and / or terminology used in this disclosure shall prevail.

[0121] Finally, it should be understood that the embodiments of the applications disclosed herein are illustrative of the principles of the embodiments of this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments described herein. Therefore, the embodiments described herein are not limited to the embodiments precisely described in the applications. Specification 15 / 15 pages 18 CN 121412970 A Figure 1 Figure 2 Specification Drawings 1 / 8 pages19 CN 121412970 A Figure 3 Appendix 2 / 8 of the specification 20 CN 121412970 A Figure 4 Appendix 3 / 8 of the specification 21 CN 121412970 A Figure 5 Figure 6 Appendix 4 / 8 of the specification 22 CN 121412970 A Figure 7 Figure 8 Appendix 5 / 8 of the specification 23 CN 121412970 A Figure 9 Appendix 6 / 8 of the specification 24 CN 121412970 A Figure 10 Figure 11 Appendix 7 / 8 of the specification 25 CN 121412970 A Figure 12 Appendix 8 / 8 of the specification 26 CN 121412970 A Abstract Abdominal ultrasound examination method, system and device Account management method, server and storage medium The embodiment of the invention provides an account management method, a server and a storage medium. In the method, an account group creation request sent by a terminal device is received, and the account group creation request comprises identifiers of a plurality of accounts and a target account group type; creating a target account group containing the plurality of accounts based on the target account group type, and determining intra-group identities of the plurality of accounts in the target account group; generating description data of the target account group based on thegroup identities of the plurality of accounts in the target account group, and storing the description data of the target account group in a preset storage space; wherein the target account group type is specified by an operator of the terminal device from a plurality of candidate account group types.

Claims

1. An account management method, comprising: The terminal device receives an account group creation request, which includes identifiers of multiple accounts and a target account group type, wherein the target account group type is specified by the operator of the terminal device from multiple candidate account group types. Create a target account group containing the multiple accounts based on the target account group type, and determine the identities of the multiple accounts within the target account group; and Based on the identities of the multiple accounts within the target account group, description data of the target account group is generated, and the description data of the target account group is stored in a preset storage space, which is used to store description data of different account groups.

2. The method according to claim 1, wherein, Different candidate account group types support different identity systems within the group.

3. The method according to claim 2, wherein, The multiple candidate account group types include at least two of the following: The first candidate account group type supports a first-level identity system with equal-level identities; The second candidate account group type supports a two-tier identity system with primary and secondary identities; or The third candidate account group type supports a three-tier identity system of super-primary identity, primary identity, and sub-identity.

4. The method according to claim 1, wherein, The plurality of accounts includes a first account, the first account having a unique identity within the target account group, and the first account having a polymorphic identity within different account groups.

5. The method according to claim 1, wherein, The step of creating a target account group containing the multiple accounts based on the target account group type, and determining the identity of the multiple accounts within the target account group, includes: Obtain the account group creation strategy corresponding to the target account group type. The account group creation strategy represents the conditions that each account in the account group to be created must meet, and the method for assigning identities within the group to each account; and The target account group is created based on the account group construction strategy, and the identities of the multiple accounts within the target account group are determined.

6. The method according to claim 1, wherein, The descriptive data for the target account group includes: Group-level description data, used to describe the configuration information of the target account group; and Account-level descriptive data is used to describe the affiliation of the multiple accounts with the target account group and their identity information within the group.

7. The method according to claim 1, wherein, The method is applied to a first server, and the plurality of accounts includes: a first account registered on the first server, and a second account registered on a second server. Storing the description data of the target account group into a preset storage space includes: The description data of the target account group is stored in the local storage space of the first server; and The description data of the target account group is synchronized with the second server so that the description data of the target account group is stored in the local storage space of the second server.

8. The method according to claim 7, wherein, The first server integrates a first middleware, and the second server integrates a second middleware. Both the first middleware and the second middleware have persistent storage and caching functions. The description data of the target account group is stored in the local storage space of the first server, including: The description data of the target account group is stored in the local database of the first server and synchronized to the first middleware; Synchronizing the description data of the target account group with the second server includes: The first middleware synchronizes the description data of the target account group to the second middleware.

9. The method according to claim 8, wherein, The method further includes: In response to receiving a first query request corresponding to the target account group from the requesting device, the description data of the target account group is queried from the first middleware, and the description data of the target account group is returned to the requesting device.

10. The method according to claim 9, wherein, The requesting device is the second server, and the first query request is sent by the second server when it cannot find the description data of the target account group in the second middleware.

11. The method according to claim 8, wherein, The method further includes: In response to receiving a second query request corresponding to the target account group from the requesting device, the description data of the target account group is queried from the local database of the first server, and the description data of the target account group is returned to the requesting device.

12. The method according to claim 1, wherein, The account group creation request also includes the task type associated with the account group to be created, and the method further includes: A target task is created based on the task type, and the triggering conditions and execution strategy of the target task are determined; and In response to the detection of the triggering condition, the target task is executed within the target account group according to the execution strategy.

13. The method according to claim 12, wherein, Each account in the target account group is responsible for managing resources. The target task is to transfer resources between different accounts in the target account group.

14. The method according to claim 12, wherein, The method further includes: Obtain authorization information between different accounts in the target account group, wherein the authorization information represents the authorization status for resource transfer; Creating a target task based on the task type includes: The target task is created based on the task type and the authorization information between different accounts in the target account group.

15. A server, comprising: At least one storage medium storing at least one instruction set; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and performs the method as described in any one of claims 1-14 according to the instructions of the at least one instruction set.

16. A computer-readable non-transitory storage medium, wherein, The computer-readable non-transitory storage medium stores at least one set of instructions, which, when executed by at least one processor, implement the method as described in any one of claims 1-14.

Images