WO2025236933A1 - Group display method and apparatus in application program, and storage medium and computer program product - Google Patents

Abstract

Provided in the present application are a group display method and apparatus in an application program, and a storage medium and a computer program product. The method comprises: displaying a first page in an application program, wherein the first page includes a target group name of a target group, the target group name is provided with a link mark for an entry link to the target group, and the entry link is created by a second object in the target group and is associated with the target group name of the target group upon being created; in response to a hovering operation triggered around the target group name, displaying basic information of the target group; and in response to the link mark being triggered, displaying a dialog page of the target group.

Description

Group display methods, devices, storage media, and computer program products in applications

Cross-reference to related applications

This application is based on and claims priority to Chinese Patent Application No. 202410602103.9, filed on May 15, 2024, the entire contents of which are incorporated herein by reference.

Technical Field

This application relates to the field of data processing technology, and in particular to a group display method, apparatus, storage medium, and computer program product in an application.

Background Technology

In applications, users are often divided into groups. When managing groups within an application, users can either enter the group name in a fixed search area to find the target group, or directly access the group via a group link (e.g., a message from another user containing a link to the target group). In the latter method, users only see the link and must click it to learn about the group and its basic information. This results in low efficiency in group management and information delivery.

Summary of the Invention

This application provides a group display method, apparatus, storage medium, and computer program product in an application, which can improve information transmission efficiency.

According to one aspect of the embodiments of this application, a group display method in an application is provided, applied to a terminal of a first object, the method comprising:

The application displays a first page containing the target group name of the target group, the target group name having a link tag for an entry link of the target group, the entry link being created by a second object in the target group and associated with the target group name of the target group at the time of creation;

In response to a dwell action triggered around the target group name, basic information about the target group is displayed;

In response to a trigger on the link tag, the session page for the target group is displayed.

According to one aspect of the embodiments of this application, a group display device in an application is provided, applied to a terminal of a first object, the device comprising:

The first display module is configured to display a first page in the application, the first page containing the target group name of the target group, the target group name having a link tag for an entry link of the target group, the entry link being created by a second object in the target group and associated with the target group name of the target group at the time of creation;

The second display module is configured to display basic information about the target group in response to a dwell operation triggered around the target group name;

The third display module is configured to display the session page of the target group in response to a trigger on the link tag.

According to one aspect of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the group display method in the application described above.

According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the group display method in the application described above.

According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the group display method in the application described above.

In this embodiment, when a user (the terminal of the first object) accesses a first page with a group link (entry link), the group link on the first page is displayed as the target group name with a link marker. At this time, the user can intuitively know which group this entry link represents, making the entry link created and shared by the second object more concrete. Furthermore, this embodiment also sets up automatic display of the target group's basic information when the user hovers around the target group name. This allows the user to preview the basic information of the target group without triggering the entry link and opening the target group's conversation page. By previewing the basic information, the user can understand what kind of group it is and determine whether they want to enter the group's conversation page. Finally, when the user decides to enter the group's conversation page, triggering the link marker on the first page to enter the target group's conversation page improves the efficiency of group information transmission.

Other features and advantages of the embodiments of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the embodiments of this application. The objects and other advantages of the embodiments of this application may be realized and obtained by means of the structures particularly pointed out in the description, claims, and drawings.

Attached Figure Description

The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

Figure 1 is a system architecture diagram of the group display method applied in an application according to an embodiment of this application;

Figures 2A-2D illustrate schematic diagrams of the group display method in an application according to an embodiment of the present application, applied in a scenario where group display is triggered based on a session group;

Figures 2E-2H illustrate schematic diagrams of the group display method in an application according to an embodiment of this application being applied in a scenario where group display is triggered based on announcement information;

Figure 3 is a flowchart of a group display method in an application according to an embodiment of this application;

Figures 4A and 4B are schematic diagrams illustrating the implementation process of enabling and disabling name display on a terminal of a first object according to an embodiment of this application;

Figures 5A-5C are schematic diagrams illustrating the implementation process of displaying an entry link as a target group name with a link tag according to an embodiment of this application;

Figures 6A-6C are schematic diagrams illustrating the implementation process of displaying entry links as target group names with link tags according to object preferences in one embodiment of this application;

Figure 7 is a schematic diagram illustrating the implementation process of displaying an entry link as a target group name with a link tag according to an embodiment of this application;

Figure 8 is a flowchart of a terminal that determines a target group including a first object according to an embodiment of this application;

Figure 9 is a flowchart of a session page displaying a target group according to an embodiment of this application;

Figures 10A and 10B are schematic diagrams illustrating the implementation process of displaying a session page for a target group according to an embodiment of this application;

Figure 11 is a flowchart of a session page displaying a target group according to another embodiment of this application;

Figure 12 is a flowchart of generating an authorization response according to an embodiment of this application;

Figures 13A-13C are schematic diagrams illustrating the implementation process of displaying a session page for a subgroup according to an embodiment of this application;

Figure 14 is an overall flowchart of a session page displaying a target group according to an embodiment of this application;

Figure 15 is a flowchart of creating an entry link according to an embodiment of this application;

Figure 16 is a flowchart of determining whether a group string satisfies a first condition according to an embodiment of this application;

Figure 17 is a schematic diagram of the structure of a predetermined relationship lookup table according to an embodiment of this application;

Figures 18A and 18B are schematic diagrams illustrating the implementation process of creating an entry link according to an embodiment of this application;

Figure 19 is an overall flowchart of creating an entry link according to an embodiment of this application;

Figure 20 is a flowchart of creating an entry link according to another embodiment of this application;

Figures 21A and 21B are schematic diagrams illustrating the implementation process of creating an entry link according to another embodiment of this application;

Figure 22 is a flowchart of a second verification of subgroup links according to an embodiment of this application;

Figure 23 is a flowchart of determining the subgroup links of each target subgroup according to an embodiment of this application;

Figure 24 is a flowchart of determining the subgroup links of each target subgroup according to another embodiment of this application;

Figures 25A and 25B are schematic diagrams illustrating the implementation process of determining subgroup links of each target subgroup according to another embodiment of this application;

Figure 26 is an overall flowchart of creating an entry link according to another embodiment of this application;

Figure 27 is a flowchart of displaying an entry link as a target group name with a link marker according to an embodiment of this application;

Figure 28 is an overall flowchart of displaying group name and basic group information according to another embodiment of this application;

Figure 29 is a schematic diagram illustrating the implementation details of a group display method in an application according to an embodiment of this application;

Figure 30 is a block diagram of a group display device in an application according to an embodiment of this application;

Figure 31 is a terminal structure diagram of a group display method in an application according to an embodiment of this application;

Figure 32 is a server structure diagram of a group display method in an application according to an embodiment of this application.

Detailed Implementation

To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

Before providing a detailed description of the embodiments of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

An application is a software program that runs on a computer or mobile device and is designed to provide users with specific functions or services. In this embodiment, the application's homepage displays the names of multiple target groups, each accompanied by a link pointing to an entry point to that group. These entry points are created by a secondary object within the group (such as an administrator or designated user) and associated with the group name. When a user hovers over a group name, the application displays basic information about the group, such as its description and number of members. If the user triggers a link, the application redirects to the group's session page, enabling the user to communicate and interact with other members within the group.

System architecture and scenario description used in the embodiments of this application

Figure 1 is a system architecture diagram of the group display method in an application according to an embodiment of this application. It includes an object terminal 140, an Internet 130, a gateway 120, an application server 110, etc.

The target terminal 140 includes various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. The target terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data. The target terminal 140 has an application platform for various target terminals to perform social activities, resource interaction, and information exchange.

Application server 110 refers to a computer system that can provide certain services to object terminal 140. Compared to ordinary object terminal 140, application server 110 has higher requirements in terms of stability, security, and performance. Application server 110 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines). Application server 110 contains various types of services, and the implementation of each service of application server 110 is often associated with some intermediate database or storage medium. Application server 110 is used to create links to at least one group based on a group link creation operation of an object terminal, and determine the method of displaying group links to other object terminals. Application server 110 is also used to display group information or group session windows based on the interactive operations of other object terminals.

Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from target terminal 140 to application server 110 are forwarded to the corresponding server via gateway 120. Messages sent from application server 110 to target terminal 140 are also forwarded to the corresponding target terminal 140 via gateway 120.

The embodiments of this application can be applied in various scenarios, such as the scenario of triggering group display based on session group as shown in Figures 2A-2D, and the scenario of triggering group display based on announcement information as shown in Figures 2E-2H.

As shown in Figure 2A, in the "Basketball Interest Group" group on the application platform, the group members are Object 1, Object 2, and Object 3. At this time, Object 1 sends a session message "https://example.com/group?token=K77qzd" on the Basketball Interest Group's session page. The session message is a group link of Group A shared by Object 1.

As shown in Figure 2B, the group members are Object 1, Object 2, and Object 3. When Object 3 logs into the application platform and opens the basketball interest group's chat page, the group link previously sent by Object 1 will be displayed as a group name with a link marker, which is "Badminton Interest Group". Object 2's previously sent "Received" message will also display the link marker, which refers to the interactive underline located below the group name "Badminton Interest Group".

As shown in Figure 2C, the group members are Object 1, Object 2, and Object 3. When Object 3 hovers the mouse over "Badminton Interest Group" in the basketball interest group's chat page, a tooltip window will appear on the chat page. This tooltip window will display information such as "Group members: 10; Already joined: Yes; Group owner's nickname: xxx1". Based on this, Object 3 clicks on the group name "Badminton Interest Group" and triggers the link to open the badminton interest group's chat page.

As shown in Figure 2D, the group members include object 3, object 11, object 3 and object 4. When object 3 double-clicks the group name "Badminton Interest Group" and triggers the link tag, a new session window will be displayed in the application platform. This session window is the session page of the Badminton Interest Group.

Figures 2A-2D above illustrate the display and preview of group links shared by various objects in the application's session page. This allows objects to know the names of groups shared by other objects within the session page, and to learn the basic information of the group without entering the group's session page. Furthermore, users can directly navigate to the group's session page based on the group link, improving the efficiency of group search.

Figure 2E shows the application announcement page of the application platform. The page displays multiple announcements posted at different times and by different individuals. Announcement 1 includes a link "https://example.com/group?token=K77qzd", Announcement 2 includes a text message "Xxxxxxx" and a link "https://example.com/group?7895", and Announcement 3 includes two images, Image 1 and Image 2. The link in Announcement 1 conforms to the format requirements for group links, indicating entry to group A. However, the link in Announcement 2 does not meet the format requirements for group links and is a regular link.

As shown in Figure 2F, when an object opens the application announcement bar on the application platform, the application announcement bar page will display three announcements. Among them, the link information of announcement 1 is displayed as the group name of group A with a link mark. The group name of group A is "Badminton Interest Group"; announcement 2 is still displayed as a text message "Xxxxxxx" and a link message "https://example.com/group?7895"; announcement 3 is still displayed as an image message consisting of image 1 and image 2.

As shown in Figure 2G, when the object hovers the mouse over "Badminton Interest Group" in Announcement 1 of the application's announcement bar, a tooltip will appear in the application's announcement bar, displaying information such as "Group members: 10; Already joined: Yes; Group owner's nickname: xxx1". Based on this, the object clicks on the group name "Badminton Interest Group" and triggers the link to open the Badminton Interest Group's session page.

As shown in Figure 2H, when the object double-clicks the group name "Badminton Interest Group" and triggers the link tag, a session window will be displayed on the application's announcement page. This session window is the Badminton Interest Group's session page.

Figures 2E-2H above illustrate the display and preview of group links shared by various objects on the group announcement page of the application. This allows objects to know the group name indicated by the group link in the announcement page and to know the basic information of the group without entering the group's session page.

In summary, the group display method of this application embodiment satisfies the need to preview group information related to group links shared by other objects in multiple scenarios such as chat windows, group announcements, documents, or favorite content, making the display scenarios of group information more diverse. Furthermore, the group display method of this application embodiment provides sharing and preview functions for groups, which can effectively improve the efficiency of group information transmission.

General description of the embodiments of this application.

According to one embodiment of this application, a group display method in an application is provided, applied to the terminal of a first object.

The group display method in this application is commonly used in scenarios such as group sharing and group display in general applications, such as the group display scenarios shown in Figures 2A-2D and 2E-2H. This application embodiment provides a solution based on setting entry links for each group, allowing users to preview group information before joining, thereby improving information transmission efficiency.

As shown in Figure 3, a group display method in an application according to an embodiment of this application may include:

Step 310: Display the first page in the application. The first page contains the target group name of the target group. The target group name has a link tag for the entry link of the target group. The entry link is created by the second object in the target group and is associated with the target group name of the target group when it is created.

Step 320: In response to a dwell action triggered around the target group name, display basic information about the target group;

Step 330: In response to a trigger on a link tag, display the session page for the target group.

Steps 310-330 are described in detail below.

In step 310, a first page is displayed in the application. The first page contains the target group name of the target group, which has a link tag for the target group's entry link. The entry link is created by a second object of the target group and is associated with the target group name of the target group when it is created.

The first page is a content page within the application. It contains entry links to the target group.

A target group refers to a group of objects that have been successfully registered in an application and possess the same or similar characteristics. For example, a target group can be a group of multiple objects with the same interests or hobbies, or a group of multiple objects performing the same task.

An entry link is a string consisting of a fixed-format string and a random string corresponding to each group. Entry links are used to link to the target group's session page, allowing objects to quickly navigate to or access the target group's session page.

The second object is another object terminal that has been successfully registered in the application and is distinct from the first object terminal.

The target group name is used to indicate the title content of the target group and is used to distinguish the target group from other groups.

Link tags are used to provide an object with an entry link to trigger the target group, allowing it to access or join the target group's session page.

In some embodiments, within the application, the first page is a content page containing the target group name. This name is a link marker pointing to an entry link created by a second object of the target group and associated with the target group name upon creation. A target group refers to a group of object terminals that have successfully registered in the application and possess the same or similar characteristics. For example, a target group could be a group of multiple objects with the same interests or hobbies, or a group of multiple objects performing the same task.

In some embodiments, the entry link is a string consisting of a fixed-format string and random strings corresponding to each group. Its function is to link to the target group's session page, enabling the object to quickly navigate to or access the target group's session page. The second object is another object terminal that has been successfully registered in the application and is distinct from the first object. The target group name indicates the target group title content and distinguishes the target group from other groups. The link tag provides the object with an entry link to trigger the target group, allowing it to access or join the target group's session page.

As an example, in a social media application, the first page could be a news feed page containing the target group names of the groups the user follows. These names have entry links, created by the group's administrator (the second object) and associated with the group name upon creation. The first page is a content page within the application containing entry links to the groups. Groups can be interest groups composed of users with similar interests or project groups composed of users performing the same task. The entry link is a string consisting of a fixed-format string and a random string corresponding to each group. Its purpose is to link to the group's session page, allowing users to quickly navigate to or access the group's session page. The second object is another object terminal that has been successfully registered in the application and is distinct from the first object. The group name indicates the group's title content and distinguishes it from other groups. The link tags provide users with entry links to the group to access or join its session page.

For example, a link tag could be an underscore below the group name, or a graphical interactive control before or after the group name.

In this specific implementation, when the terminal of the first object accesses the application and opens any content page in the application, the server, with authorization, will display the content page that the terminal of the first object wants to access as the first page in the application. The first page may include text, images, videos, or entry links to target groups, etc.

In some embodiments, since the display format of the entry link in the first page is retained when the object browses the first page, directly displaying the entry link would still prevent the object from intuitively understanding what kind of group the entry link indicates. Therefore, when the server determines that the entry link in the first page was created by a second object of the target group and associated with the target group name at creation time, the entry link is displayed as the target group name with a link tag in the first page of the application. This ensures that the first page seen by the first object's terminal includes the target group name, which has a link tag for the target group's entry link. This allows the object to intuitively understand what kind of group the entry link indicates based on the target group name, and provides a link tag for the object to trigger and access the group's session page.

To save space, the specific process of creating the entry link and displaying the entry link as the target group name with the link tag in the embodiments of this application will be described in detail below, and will not be repeated here.

Thus, displaying the first page in the application, containing the target group's name and entry link, significantly improves user convenience for participating in group activities by providing an intuitive and easily accessible interface. The link to the target group name not only clearly identifies the group's theme and purpose but also simplifies user navigation to the group session page through a directly linked entry link. This design, based on behavioral analysis and interface design principles, enhances user experience by reducing the complexity and time required for user operations. The combination of a fixed format and random strings for the entry link ensures its security and uniqueness, preventing unauthorized access and facilitating the detection and management of group access traffic. The participation of a second object in creating the entry link increases the flexibility of social interaction and management within the group, allowing it to better adapt to the needs and preferences of different users. Overall, this design, through careful technical arrangement, optimizes the user interface and enhances social interaction, thereby increasing the application's attractiveness and user satisfaction.

In step 320, in response to a dwell action triggered around the target group name, basic information about the target group is displayed.

In some embodiments, a dwell operation triggered around a target group name refers to a dwell operation triggered in a target area of the first page. The target area is an area on the first page where the distance between the display position of the target group name and the target group name is less than a distance threshold. The basic information is used to prompt the first object whether to trigger the link tag.

A target object refers to an object used to interact with the application's pages. Examples include a mouse, a stylus, or a user's finger.

The area surrounding the target group name refers to the region that the server can sense and confirm as valid for the target object's stay operation.

In some embodiments, within the application, a first page contains the name of the target group, surrounded by a specific target area. When a user hovers over the target area on the first page using a target object (such as a mouse, stylus, or finger), the application responds by displaying basic information about the target group. This basic information is intended to prompt the user whether they should trigger a link to access or join the target group's session page.

In some embodiments, the target area is defined based on the display location of the target group name. Specifically, it is the area whose distance from the name's display location is less than a preset distance threshold. This distance threshold is set by the application developer based on user experience and design requirements to ensure that users can easily obtain basic information about the group when operating near the target group name.

In some embodiments, when a user's target object stays in the target area for a certain period of time (usually set by the application), the application detects this stay and triggers the display of basic information about the target group. This information may include the group's description, number of members, latest activities, etc., to help the user understand the group's content and activity level, thereby deciding whether to visit or join the group.

As an example, the first page is a dynamic news feed displaying the names of various groups the user follows. Each group name is surrounded by a target area; when the user hovers their mouse over this area, the application displays basic information about the group. For instance, if the user hovers their mouse near the "Photography Enthusiasts" group name, a tooltip pops up displaying the group's description (e.g., "Welcome all photography enthusiasts to join, share your photos, and exchange photography tips."), current number of members (e.g., "5000+ members"), and the group's latest activity (e.g., "Latest photo sharing: Beautiful sunset photos"). This basic information helps users quickly understand the group's content and activity level, deciding whether to click the group name link to join or view more details. This design not only improves the user experience but also increases group visibility and attractiveness, encouraging users to participate in more social activities. Simultaneously, it reduces the likelihood of users accidentally clicking on group names, enhancing application usability and user satisfaction.

For example, the area surrounding the target group name, i.e., the target region, can be defined as the rectangular region formed by extending the four sides of the outer rectangle of the target group name outward at equal distances.

A dwell operation refers to keeping a target object in its current position for a certain period of time. Dwell operations include, but are not limited to, hovering and long-pressing.

The basic information of the target group is used to indicate the specific content of the target group. For example, the number of group members, the group type, the group creation date, and who has administrative privileges in the group are all within the scope of the basic information of the target group.

In some embodiments, the basic information about a target group consists of key data about the group, providing an overview and basic attributes. This information typically includes the number of group members, reflecting the group's size and activity level; the group type, such as an interest group, work team, or study group, which helps users understand the group's nature and purpose; the group's creation date, which shows how long the group has existed and sometimes reflects its maturity and stability; and the individuals with administrative privileges within the group, identifying the group's administrators or leaders responsible for maintaining group order and managing group content. This basic information is very useful to users because it helps them quickly assess whether they want to join or participate in a particular group, while also providing group administrators with the essential information needed to manage the group.

In this specific implementation, for interactive purposes, the terminal of the first object can control the target object to stay at any position on the application's interface. Therefore, when the terminal of the first object sees a target group name displayed with a link tag in the application, the terminal of the first object can control the target object to stay around the target group name, allowing the server to detect the target object's position. Then, the server will obtain the target object's position on the application's interface.

In some embodiments, the server identifies whether the target object's location is within the range of a predefined target group name, until the target object stays around the target group name for a predetermined time. The server then extracts the basic information of the target group and displays it in the application's interface in the form of a message window, so that the terminal of the first object can understand what kind of group the target group is without joining the target group.

Thus, within the application, when a user hovers over a target area on the first page, the system displays basic information about the target group. By providing a detailed overview of the group, users can quickly understand its content and nature without leaving the current page. This not only improves the user experience and reduces the need for users to switch between different pages, but also increases the likelihood of user participation in group activities. This interaction method also improves information visibility, enabling group administrators to manage groups more effectively, while also helping to prevent accidental clicks, thus enhancing application usability and user satisfaction.

In step 330, in response to a trigger on a link tag, the session page for the target group is displayed.

A conversation page refers to a window for members of a target group to communicate and exchange information.

In this specific implementation, when an object wants to access a target group, the object triggers a link marker in the application. Based on this, the server receives the object's trigger operation on the link marker, displays the target group's session page in the application, so that the object can view the session content of each member of the target group and communicate with each member of the target group in the session page.

In some embodiments, when a user triggers a link next to the target group name on the application's homepage, the application responds by displaying the target group's conversation page. This conversation page is a specially designed window for group members to engage in real-time or asynchronous conversational communication. In a specific implementation, when a user wants to access the target group, they click or tap the link in the application. Once the user triggers the link, the application sends this action to the server. Upon receiving the trigger, the server retrieves the conversation page data for the target group associated with that link. This data may include a list of group members, historical conversation records, the status of currently online members, etc. The server sends this data back to the application, which renders the target group's conversation page on the user's device. The user can now view the group members' conversation content on this page, including both the latest messages and historical records. Furthermore, users can enter their own messages on the conversation page to communicate with other group members in real time.

To save space, the specific process of displaying the session page of the target group in this embodiment of the application will be described in detail below, and will not be repeated here.

Through steps 310-330 above, in this embodiment of the application, when a user (the terminal of the first object) accesses a first page with a group link (entry link), the group link on the first page is displayed as the target group name with a link marker. At this time, the user can intuitively know which group this entry link represents, making the entry link created and shared by the second object more concrete. In addition, in this embodiment of the application, when the user hovers the target object (mouse, stylus, etc.) around the target group name, the basic information of the target group is automatically displayed to the user. This allows the user to preview the basic information of the target group without triggering the entry link and opening the target group's conversation page. By previewing the basic information of the target group, the user can understand what kind of group it is and thus determine whether to enter the group's conversation page. Finally, when it is determined to enter the group's conversation page, triggering the link marker on the first page to enter the target group's conversation page can improve the efficiency of group information transmission.

The above is a general description of steps 310-340. The specific implementations of steps 310, 320, and 330 will be described in detail below.

Detailed description of step 310

In step 310, a first page is displayed in the application. The first page contains the target group name of the target group, which has a link tag for the target group's entry link. The entry link is created by a second object in the target group and is associated with the target group name of the target group when it is created.

Since the security levels of various objects within an application differ, directly displaying the entry link as the target group name with a link tag might compromise the security of some more private groups within the application. Therefore, this application provides a scheme that controls the display format of entry links based on the settings of a second object during its creation. This improves the diversity of entry link display and thus enhances information display security.

In some embodiments, the first page in the application is typically a content-rich page containing the names of multiple target groups. Each name is accompanied by a link marker for an entry point, which users can click or tap to access the corresponding group session page. These entry points are created by a second entity within the group (typically a group administrator or creator) and are associated with the group name at creation time. However, given the potential for varying security levels across different entities within the application, particularly for more private groups, directly displaying the entry point as the target group name with the link marker could pose security risks. For example, this could make it easier for unauthorized users to discover and join these private groups, potentially leading to the leakage of sensitive information or compromise of group privacy.

In some embodiments, this application proposes a scheme to control the display format of the entry link based on the settings of a second object during its creation. Specifically, group administrators can choose different entry link display formats according to the group's privacy settings and security requirements. For example, they can choose to hide the entry link, displaying it only after specific operations or permission verification; or they can choose to display the entry link in an encrypted or obfuscated form to reduce the risk of it being discovered by unauthorized users. This scheme increases the diversity of entry link display, allowing group administrators to flexibly control the visibility and access methods of the entry link according to different group needs and security conditions. Furthermore, this also helps to improve the security of information display and protect the privacy and security of group members. In this way, the application can ensure the security and privacy of the group while providing convenient group access functions.

In some embodiments, the target group name of the first page in step 310 is determined in the following way:

If the entry link is created by a second object of the target group, is associated with the target group name at creation, and name display is enabled for the first object's terminal, then the link tag of the entry link will be constructed as the target group name.

Enabling name display means that when the first page is displayed to the terminal of the first target, the entry link is displayed as the target group name with a link tag, while disabling name display means that when the first page is displayed to the terminal of the first target, the entry link is displayed in its original link form.

In this specific implementation, when the second object creates an entry link for the target group and associates the entry link with the target group name, it is desired that the target group name is only visible to certain fixed object terminals. The second object can add the terminal name or terminal identifier of each object terminal that can directly view the target group name through the entry link in the name display enable editing area of the entry link creation settings interface. Based on this, when the terminal name or terminal identifier of the first object's terminal is added to the name display enable editing area, when the first object's terminal accesses the first page, the entry link on the first page will directly display the target group name with the link marker, instead of the original form of the entry link. When the terminal name or terminal identifier of the first object's terminal is not added to the name display enable editing area, when the first object's terminal accesses the first page, the entry link on the first page will retain its original display form and will still be displayed as a link.

In some embodiments, within an application, when an entry link is created by a second object (such as a group administrator) of the target group, the second object can choose during the creation process whether to enable name display for the first object's terminal. If name display is enabled, the entry link's link marker will be constructed as the target group name. This means that when the first object views the first page on their terminal, they will see a group name with a link marker, instead of the original link format. The second object can specify which terminal names or identifiers are allowed to see the group name in the entry link creation settings interface. These terminal names or identifiers are typically associated with specific users or devices. If the first object's terminal name or identifier is added to the edit area for enabling name display, the entry link will be displayed as the target group name with a link marker when the first object accesses the first page, and can be directly clicked or touched to access the group session page. Conversely, if the first object's terminal name or identifier is not added to the edit area for enabling name display, the entry link will retain its original link format and be displayed as a regular link instead of the group name. This design allows group administrators to control which users or devices can access the group in a more intuitive way, thereby improving the display diversity of entry links and the security of information display. The application can flexibly control the display format of the entry link according to the group administrator's settings, which not only ensures the privacy and security of the group, but also provides a more convenient and intuitive way for specific users to access the group.

As an example, as shown in Figure 4A, when Object 1 created the entry link "https://example.com/group?token=7qe31a5" for the tennis interest group, it did not enable name display for Object 3. At this time, when Object 3 accesses the basketball interest group's session page, the content sent by Object 1 displayed on the session page is just a simple link message "https://example.com/group?token=7qe31a5," and Object 3 cannot directly understand what this link message indicates.

As an example, as shown in Figure 4B, when Object 1 creates the entry link for the tennis interest group "https://example.com/group?token=7qe31a5", it enables name display for Object 3. At this time, when Object 3 accesses the basketball interest group's chat page, the content sent by Object 1 is displayed on the chat page as the group name of the tennis interest group with the linked tag. Object 3 can directly know that Object 1 shared a link to join the tennis interest group. Based on this, Object 3 can choose whether to join the tennis interest group through this linked group name according to its own needs.

As an example, suppose there's a group called "Photography Enthusiasts." The group administrator (the second object) creates an entry link and associates it with the group name. The administrator wants only specific user devices to see the group name, while other users only see the raw link. In the entry link creation settings, the administrator adds the device names or device identifiers of the user devices allowed to view the group name in the "Enable Name Display" edit area. For example, the administrator adds the device identifiers of users A and B. When users A and B access the application's first page, they will see the group name "Photography Enthusiasts" with a link next to it. They can click or tap the name to directly access the group's session page. If user C's device name or identifier is not added to the "Enable Name Display" edit area, then when user C accesses the first page, they will only see a regular link instead of the group name. User C needs to click the link to access the group's session page. This allows the group administrator to control which users can access the group in a more intuitive way while maintaining the group's privacy and security. Authorized users can more easily join and participate in group activities; while unauthorized users need to take additional steps to access the group, which helps protect the group's privacy and security.

The advantage of this embodiment is that the display format of the entry link is controlled according to the settings of the second object during its creation. When the terminal of the first object is set by the second object to have its name displayed, the terminal of the first object will directly receive the target group name indicated by the entry link when accessing the first page, thus understanding the meaning of the entry link more intuitively. When the terminal of the first object is not set by the second object to have its name displayed, the entry link seen when accessing the first page is just an ordinary link, and its meaning cannot be intuitively understood. This method can improve the display diversity of entry links, thereby improving the security of information display.

Since different objects within an application have varying levels of understanding and needs regarding the target group, displaying the target group name in a fixed format on the first page often results in limited flexibility in group display. Therefore, this application provides a scheme that uses different target group names to indicate the same group for different objects, thereby improving the flexibility of group information display.

In some embodiments, the target group name of the first page in step 310 is determined in the following way:

The group name specified by the second object for the terminal of the first object when creating the entry link is determined as the target group name corresponding to the terminal of the first object, wherein the second object specifies different group names for different object terminals when creating the entry link.

In this specific implementation, when the second object creates an entry link for the target group and associates the entry link with the target group name, the target group is set to be displayed to different objects with different linked target group names via the entry link. Simultaneously, the target group name seen by each object is defined, assigning different target group names to different object terminals. Based on this, when the first object's terminal accesses the first page, the entry link is displayed with the target group name corresponding to the first object's terminal, according to the second object's settings.

In some embodiments, when a second object (such as a group administrator) creates an entry link in the application, they can specify different group names for different object terminals. This means that when different users access the first page, the group names they see may differ, depending on the settings of the second object. In the settings interface for creating the entry link, the second object can specify a unique group name for each object terminal. For example, the second object can specify "Photography Club" for user A's terminal and "Photography Community" for user B's terminal, even though both names point to the same target group. When the first object's terminal accesses the first page, the application will display the entry link with the target group name corresponding to the first object's terminal, based on the second object's settings. For example, if the first object is user A, they will see the group name "Photography Club" with a link on the first page; if the first object is user B, they will see the group name "Photography Community" with a link. This allows group administrators to flexibly display group names based on different users or devices, thereby improving user experience and group attractiveness. It also provides group administrators with a personalized way to interact and communicate with different user groups. In this way, the application can better meet the needs and preferences of different users, and enhance user engagement and satisfaction.

It should be noted that when specifying different target group names for different object terminals, the second object can be set so that each object has a different target group name, making the target group names seen by different objects completely different, or different group names can be set according to groups, so that the target group names seen by each object in a group are the same, but the target group names seen by objects in different groups are different.

As shown in Figure 5A, when Object 1 creates an entry link for a tennis interest group, it configures the display settings for this entry link on the application platform. In the display settings page, the entry link for the tennis interest group is set to "https://example.com/group?token=7qe31a5". Next, Object 1 sets the group name displayed to members through the tennis interest group's entry link to be "Tennis Enthusiasts Alliance"; and the group name displayed to members to be "Tennis Exchange Group".

As shown in Figure 5B, the group members include Object 1, Object 2, and Object 3. Object 2 is not a member of the tennis interest group. When Object 2 accesses the conversation page of the basketball interest group, the content sent by Object 1 displayed on the conversation page is the group name of the tennis interest group with a link tag. At this time, the group name with the link tag is "Tennis Exchange Group".

As shown in Figure 5C, the group members include Object 1, Object 2, and Object 3. Object 3 is a group member of the tennis interest group. When Object 2 accesses the conversation page of the basketball interest group, the content sent by Object 1 displayed on the conversation page is the group name of the tennis interest group with a link tag. At this time, the group name with a link tag is "Tennis Enthusiasts Alliance".

As an example, suppose there's a group called "Fitness Enthusiasts." The group administrator (the second object) creates an entry link and associates it with the group name. The administrator wants to assign different group names to different user devices based on users' interests and preferences. In the settings interface for creating the entry link, the administrator can assign a unique group name to each user device. For example, the administrator can assign "Yoga Enthusiasts" to user devices that like yoga, "Strength Training Fanatics" to user devices that like strength training, and "Aerobics Enthusiasts" to user devices that like cardio, even though all three names point to the same target group. When user A (who likes yoga) accesses the application's homepage, they will see the group name "Yoga Enthusiasts" with a link. User A can click or tap this name to directly enter the group's conversation page. When user B (who likes strength training) accesses the homepage, they will see the group name "Strength Training Fanatics" with a link. User B can click or tap this name to directly enter the group's conversation page. When user C (who enjoys aerobic exercise) visits the first page, they will see the group name "Aerobic Exercise Enthusiasts" with a link. User C can click or tap this name to directly enter the group's chat page. This design allows group administrators to flexibly display the group name based on users' interests and preferences, thereby improving user experience and group attractiveness. It also provides group administrators with a personalized way to interact and communicate with different user groups. In this way, the application can better meet the needs and preferences of different users, enhancing user engagement and satisfaction.

The advantage of this embodiment is that when the second object creates the entry link for the target group, it provides a channel to set different target group names for different object terminals, so that the second object can specify different target group names for different objects as needed, and use different target group names to indicate the same group for different objects, which can improve the flexibility of group display information.

Because different objects have different preferences for group naming—for example, some objects prefer to display group names in a concise way, while others prefer to display them in a more specific way—and because different objects also have different preferences for the font, font size, and other formats of the group names, some groups require the group names to be displayed in a larger font size to help this group clearly identify which group the group name refers to, this application provides a scheme that allows the display format of entry links to be controlled according to the object's preferences when the second object is created. This makes the displayed target group names more in line with the preferences of each object, improving the display diversity of entry links.

In some embodiments, the target group name of the first page in step 310 is determined in the following way:

The candidate group name that corresponds to the first object preference of the terminal of the first object among the multiple candidate group names is determined as the target group name, wherein the multiple candidate group names are associated with the entry link when the second object creates the entry link.

The first object preference is used to indicate the habitual preferences of the terminal of the first object in the display of group names. The first object preference includes, but is not limited to, the object's preference for font, font size, format, etc. when displaying group names.

Candidate group names are used to indicate different naming methods for the same target group.

In some embodiments, within an application, when a second object (such as a group administrator) creates an entry link, they can set multiple candidate group names for the same target group. These candidate group names represent different naming methods for the same group, designed to meet the preferences of different users regarding group name display. These preferences include, but are not limited to, font type, font size, format, etc.

In some embodiments, the application first collects the group name display preferences of the first user's terminal. This is typically determined through the user's settings or usage habits within the application. For example, a user might have selected a specific font and size in the settings, or frequently chosen a certain display format in past use. Next, the application analyzes these preferences and matches them against multiple candidate group names set by the second user for the entry link. Each candidate group name may have different display settings, such as different fonts, sizes, or formats. The application's goal is to find the candidate group name that best matches the first user's preferences. Once a matching candidate group name is found, the application displays this name as the target group name on the first user's terminal. In this way, the first user sees a group name that matches their display preferences, thereby improving user experience and satisfaction. The ability to display group names based on the user's personalized needs enhances user interaction and application satisfaction. Simultaneously, it demonstrates the application's attention to and responsiveness to user personalization needs, contributing to an improved overall user experience.

As an example, suppose there is a group called "Food Exchange." The group administrator (the second object) creates an entry link and sets multiple candidate group names for this entry link to suit different users' display preferences. These candidate group names include: "Gourmet," using an elegant font and a large font size, suitable for users who prefer a formal style; "Foodie Paradise," using a lively font and a medium font size, suitable for younger users who prefer a relaxed style; and "Cooking World," using a professional font and a smaller font size, suitable for users interested in cooking and appreciating technical details. Each candidate group name corresponds to different display settings to meet the preferences of different users.

As an example, when the first user (User A) visits the application's first page, the application detects User A's device preferences. Assume User A prefers a formal font and a large font size. Therefore, the application will display "Gourmet" as the target group name on User A's device. When the second user (User B) visits the first page, the application detects that User B prefers a lively font and a medium font size. Therefore, the application will display "Foodie Paradise" as the target group name on User B's device. When the third user (User C) visits the first page, the application detects that User C prefers a professional font and a small font size. Therefore, the application will display "Cooking World" as the target group name on User C's device. Group administrators can provide personalized group name displays for each user based on their display preferences, thereby improving user satisfaction and engagement. This also demonstrates the application's attention to and responsiveness to users' personalized needs.

In this specific implementation, when the second object creates an entry link to the target group and associates the entry link with the target group name, considering the different display preferences of different objects for group names, firstly, with authorization, the group display parameters set by each object in the application are obtained from the server's background logs. These parameters include the display font, font size, and display mode of the group name. Next, objects whose similarity in group display parameters exceeds a predetermined threshold are grouped into the same set, and a candidate group name corresponding to the group display parameters is set for each set. When an object in the set accesses the entry link, the entry link is displayed as the corresponding candidate group name. Each candidate group name is used to indicate the target group. Based on this, when the first object's terminal accesses the first page, the set to which the first object's terminal belongs based on the first object's preferences is first determined, and the candidate group name corresponding to the set is displayed as the target group name with a link tag, ensuring that the displayed target group name is adapted to the first object's terminal's preferences.

As shown in Figure 6A, when creating an entry link for a tennis interest group, the application platform configures the display settings for this entry link. In the display settings page, the candidate group names for the tennis interest group are set to the full name "City A and City B Tennis Interest Exchange Group" and the abbreviation "A+B City Tennis Group," with the entry link being "https://example.com/group?token=7qe31a5." Next, based on the preferences of various users regarding the display of the full group name and the abbreviation, the users are divided into two groups. The first group consists of users who prefer to display the full group name, including users 2, 11, 5, 6, etc. The second group consists of users who prefer to display the abbreviation, including users 3, 4, 5, 15, etc.

As shown in Figure 6B, the group members include Object 1, Object 2, and Object 3. When Object 2 accesses the conversation page of the basketball interest group, the content sent by Object 1 displayed on the conversation page is the group name of the tennis interest group with a link tag. At this time, the group name with the link tag is "A City and B City Tennis Interest Exchange Group".

As shown in Figure 6C, the group members include Object 1, Object 2, and Object 3. When Object 3 accesses the basketball interest group's chat page, the chat page displays the content sent by Object 1, which is the group name of the tennis interest group with a link tag. At this time, the group name with the link tag is "A+B City Tennis Group".

The advantage of this embodiment is that when the second object creates the entry link, it selects the target group name to be displayed for each object according to the object's preferences. For different objects, the same group is displayed with different names, making the displayed target group name more in line with the preferences of each object. This can improve the display diversity of the entry link and enhance the user experience of the object in the application.

Detailed description of step 320

In step 320, in response to a dwell action triggered around the target group name, basic information about the target group is displayed.

In some embodiments, the target area is an area on the first page where the distance between the display location of the target group name and the target area is less than a distance threshold, and the basic information is used to prompt the first object whether the link tag is triggered.

In this embodiment of the application, the basic information of the target group includes at least one of the information set when the second object creates the target group and the information extracted from the target group by the application platform based on the basic information extraction rules.

The information set when the second object creates the target group is the group information that the second object wants the object to be able to preview without opening the session page.

The information extracted from the target group by the application platform based on basic information extraction rules is group information that can be previewed before the session page is opened, selected by the application platform based on various factors such as the target group's group type and group security level.

The information set when the second object creates the target group and the information extracted from the target group by the application platform based on the basic information extraction rules may overlap. When the information to be displayed by both is the same, the information only needs to be displayed once.

In some embodiments, within the application, when a user (the first object) triggers a hover action within a target area on the first page, the system displays basic information about the target group. The target area is the region on the first page whose distance from the display location of the target group name is less than a distance threshold. This design allows users to preview basic information about the group through a simple hover action without directly clicking or triggering a link, thus helping users decide whether to open the session page.

In some embodiments, the second object (such as a group administrator) sets information when creating the target group. This information is group information that the administrator wants users to preview without opening the session page, and may include the group's description, purpose, rules, etc. The application platform extracts information from the target group based on basic information extraction rules. This information is filtered by the application platform based on various factors such as the target group's group type and security level, and can be previewed before opening the session page. For example, for a public group, the application platform might extract the group's latest discussion topics or activities; while for a private group, the platform might extract the number of members or the administrator's profile. When there is overlap between the information set by the second object when creating the target group and the information extracted by the application platform based on basic information extraction rules, it ensures that the same information is displayed only once to avoid redundancy and confusion. This improves the user experience, allowing users to obtain necessary information without delving into the group, helping them decide whether to join or participate in the group. It also demonstrates the application's responsiveness to user needs and its flexibility in managing group information.

As an example, suppose there is a group called "Photography Tips Exchange". The group administrator (the second user) created an entry link and set the target group name "Photography Tips Exchange" for this entry link. The administrator wants users to be able to preview some basic information about the group without opening the session page. When the first user (user A) visits the application's first page, they see the group name "Photography Tips Exchange" with a link. User A hovers their mouse over the target area near the group name (the area less than a distance threshold from the displayed position of the group name), triggering a hover action. In response to the user's hover action, the application displays basic information about the target group on User A's device. This information includes: Group description: "Welcome photography enthusiasts to join, share and learn photography tips, and exchange experiences." This information was set by the administrator when creating the group, hoping that users can understand the purpose and content of the group without opening the session page. Latest discussion topic: "How to take beautiful sunset photos?" This is group information that the application platform filters based on group type and security level, which can be previewed before opening the session page. It helps users understand the group's activity level and the topics discussed. If there is overlap between the information set by the administrator when creating the group and the information extracted by the application platform (for example, the administrator also mentions the latest discussion topic), the application will ensure that the same information is displayed only once to avoid redundancy. User A can preview the basic information of the group without opening the conversation page, helping them decide whether to open the conversation page and participate in the group discussion. This design improves the user experience, allowing users to obtain the necessary information without delving into the group, helping them make decisions about whether to join or participate. At the same time, it also demonstrates the application's responsiveness to user needs and its flexibility in managing group information.

In some instances, when the application platform extracts information from a target group based on basic information extraction rules, the basic information extraction rules are set as follows: multiple score ranges are defined based on the target group's security score, and each score range corresponds to a specific information item to be extracted. The security score is determined based on the target group's group type. Each group type has a pre-defined score value.

For example, the score is 60 for sports groups, 40 for food groups, and 80 for gaming groups. When the target group's security score is between 0 and 40, the extracted information includes the number of members and the group's creation time. When the target group's security score is between 80 and 100, the extracted information includes the current number of members and the maximum number of members allowed in the group.

As an example, when extracting basic information about a target group, the application platform determines which information items to extract based on the group's security score. The security score is pre-set based on the group type; different group types have different security score values. For example, a sports group might have a security score of 60, a food group might have 40, and a gaming group might have 80. The platform divides these security scores into multiple score ranges and assigns corresponding information items to each range. For example:

0-40 points: This range may correspond to a lower security level. The platform may extract some basic information, such as the number of people in the group and the creation time. This information is relatively public and will not disclose sensitive content.

41-60 points: This range likely corresponds to a medium level of security. The platform may extract more information, such as the group's latest activities or discussion topics. This information can help users understand the group's activity level and discussion content.

61-80 points: This range may correspond to a higher security level, and the platform may extract more detailed information, such as group rules or administrator contact information. This information helps users understand the group's management methods and participation requirements.

81-100 points: This range likely corresponds to the highest security level. The platform may extract more sensitive information, such as the current number of members in the group and the maximum number of members allowed. This information helps users understand the size of the group and whether there is still room for new members.

When a user pauses within the target area on the first page, the platform extracts relevant information based on the target group's security score and displays it to the user. For example, if a gaming group has a security score of 80, the platform might extract information such as the current number of members and the maximum number of members, displaying this information to the user. This helps users understand the group's basic information and security level without opening the chat page, allowing them to decide whether to join the group. It also demonstrates the application's responsiveness to user needs and its flexibility in managing group information.

As shown in Figure 2C, when the target group is a single group, the basic information of the target group is displayed when the mouse hovers around the target group name with the link mark in the session page. At this time, the basic information of the target group includes "Group members: 10; Has anyone joined: Yes; Group owner nickname: xxx1", etc.

As shown in Figure 7, the group members include Object 1, Object 2, and Object 3. When the target group includes multiple subgroups, hovering the mouse over the linked target group name in the session page displays basic information about the target group. Specifically, when Object 3 hovers the mouse over the linked group name "Badminton Interest Group" sent by Object 1 in the basketball interest group's session page, the linked target subgroup names of the three target subgroups included in the badminton interest group will be displayed. These three subgroup names are "Badminton Interest Group 1," "Badminton Interest Group 2," and "Badminton Newcomer Training."

The advantage of this embodiment is that by setting up a preview function in the application for the entry link displayed as the target group name with a link mark, users can preview the basic information of the group without opening the group's session page, understand what kind of group it is, and thus decide whether to join the group. Furthermore, by setting specific content for the basic group information for single and multiple target groups, the efficiency of group information transmission and the diversity of information display can be improved.

Detailed description of step 330

In step 330, in response to a trigger on a link tag, the session page for the target group is displayed.

To improve information transmission efficiency and enable the terminal of the first object to quickly access the session page of the target group, this application provides a scheme based on triggering to directly display the session page.

In some embodiments, step 330 specifically includes:

In response to a trigger on a link tag, if the first object is determined to be included in the target group, the session page for the target group is displayed.

In this specific implementation, when the terminal of the first object triggers the link tag through the target object, the server first detects the trigger event generated by the interaction between the target object and the link tag. Then, based on the trigger event, and with authorization, the information of each member of the target group is compared with the information of the terminal of the first object to determine whether the terminal of the first object is a member of the target group. If it is determined that the target group includes the first object, the session page of the target group is directly displayed in the application, allowing the terminal of the first object to directly view the session records of other group members and engage in conversations with other group members.

In some embodiments, when a user (the first object) clicks or touches a link in the application via their terminal, if the link points to a group (the target group), the application performs a series of steps to determine if the user has permission to view the group's session page. The application detects this triggering event when the user interacts with the link via their terminal. This event could be a click, touch, or other form of interaction. After detecting the triggering event, the application checks if the user has permission to view the target group's session page. This typically involves verifying whether the user is a member of the target group. The application may communicate with a server requesting verification of the user's membership. The server compares the user's terminal information with the target group's member list to determine if the user is a member of the target group. This may involve checking the user's account information, group invitation status, or other membership verification mechanisms.

In some embodiments, if the server confirms that the user is a member of the target group, the application will directly display the target group's conversation page. This page typically contains information such as group history, member list, and group announcements. Users can view the conversation history of other group members and communicate with them in real time. If the server confirms that the user is not a member of the target group, the application may display a message informing the user that they cannot view the group's conversation page, or provide an option to join the group. This entire process ensures that only members of the target group can view and participate in the group's conversations, protecting the group's privacy and security. At the same time, it provides users with a convenient and quick way to join or view groups of interest.

As an example, suppose there is a group called "Photography Enthusiasts". The group administrator (the second object) creates an entry link and sets the link tag "Join Photography Enthusiasts Group" for this entry link. The administrator wants users who click this link to directly view the group's conversation page if they are already members of the group. When the first object (user A) visits the application's first page, they see the group name with the "Join Photography Enthusiasts Group" link. User A is interested in photography and decides to click the link. In response to the user's click, the application sends a trigger event to the server. The server first detects this trigger event and then, based on the trigger event and with authorization, compares the information of each member of the target group with user A's terminal information. Assuming user A is already a member of the "Photography Enthusiasts" group, the server will confirm this and notify the application. Upon receiving the notification, the application will directly display the "Photography Enthusiasts" group's conversation page. User A can view the conversation records of other group members on the conversation page and communicate with other group members in real time. If user B clicks the same link, but user B is not a member of the "Photography Enthusiasts" group, the server will detect this and notify the application. Upon receiving the notification, the application may display a message informing user B that they cannot view the group's conversation page, or provide an option to join the group. This ensures that only group members can view and participate in group conversations, protecting the group's privacy and security. Simultaneously, it provides users with a convenient and quick way to join or view groups of interest.

The advantage of this embodiment is that when the terminal of the first object is detected to have triggered the link mark through the target object, and the target group is determined to include the first object, the session page of the target group is directly displayed according to the triggering operation without setting any intermediate links, so that the terminal of the first object can quickly access the session page of the target group, thereby improving the efficiency of information transmission.

Referring to Figure 8, in some embodiments, the target group including the first object is determined in the following manner:

Step 810: Obtain the candidate terminal identifier of each candidate object terminal in the target group;

Step 820: If the terminal identifier of the terminal of the first object is found to be consistent with a candidate terminal identifier, then the target group is determined to include the first object.

Steps 810-820 are described in detail below.

In step 810, the candidate terminal identifiers of each candidate object terminal in the target group are obtained.

Candidate object terminals refer to the various object terminals that have been registered on the application and belong to the group members of the target group.

Candidate terminal identifiers are used to identify candidate terminals in order to distinguish different candidate terminals.

In this specific implementation, the basic information of each group in the application and the information related to group members are recorded in the server's background log. Based on this, with authorization, the information related to group members of the target group can be obtained from the server's background log, and the candidate terminal identifiers of each candidate object terminal (group member) in the target group can be extracted from the information related to group members.

In some embodiments, obtaining the candidate terminal identifiers of each candidate object terminal in the target group is a crucial step in the application. This involves identifying the terminals of group members to distinguish different member terminals. Each user registered on the application has a unique terminal identifier, which can be a device ID, user account ID, or other unique identifier. These identifiers are used to uniquely identify each user terminal on the server side. The basic group information and group member information of each group in the application are recorded in the server's background log. This information includes the group ID, group name, group description, list of group members, and their terminal identifiers. To protect user privacy and data security, group member information can only be obtained from the server's background log with authorization. This typically involves verifying the requester's identity and permissions to ensure that only legitimate requests can access this information. Once authorized, the group member information of the target group can be obtained from the server's background log. This includes the group ID, group name, group description, and terminal identifiers of group members. From the group member information, the candidate terminal identifiers of each candidate object terminal in the target group can be extracted. These identifiers are used to uniquely identify each group member's terminal in the application to facilitate operations such as message push and session management. When extracting and using these terminal identifiers, relevant privacy regulations and policies must be followed to ensure the security and privacy of user data are not compromised. Applications can obtain the terminal identifiers of individual group members within a target group, thereby enabling precise management and personalized services for group members. This not only improves the user experience of the application but also enhances group interactivity and cohesion.

As an example, suppose there is a group called "Dance Lovers". The group administrator (the second object) creates an entry link and sets the link tag "Join the Dance Lovers Group" for this entry link. The administrator wants users who click this link to directly view the group's conversation page if they are already members of the group. When the first object (user A) visits the application's first page, they see the group name with the "Join the Dance Lovers Group" link. User A is interested in dance and decides to click the link. In response to the user's click, the application sends a trigger event to the server. The server first detects this trigger event and then, based on the trigger event and with authorization, compares the information of each member of the target group with user A's terminal information. Assuming user A is already a member of the "Dance Lovers" group, the server will confirm this and notify the application. After receiving the notification, the application will directly display the "Dance Lovers" group's conversation page. User A can view the conversation history of other group members on the conversation page and communicate with other group members in real time. On the other hand, if user B clicks the same link, but user B is not a member of the "Dance Lovers" group, the server will detect this and notify the application. Upon receiving the notification, the application may display a message informing user B that they cannot view the group's conversation page, or provide an option to join the group. This design ensures that only group members can view and participate in group conversations, protecting the group's privacy and security. At the same time, it provides users with a convenient and quick way to join or view groups of interest.

In this way, by obtaining the candidate terminal identifiers of each candidate device in the target group, the application can accurately identify and manage group members. Based on the basic group information and member-related information recorded in the server's backend logs, the accuracy and reliability of the data are ensured. With authorization, the extracted candidate terminal identifiers not only distinguish different group member devices but also provide the foundation for efficient message push and session management. This precise terminal identification mechanism helps improve user experience, enhance group interactivity and cohesion, and also helps maintain group security and privacy.

In step 820, if the terminal identifier of the terminal of the first object is determined to be consistent with a candidate terminal identifier, then the target group is determined to include the terminal of the first object.

In this specific implementation, firstly, the candidate terminal identifiers of each candidate terminal are compared with the terminal identifier of the terminal of the first object. Next, if a candidate terminal identifier matches the terminal identifier of the terminal of the first object, it indicates that the terminal of the first object is a member of the target group, and the target group is determined to include the terminal of the first object. If no candidate terminal identifier matches the terminal identifier of the terminal of the first object, it indicates that the terminal of the first object is not a member of the target group, and the target group is determined to exclude the terminal of the first object.

In some embodiments, the process of determining whether a user (first object) belongs to a target group in an application is as follows: The application obtains candidate terminal identifiers for all group members in the target group. These identifiers are unique and used to identify the terminal device of each group member. The application then compares these candidate terminal identifiers one by one with the terminal identifier of the first object. The comparison process is implemented by an algorithm, typically performing an exact match between the two identifier strings. If a candidate terminal identifier is found to be exactly the same as the terminal identifier of the first object during the comparison, the application can determine that the first object's terminal is a member of the target group. The determination process is based on the uniqueness and accuracy of the terminal identifiers. Terminal identifiers are typically generated by the application to ensure that each terminal device has a unique identifier. Therefore, by comparing terminal identifiers, it is possible to accurately determine whether a user belongs to a group. If no candidate terminal identifier is found to be the same as the first object's terminal identifier during the comparison, the application determines that the first object's terminal is not a member of the target group. This means that the user cannot view or participate in the group's sessions, thus protecting the privacy and security of the group. This is typically triggered when a user attempts to access the group session page. This ensures that only legitimate group members can access group content, while providing users with a safe and private communication environment.

As an example, suppose there is a group called "Tech Enthusiasts". The group administrator (the second object) creates an entry link and sets the link tag "Join the Tech Enthusiasts Group" to this entry link. The administrator wants users who click this link to directly view the group's conversation page if they are already members of the group. When the first object (user A) visits the application's homepage, they see the group name with the "Join the Tech Enthusiasts Group" link. User A is interested in technology and decides to click the link. In response to the user's click, the application sends a trigger event to the server. The server first detects this trigger event and, based on the trigger event and with authorization, compares the information of each member of the target group with user A's terminal information. Assuming user A is already a member of the "Tech Enthusiasts" group, the server will confirm this and notify the application. Upon receiving the notification, the application will directly display the "Tech Enthusiasts" group's conversation page. User A can view the conversation records of other group members on the conversation page and communicate with other group members in real time. On the other hand, if user B clicks the same link, but user B is not a member of the "Tech Enthusiasts" group, the server will detect this and notify the application. Upon receiving the notification, the application may display a message informing user B that they cannot view the group's conversation page, or provide an option to join the group. This ensures that only group members can view and participate in group conversations, protecting the group's privacy and security. Simultaneously, it provides users with a convenient and quick way to join or view groups of interest.

The advantage of this embodiment is that it uses a terminal identifier comparison method to determine whether the terminal of the first object is a member of the target group. The comparison is simple and can determine whether the target group includes the terminal of the first object in a relatively accurate and quick manner.

Because accidental triggering of interactions often occurs in applications—for example, an object may not intend to trigger a certain process or open a certain page on the application's interface, but accidentally touching the corresponding control can cause the process to be triggered or the page to be opened—this situation can affect the accuracy of information display. Therefore, this application provides a solution that sets a confirmation step before displaying the session page, which can effectively prevent the page from being accidentally triggered and thus improve the accuracy of information display.

Referring to Figure 9, in some embodiments, step 330 specifically includes, but is not limited to, the following steps 910-920:

Step 910: In response to the target object's triggering of the link tag, display an inquiry message;

Step 920: In response to an affirmative answer to the query message, display the session page for the target group.

Steps 910-920 are described in detail below.

In step 910, in response to the target object's triggering of the link tag, an inquiry message is displayed.

The query message is used to ask the terminal of the first object whether to display the session page of the target group.

In a specific implementation of this embodiment, when the terminal of the first object triggers the link mark through the target object, the server detects this triggering event and determines through comparison that the target group includes the terminal of the first object. Then, the server displays a pop-up window on the application to the terminal of the first object to ask for a query message, so as to ask the terminal of the first object to reconfirm whether to access the session page of the target group.

In some embodiments, when a target object (typically a group administrator or other group member) triggers a link marker in the application, the application performs the following steps to display a prompt message: The application detects this trigger event when the target object clicks or touches the link marker. This event may be a click, touch, or other form of interaction. After detecting the trigger event, the application communicates with the server to request verification that the first object's terminal is a member of the target group. The server performs the verification based on stored group member information. If the server confirms that the first object's terminal is a member of the target group, the application displays a prompt message as a pop-up on the first object's terminal. This message may say: "Do you want to view the 'Target Group' session page?" The first object's terminal user will see this prompt message and can choose "Yes" or "No". This step allows the user to make a final confirmation before accessing the group session page, increasing user control and privacy protection. If the user selects "Yes", the application displays the target group's session page. If the user selects "No", the application cancels the operation, and the user is not directed to the group session page. This increases user engagement and control, ensuring that the user has sufficient choice before accessing the group session page. It also enhances the user experience of the application, making users feel safer and more secure. At the same time, it demonstrates the application's responsiveness to user needs and respect for user privacy.

As an example, suppose there is a group called "Movie Lovers". The group administrator (the second object) creates an entry link and sets the link tag "Join Movie Lovers Group" for this entry link. The administrator wants users who are already members of the group to be able to directly view the group's session page after clicking this link. When the first object (user A) visits the application's first page, they see the group name with the "Join Movie Lovers Group" link. User A is interested in movies and decides to click the link. In response to the user's click, the application sends a trigger event to the server. The server first detects this trigger event, and then, based on the trigger event and with authorization, compares the information of each member of the target group with the information on user A's terminal. Assuming user A is already a member of the "Movie Lovers" group, the server will confirm this and notify the application. After receiving the notification, the application will display a pop-up message on user A's terminal asking: "Do you want to view the 'Movie Lovers' group's session page?" After seeing the question message, user A can choose "Yes" or "No". If user A chooses "Yes", the application will directly display the "Movie Lovers" group's session page. User A can view other group members' conversation history on the conversation page and communicate with them in real time. If User A selects "No," the application will cancel the operation, and User A will not be redirected to the group conversation page. This ensures that users have full choice before accessing the group conversation page, increasing user engagement and control. At the same time, it also improves the application's user experience, making users feel safer and more secure.

Thus, by implementing a feature in the application that displays a prompt message in response to a target object's link tag, both user experience and data security can be improved. This feature relies on server-side verification of group member eligibility, ensuring that only legitimate group members receive the prompt message. By displaying the prompt message as a pop-up on the user's terminal, the application provides the user with a final confirmation opportunity before accessing the group session page, enhancing user engagement and control, while simultaneously promoting effective communication and interaction among group members. This provides the application with a more secure, private, and efficient group management mechanism.

In step 920, in response to an affirmative answer to the query message, the session page for the target group is displayed.

In this specific implementation, when the terminal of the first object responds positively to the query message, indicating that the triggering of the link tag by the target object is not a mistake, the session page of the target group is displayed to the terminal of the first object. When the terminal of the first object responds negatively to the query message, indicating that the triggering of the link tag by the target object may be a mistake, and the terminal of the first object does not want to access the session page of the target group, the query message is closed, the session page of the target group is not displayed, and the page currently displayed on the application platform remains unchanged.

In some embodiments, within the application, when the terminal of the first user receives a prompt message, the user can choose whether to confirm access to the target group's session page. If the terminal user of the first user selects "Yes" or "Confirm," the application sends this response back to the server. Upon receiving a positive response, the server verifies the validity of this selection and confirms that the user does indeed have permission to access the target group's session page. After successful verification, the application displays the target group's session page on the terminal of the first user, allowing the user to begin viewing and participating in group discussions. If the terminal user of the first user selects "No" or "Cancel," the application sends this response back to the server. Upon receiving a negative response, the server records this selection and confirms that the user does not wish to access the target group's session page. Based on this selection, the application closes the prompt message and maintains the currently displayed page, preventing the user from being redirected to the group session page. This ensures that users have sufficient choice before accessing the group session page, avoiding inconvenience caused by accidental triggering. It improves the user experience of the application, making users feel safer and more secure. Simultaneously, it demonstrates the application's responsiveness to user needs and respect for user privacy.

As an example, suppose there is a group called "Travel Photography". The group administrator (the second object) creates an entry link and sets the link tag "Join Travel Photography Group" for this entry link. The administrator wants users who are already members of the group to be able to directly view the group's session page after clicking this link. When the first object (user A) visits the application's first page, they see the group name with the "Join Travel Photography Group" link. User A is interested in travel photography and decides to click the link. In response to the user's click, the application sends a trigger event to the server. The server first detects this trigger event, and then, based on the trigger event and with authorization, compares the information of each member of the target group with the information on user A's terminal. Assuming user A is already a member of the "Travel Photography" group, the server will confirm this and notify the application. After receiving the notification, the application will display a pop-up message on user A's terminal asking: "Do you want to view the 'Travel Photography' group's session page?" After seeing the question message, user A can choose "Yes" or "No". If user A chooses "Yes", the application will directly display the "Travel Photography" group's session page. User A can view other group members' conversation history on the conversation page and communicate with them in real time. If User A selects "No," the application will close the prompt message and keep the currently displayed page unchanged. User A will not be redirected to the group conversation page and can continue browsing other content in the application.

As shown in Figure 10A, the group members include Object 1, Object 2, and Object 3. When Object 3 double-clicks the link to the Tennis Interest Group sent by Object 1 in the basketball interest group's session page, the application platform will display a prompt message window. The prompt message in the prompt message window is "Do you want to open the group 'Tennis Interest Group'?" The prompt message window also includes interactive "Confirm" and "Cancel" controls.

As shown in Figure 10B, the group members include object 3, object 5, and object 9. When object 3 clicks the "Confirm" control in the query message window, it is considered that object 3 has given a positive response, and the tennis interest group's conversation page is displayed in the application platform. When object 3 clicks the "Cancel" control in the query message window, it is considered that object 3 has given a negative response, and the query message window is closed directly.

The advantage of this embodiment is that when the terminal of the first object is detected to have triggered the link mark through the target object, and the target group is determined to include the terminal of the first object, an inquiry message window is set. After the terminal of the first object confirms again, the session page of the target group is displayed according to the triggering operation. This can reduce the possibility of displaying the session page due to accidental triggering and improve the efficiency and accuracy of information transmission.

To improve group access security, if the first user's terminal is not a member of the target group, even if the link marker for the target group name is triggered, it will not directly access the target group's group page. In this case, directly blocking the first user's terminal from entering the target group would affect normal conversational communication and reduce the efficiency of information transmission within the application. Therefore, this application provides a scheme for setting an authorization access step when displaying the session page, enabling the session page to be displayed to the first user's terminal only after authorized access.

Please refer to Figure 11. In some embodiments, step 330 specifically includes, but is not limited to, the following steps 1110-1120:

Step 1110: In response to the target object's triggering of the link tag, send an authorization request to the second object;

Step 1120: In response to receiving the authorization response from the second object, display the session page of the target group.

Steps 1110-1120 are described in detail below.

In step 1110, in response to the target object's triggering of the link tag, an authorization request is sent to the second object.

In this specific implementation, when the terminal of the first object triggers the link tag through the target object, the server, upon detecting this triggering event and determining through comparison that the target group does not include the terminal of the first object, firstly prompts the terminal of the first object in a pop-up window whether it requests authorization to join the target group. Then, when the terminal of the first object wishes to join the target group, it selects to request authorization. Based on this, the server will send an authorization request to the second object on behalf of the terminal of the first object, requesting to join the target group. When the second object receives the authorization request, it will perform terminal authentication on the terminal of the first object. If the authentication of the terminal of the first object is successful, it will issue an authorization response, allowing the terminal of the first object to join the target group. If the authentication of the terminal of the first object fails, it will issue a denial of authorization response, disallowing the terminal of the first object from joining the target group.

In some embodiments, within the application, when a target object triggers a link marker, if the server detects that the first object's terminal is not a member of the target group, the application will detect this triggering event when the target object clicks or touches the link marker. This event may be a click, touch, or other form of interaction. After detecting the triggering event, the application communicates with the server to request verification that the first object's terminal is a member of the target group. The server performs verification based on stored group member information. If the server confirms that the first object's terminal is not a member of the target group, the application displays a pop-up message on the first object's terminal asking: "Do you want to apply to join the 'target group'?" If the first object's terminal user selects "Yes" or "Apply," the application sends this selection back to the server. Upon receiving the application, the server sends an authorization request on behalf of the first object's terminal to a second object (group administrator or other authorized object). Upon receiving the authorization request, the second object authenticates the first object's terminal. This may include checking the user's registration information, verifying the user's identity credentials, etc. If the second object determines that the first object's terminal is successfully authenticated, they will issue an authorization response, allowing the first object's terminal to join the target group. The application receives the authorization response and adds the first object's terminal to the target group. If the second entity determines that the authentication of the first entity's terminal fails, they will issue a denial response, disallowing the first entity's terminal from joining the target group. The application will receive the denial response and notify the first entity's terminal user that the application was rejected.

As an example, suppose there is a group called "Healthy Living". The group administrator (the second object) creates an entry link and sets the link tag "Join Healthy Living Group" to this entry link. The administrator wants users who click this link tag to apply to join the group if they are not already members. When the first object (user A) visits the application's homepage, they see the group name with the "Join Healthy Living Group" link tag. User A is interested in healthy living and decides to click the link tag. In response to the user's click, the application sends a trigger event to the server. The server first detects this trigger event and, based on the trigger event and with authorization, compares the information of each member of the target group with the information on user A's device. Assuming user A is not a member of the "Healthy Living" group, the server will confirm this and notify the application. After receiving the notification, the application will display a pop-up message on user A's device asking: "Do you want to apply to join the 'Healthy Living' group?" After seeing the message, user A can choose "Yes" or "Apply". If user A chooses "Yes", the application will send this selection back to the server. After receiving the application, the server will send an authorization request to a second entity on behalf of User A's terminal, requesting to join the "Healthy Living" group. Upon receiving the authorization request, the second entity (the group administrator) will authenticate User A's terminal. This may include checking the user's registration information and verifying the user's identity credentials. If the second entity determines that User A's terminal is successfully authenticated, they will issue an authorization response, allowing User A's terminal to join the "Healthy Living" group. The application will receive the authorization response and add User A's terminal to the group. User A can then view other members' discussions and participate in healthy living exchanges within the group. If the second entity determines that User A's terminal is unauthenticated, they will issue a denial response, preventing User A's terminal from joining the "Healthy Living" group. The application will receive the denial response and notify User A's terminal that the user application was rejected.

Thus, by implementing a feature in the application that sends an authorization request to a second object in response to a target object's link tag, group security and user experience can be improved. This feature is based on server-side verification of group membership, ensuring that only legitimate users receive authorization requests. By displaying a prompt message on the user's terminal as a pop-up, the application provides the user with a final confirmation opportunity before requesting to join the group, enhancing the user's sense of participation and control. When a user chooses to join the group, the server sends an authorization request to the second object on behalf of the user, and the second object verifies the user's identity. If the verification is successful, the second object will grant authorization, allowing the user to join the group; if the verification fails, the second object will deny authorization, preventing the user from joining the group. This design not only improves group security but also enhances the user experience, making users feel safer and more secure. At the same time, it also demonstrates the application's responsiveness to user needs and respect for user privacy.

In step 1120, in response to receiving the authorization response from the second object, the session page of the target group is displayed.

An authorization response refers to the second object's response to the authorization request from the first object's terminal, granting permission to join the target group.

In this specific implementation, when an authorization response from the second object is received, it indicates that the first object's terminal is allowed to join the target group. Based on this, the server, in response to receiving the authorization response from the second object, first adds the first object's terminal as a group member of the target group and displays the target group's session page on the first object's terminal.

In some embodiments, within an application, when a second object (such as a group administrator) responds to an authorization request from a first object's terminal, the server receives the second object's authorization response, indicating that the first object's terminal is permitted to join the target group. Based on the authorization response, the server adds the first object's terminal as a member of the target group, involving updating the group member database on the server to record the first object's terminal information. Once the first object's terminal is added as a member of the target group, the server sends an instruction to the first object's terminal to display the target group's session page. This page may contain the group's history, a list of currently online members, and an input box for sending new messages. Upon receiving the server's instruction, the first object's terminal updates the application's interface to display the target group's session page. Users can now view the group's discussions and participate in real-time communication. This ensures that only authorized users can join the group and view the group's session page, maintaining the group's security and privacy. Simultaneously, it improves the user experience, allowing users to quickly and easily join groups of interest and participate in discussions.

As an example, suppose there is a group called "Tech Enthusiasts". The group administrator (the second object) created an entry link and set the link tag "Join the Tech Enthusiasts Group". The administrator wants users who click this link to apply to join the group if they are not already members. When the first object (user A) visits the application's homepage, they see the group name with the "Join the Tech Enthusiasts Group" link. User A is interested in technology and decides to click the link. In response to the user's click, the application sends a trigger event to the server. The server first detects this trigger event and, based on the trigger event and with authorization, compares the information of each member of the target group with the information on user A's device. Assuming user A is not a member of the "Tech Enthusiasts" group, the server will confirm this and notify the application. After receiving the notification, the application will display a pop-up message on user A's device asking: "Do you want to apply to join the 'Tech Enthusiasts' group?" After seeing the message, user A can choose "Yes" or "Apply". If user A chooses "Yes", the application will send this selection back to the server. After receiving the request, the server sends an authorization request to a second entity on behalf of User A's device, requesting to join the "Tech Enthusiasts" group. Upon receiving the authorization request, the second entity (the group administrator) authenticates User A's device. This may include checking the user's registration information and verifying the user's credentials. If the second entity determines that User A's device is successfully authenticated, they will issue an authorization response, allowing User A's device to join the "Tech Enthusiasts" group. The application receives the authorization response and adds User A's device to the group. Once User A's device is added to the group, an instruction is sent to User A's device requesting the display of the "Tech Enthusiasts" group's conversation page. Upon receiving the instruction, User A's device updates the application's interface, displaying the group's conversation page. User A can now view the group's history, the list of currently online members, and participate in real-time discussions.

The advantage of this embodiment is that by setting up an authorization access step when displaying the session page, if the target group does not include the first object's terminal, authorization access to the session page for the target group is requested for the first object's terminal based on the triggering of the link tag by the target object. After authorization, the first object's terminal is included in the target group's membership scope, and the target group's session page is displayed for the first object's terminal. This allows the first object's terminal to quickly join the target group after authorization, meeting the normal session communication needs of the first object's terminal and improving the information transmission efficiency of the application.

Referring to Figure 12, in some embodiments, the authorization response is generated in the following manner:

Step 1210: Obtain the terminal reputation and creation timestamp of the terminal of the first object;

Step 1220: Determine the terminal score of the first object's terminal based on terminal reputation and creation timestamp;

Step 1230: If the terminal score is greater than the predetermined score, generate an authorization response.

Steps 1210-1230 are described in detail below.

In step 1210, the terminal reputation and creation timestamp of the terminal of the first object are obtained.

Terminal credit rating is used to indicate the creditworthiness of the terminal of the first object.

A timestamp is created to indicate the point in time when the first object's terminal was registered with the application.

In the specific implementation of this embodiment, since the reputation and creation timestamp of each object terminal are recorded in the background log of the application server, the terminal reputation and creation timestamp of the first object terminal can be directly obtained from the background log with authorization.

In some embodiments, obtaining the terminal reputation and creation timestamp of a first object's terminal is a crucial process within the application. This process helps assess the terminal's creditworthiness and determine its registration time within the application. Terminal reputation is a metric used to measure the first object's terminal's creditworthiness within the application. It may be based on various factors, such as the terminal's historical behavior, compliance with application rules, and engagement. The application server records reputation information for each terminal. This information may include the terminal's historical activity records, violation records, user feedback, etc. With authorization, the server can access these records and directly obtain the first object's terminal reputation from the background logs. A creation timestamp is a timestamp indicating the first object's terminal's registration time within the application. It records the exact time the terminal first registered or joined the application. The application server also records the registration time for each terminal. This timestamp information is typically stored in background logs. With authorization, the server can directly obtain the first object's terminal's creation timestamp from these logs. Before obtaining this sensitive information, the application must ensure that it has obtained the necessary authorization. This may include user consent, compliance with data protection regulations, etc. The purpose of licensing is to protect user privacy and ensure that this information can only be accessed and used legally and legitimately. When acquiring and processing this information, applications must take appropriate security measures to ensure the security and integrity of the data. This may include data encryption, access control, and regular auditing.

As an example, suppose there is an application called "Online Education" that provides various online courses and learning resources. To ensure the security and quality of the learning environment, the application evaluates the credibility of user devices and records user registration times. When a first user (User A) attempts to access a protected advanced course, the application needs to evaluate User A's device credibility and registration time. When User A attempts to access the advanced course, the application sends a request to the server to evaluate User A's device credibility. The server checks the background logs for User A's device credibility records. These records may include User A's historical behavior, engagement, compliance with community rules, etc. Based on this information, the server calculates User A's device credibility score. The higher the score, the better User A's device credibility. The server checks the creation timestamp of User A's device to determine User A's registration time. The creation timestamp records the exact time User A first registered with the application, which helps assess User A's loyalty and engagement with the application. Before obtaining this information, the application ensures that it has obtained User A's authorization, such as through a user agreement or privacy policy. This ensures that the application's access to and use of user data is legal and transparent. Based on user A's terminal reputation and registration time, the application decides whether to allow user A to access advanced courses. If user A has a high reputation and a long registration time, the application may allow access; if the reputation is low or the registration time is short, the application may restrict access or require the user to provide more information.

Thus, by implementing the functionality to obtain the terminal reputation and creation timestamp of the first user object within the application, the application's security and user experience can be significantly improved. This functionality, based on server records of terminal reputation and registration time, ensures data accuracy and real-time performance. By directly retrieving this information from background logs, the application can quickly and efficiently assess the terminal's creditworthiness and registration time, enabling more informed decisions such as access control and risk management. This not only enhances application security but also improves the user experience, making users feel safer and more secure. Simultaneously, it demonstrates the application's responsiveness to user needs and respect for user privacy. The functionality to obtain terminal reputation and creation timestamps provides the application with a powerful tool to better manage user terminals, protect user data, and improve overall service quality.

In step 1220, the terminal score of the terminal of the first object is determined based on the terminal reputation and the creation timestamp.

The terminal score is used to indicate the authorization score for adding the terminal of the first object to the target group.

In this specific implementation, firstly, a first score is determined based on the terminal's reputation; then, a second score is determined based on the creation timestamp. Finally, a weighted sum of the first and second scores is performed to obtain the terminal score.

Specifically, when determining the first score based on the terminal's reputation, a function calculation method is used. The terminal's reputation is substituted into a preset function as an independent variable, and the output of the preset function is used as the first score. The preset function is an increasing function; the higher the terminal's reputation, the higher the first score.

When determining the second score based on the creation timestamp, the time difference between the creation timestamp and the current time is first calculated. Then, a lookup table is used to retrieve the mapping table between time difference intervals and candidate scores. The time difference interval within this interval is determined, and the candidate score corresponding to that interval is used as the second score. A larger time difference results in a larger second score.

In some embodiments, determining the terminal score of a terminal for a first target based on terminal reputation and creation timestamp is a crucial decision-making process within the application. This process helps assess the terminal's eligibility and authorization rating for joining a target group. Terminal reputation is a metric that measures a terminal's creditworthiness, reflecting its behavioral history within the application, rule compliance, and user feedback. To convert terminal reputation into a quantifiable score, the application can employ a pre-defined increasing function. This function takes terminal reputation as its independent variable and outputs a corresponding first score. Since the function is increasing, a higher terminal reputation results in a higher first score. The creation timestamp records the terminal's registration time within the application, helping to assess its activity and loyalty. To convert the creation timestamp into a quantifiable score, the application first needs to calculate the time difference between the current time and the creation timestamp. The application can use a lookup table, referencing a predefined mapping table of time difference intervals and candidate scores. This table divides the time difference into different intervals, each corresponding to a candidate score. A larger time difference results in a higher second score. Once the first and second scores are obtained, the application performs a weighted sum to arrive at the final terminal score. The weighted sum operation involves assigning different weights to the first and second scores, reflecting their respective importance in the final terminal score. For example, if terminal credibility is considered more important than registration time, the first score might have a higher weight. The final terminal score is a weighted sum of the first and second scores, comprehensively considering both the terminal's creditworthiness and registration time, providing a holistic basis for authorization decisions.

As an example, suppose there is a group called "Professional Photography Exchange," a platform for advanced photography enthusiasts to exchange ideas. To ensure the quality and professionalism of the group, the group administrator wants to evaluate the devices of users applying to join to determine if they meet the group's requirements. When User A applies to join the "Professional Photography Exchange" group, the application first evaluates User A's device reputation. Assuming User A's device reputation score is 80 points (out of 100), the application will substitute this reputation score into a preset increasing function to calculate a first score. For example, the increasing function might be f(x) = x, in which case the first score would also be 80 points. The application then evaluates User A's device creation timestamp. Assuming User A's device was registered two years ago, the application will calculate the time difference between the current time and the creation timestamp, resulting in two years. Then, the application will refer to a mapping table of time difference intervals and candidate scores. For example, the mapping table might look like this: 0-1 years: 10 points; 1-2 years: 20 points; 2-3 years: 30 points; 3 years and above: 40 points. Based on the two-year time difference, User A's second score is 20 points. The application will perform a weighted sum of the first and second scores to obtain the final score. Assuming the weight of the first score is 0.6 and the weight of the second score is 0.4, then the final score = (80 * 0.6) + (20 * 0.4) = 48 + 8 = 56 points. The group administrator will decide whether to authorize User A to join the group based on the final score. If the group's authorization threshold is 60 points, then User A's final score is 56 points, which is below the threshold, and the group administrator may reject User A's joining application. If the group administrator believes that User A's final score is close to the threshold, they may request the user to provide more information or conduct an evaluation.

In some embodiments, when performing a weighted sum operation on the first score and the second score to obtain the terminal score, firstly, a first weight and a second weight are determined. The first weight indicates the importance of terminal reputation in the terminal rating, and the second weight indicates the importance of the creation timestamp in the terminal rating. The sum of the first weight and the second weight is 1. Then, the product of the first weight and the first score, and the product of the second weight and the second score are added together to obtain the terminal score of the first object's terminal.

In step 1230, if the terminal score is greater than a predetermined score, an authorization response is generated.

The predetermined score is used to measure whether the terminal of the first object meets the conditions for joining the target group.

In this specific implementation, firstly, the terminal score is compared with a predetermined score. Next, if the terminal score is determined to be greater than the predetermined score, it indicates that the terminal of the first target is relatively safe and meets the conditions for joining the target group, and an authorization response is generated. Conversely, if the terminal score is determined to be less than or equal to the predetermined score, it indicates that the terminal of the first target is of higher risk and does not meet the conditions for joining the target group, and a denial response is generated.

In some embodiments, the application needs to set a predetermined score, which serves as a benchmark for whether a terminal meets the conditions for joining a target group. The application compares the calculated terminal score with the predetermined score to determine if the terminal meets the conditions for joining the group. If the terminal score is greater than the predetermined score, the application generates an authorization response. This indicates that the terminal of the first target is relatively safe and meets the conditions for joining the target group. The authorization response typically contains an instruction to allow joining the group, and the application sends this response to the terminal of the first target, enabling it to join the group and participate in the discussion. If the terminal score is less than or equal to the predetermined score, the application generates a denial response. The terminal of the target poses a greater risk and does not meet the conditions for joining the target group. The denial response typically contains an instruction to disallow joining the group, and the application sends this response to the terminal of the first target, notifying it that it cannot join the group. Regardless of whether an authorization response or a denial response is generated, the application notifies the terminal of the result. If it is an authorization response, the user will be able to see the group's conversation page and participate in the discussion; if it is a denial response, the user will receive a notification that their terminal does not meet the conditions for joining the group. Based on the terminal score-based authorization mechanism, the application can effectively manage group members, ensuring the security and professionalism of the group. At the same time, it also demonstrates the application's responsiveness to user needs and respect for user privacy.

As an example, suppose there is a group called "Advanced Investment Discussion," a professional discussion platform for experienced investors only. To ensure the quality and security of the group, the group administrator sets a predetermined score; only users with a terminal score exceeding this score can join the group. When User A applies to join the "Advanced Investment Discussion" group, the application first evaluates User A's terminal score. Let's say User A's terminal score is 75, and the predetermined score is 70. The application compares User A's terminal score (75) with the predetermined score (70). The comparison shows that User A's terminal score is greater than the predetermined score. Because User A's terminal score is greater than the predetermined score, the application generates an authorization response. The authorization response contains instructions to allow User A to join the group, and the application sends this response to User A's terminal. After receiving the authorization response, User A's terminal displays the group's session page. User A can now view the group's history, the list of currently online members, and participate in live discussions.

As an example, suppose User B requests to join the same group, but User B's terminal score is 65, lower than the predetermined score. When User B requests to join the "Advanced Investment Discussion" group, the application evaluates User B's terminal score. Assume User B's terminal score is 65, and the predetermined score is 70. The application compares User B's terminal score (65) with the predetermined score (70). The comparison shows that User B's terminal score is lower than the predetermined score. Because User B's terminal score is lower than the predetermined score, the application generates a denial-of-authorization response. The denial-of-authorization response contains an instruction not to allow User B to join the group, and the application sends this response to User B's terminal. After receiving the denial-of-authorization response, User B's terminal displays a notification stating that their terminal does not meet the conditions for joining the group. User B cannot join the group and cannot view the group's session page. How can a terminal score-based authorization mechanism help group administrators manage group members and ensure the quality and security of the group?

The advantage of this embodiment is that by comprehensively determining the terminal score of the first object's terminal based on the terminal reputation and creation timestamp, and by using a scoring method to quantify the terminal verification process of the first object's terminal, the convenience and reliability of terminal verification of the first object's terminal can be improved, thereby improving the reliability and security of group access authorization for the first object's terminal.

To improve the efficiency of displaying group information, multiple groups can be aggregated into a single entry link for sharing, based on the settings of the second object. This allows other objects to preview basic information such as the group names of multiple groups through a single entry link.

In this embodiment, the target group of this application includes multiple target subgroups, and the entry link is synthesized based on the sub-entry links created by the second object for each target subgroup. The method of creating sub-entry links for each target subgroup is essentially the same as the method of creating entry links for the target group.

Based on this, when a target group includes multiple target sub-links, the basic information of the target group includes the target sub-group name of each target sub-group. The target sub-group name is associated with the target sub-group when the second object creates the entry link, and the target sub-group name has a link tag.

In this embodiment, step 330 specifically includes:

In response to a link marker on the target subgroup name triggered by the target object, the session page of the target subgroup is displayed.

In the specific implementation of this embodiment, the various scenarios in which the session page of the target subgroup is displayed based on the triggering of the link marker on the target subgroup name are similar to steps 910-920 and 1110-1120 described above. To save space, these details will not be repeated.

As shown in Figure 13A, the group members include Object 1, Object 2, and Object 3. When Object 3 hovers the mouse over the group name "Badminton Interest Group" (linked by Object 1) in the basketball interest group's chat page, the linked names of the three target subgroups included in the badminton interest group will be displayed. These subgroup names are "Badminton Interest Group 1," "Badminton Interest Group 2," and "Badminton Newcomer Training." When Object 3 hovers the mouse over the target subgroup "Badminton Interest Group 1," the application platform will display the basic information of that target subgroup: "Group members: 5; Already joined: Yes; Group owner nickname: AA1."

As shown in Figure 13B, the group members include Object 1, Object 2 and Object 3. When Object 3 hovers the mouse over the group name of the target subgroup "Badminton Interest Group 2", the application platform will display the basic information of the target subgroup: "Group members: 32; Have they joined: No; Group owner nickname: AA2".

As shown in Figure 13C, group member AA1 includes object 3, object 11, object 2, object 4, and object 5. Based on the comparison of the basic information of each target subgroup, object 3 double-clicks the link marker of the target subgroup "" in the application platform to trigger this link marker. At this time, the session page of the target subgroup "Badminton Interest Group 1" is displayed in the application platform.

The advantage of this embodiment is that, based on the settings of the second object, multiple groups are aggregated into a single entry link for sharing. This allows other objects to preview the group names of multiple groups through a single entry link, and based on the interaction with the group names in different groups, preview the basic information of each group and trigger the link to join the conversation page of that group. This improves the efficiency of displaying and transmitting group information.

Figure 14 illustrates the process executed by the application server when displaying the session page of the target group. Specifically, in step 101, the terminal of the first object clicks the link to edit the target group on the first page. In step 102, the server retrieves the group information of the target group. In step 103, it checks whether the terminal of the first object is already in the group. In step 104, if the terminal of the first object is not already in the group, it requests to join the target group. In step 105, it determines whether the joining was successful. In step 106, if the terminal of the first object is already in the group, or has successfully joined the target group, it opens the session page of the target group after a second confirmation. When the terminal of the first object clicks the link to the target group on the first page, triggering the link, the server first retrieves the group information of the target group and determines whether the terminal of the first object is already in the group based on the group information. The specific implementation process is similar to steps 810-820 above.

In some embodiments, if it is determined that the terminal of the first object is in the target group, the session page of the target group is opened after secondary confirmation. The specific implementation process is similar to steps 910-920 above. If it is determined that the terminal of the first object is not in the target group, and the terminal of the first object requests to join the target group, it is determined whether the terminal of the first object has successfully joined. After confirming successful joining, the session page of the target group is opened after secondary confirmation by the terminal of the first object. The specific implementation process is similar to steps 1110-1120 above. For the sake of brevity, it will not be described in detail.

A detailed description of an embodiment of this application for creating an entry link for a target group.

To improve the convenience and accuracy of creating entry links, embodiments of this application provide a link creation scheme based on random numbers and encoding rules, which can improve link creation efficiency and make entry links different for different groups.

Referring to Figure 15, in some embodiments, when the target group includes only a single group, the process of creating an entry link for the target group specifically includes, but is not limited to, the following steps 1510-1540:

Step 1510: Display the target group's session page to the second object;

Step 1520: In response to the link creation operation of the second object in the session page of the target group, obtain the target group name of the target group and the terminal identifier of the second object;

Step 1530: Generate a group string based on the target group name and terminal identifier;

Step 1540: If the group string is determined to satisfy the first condition, then encode the group string into an entry link and display the entry link for the second object.

Steps 1510-1540 are described in detail below.

In step 1510, the target group's session page is displayed to the second object.

In this specific implementation, when a second object logs into the application platform and wants to access the session page of its target group, the server responds to the second object's access request and displays the target group's session page to the second object. The target group's session page includes an interactive control for generating an entry link to the target group.

In some embodiments, displaying the target group's session page to a second user is a key interactive process within the application, allowing the user to access and participate in group discussions. The second user (User B) opens the application and logs into the application platform. The login process typically involves verifying the user's credentials, such as username and password, to ensure user security. After logging in, User B wants to access the session page of their target group. User B selects the appropriate group in the application's interface or clicks on the group name in the group list, thereby sending an access request to the server. Upon receiving User B's access request, the server verifies whether User B has permission to access the target group's session page. This involves checking if User B's terminal score has reached a predetermined score, or confirming whether User B has already obtained access through other means. If User B has permission to access the target group's session page, the server sends the session page content to User B's terminal. The session page typically includes the group's history, a list of currently online members, message input boxes, and various interactive controls, such as send message buttons and file upload buttons. Within the target group's session page, the server includes a link generation interactive control. This control allows User B to generate an entry link for inviting others to join the target group. When User B clicks the generate link interactive control, the server generates a unique invitation link and displays it on the session page. User B can then share this link with others, inviting them to join the target group. User B can now view and participate in the target group's discussions and communicate with other members in real time. By generating and sharing invitation links, User B can easily invite other users to join the group, expanding the group's influence and activity. The application's ability to display the target group's session page to a second party and provide the functionality to generate invitation links enhances the user's interactive experience and group activity.

As an example, suppose there is a group called "City Explorers," a platform for outdoor enthusiasts to share travel experiences and plan adventures. User B (the second user) is a member of this group and wants to access the group's session page through the application. User B opens the "City Explorers" application and logs in with his username and password. The application verifies User B's credentials to ensure he is a legitimate user. After logging in, User B sees a list of groups on the application's main interface. He clicks on the "City Explorers" group, sending a request to the server to access the group's session page. Upon receiving User B's access request, the server checks whether User B has permission to access the "City Explorers" group's session page. This may include verifying whether User B's terminal score has reached a predetermined score, or confirming whether User B has already obtained access through other means. If User B has permission to access the group's session page, the server sends the "City Explorers" group's session page content to User B's terminal. The session page displays the group's history, including travel photos, adventure plans, and discussion topics shared by members. There is also an online member list on the page, showing the currently online group members. In a prominent location on the conversation page, the server includes an interactive control to generate an invitation link. This control might be a button labeled "Generate Invitation Link." When user B clicks this button, the server generates a unique invitation link and displays it on the conversation page. This link can be used to invite others to join the "City Explorers" group. The conversation page of the target group is displayed to the second user, providing the functionality to generate an invitation link. This design not only enhances the interactivity and social nature of the application but also helps users expand their social circles, improving the overall user experience.

In this way, by displaying the target group's conversation page to a second user and providing interactive controls within the page to generate entry links, the application can significantly enhance the user's social interaction experience and group activity. Specifically, when a second user logs into the application platform and accesses the target group's conversation page, the server responds to their access request, displaying a conversation page containing elements such as history, a list of online members, and message input boxes. This process not only allows users to participate in group discussions in real time but also empowers them to easily invite others to join the group through the generation of interactive link controls. This not only enhances users' sense of belonging and participation but also expands the group's influence through social sharing mechanisms, thereby increasing the overall user stickiness and activity of the application.

In step 1520, in response to the link creation operation of the second object in the session page of the target group, the target group name of the target group and the terminal identifier of the second object are obtained.

The terminal identifier of the second object is used to mark the second object in order to distinguish the second object from other object terminals.

In this specific implementation, when the second object wants to create an entry link to the target group, the second object will trigger a link generation interaction control in the target group's session page. Based on this, the server will receive the trigger event of the second object's link generation interaction control and, in response to the link creation operation of the second object in the target group's session page, obtain the target group name of the target group and the terminal identifier of the second object from the background log.

In some embodiments of the application, when a second object wants to create an entry link to a target group, the process involves multiple steps to ensure that the link generation is secure and traceable. The second object clicks or triggers an interactive control, such as a button or link generator, that dynamically generates the link on the target group's session page. Sending a trigger event sends a trigger event to the server, notifying the server that the second object wants to generate an entry link. Upon receiving the trigger event, the server responds to the second object's link creation operation. The server retrieves the name of the target group from its database or group management module. This name is the group's identifier, used to display and identify the group in the link. The server obtains the second object's terminal identifier from background logs or user session management. This identifier is unique and used to mark the second object's terminal to distinguish it from other users' terminals. The terminal identifier is not only used to mark the second object but may also be used to detect link generation and usage, ensuring the link's security and traceability. The server uses the obtained target group name and the second object's terminal identifier to generate a unique entry link. This link contains the necessary information to allow other users to join the target group. The generated entry link is sent back to the second object's terminal, displayed on the session page, or provided to the second object in other ways (such as by copying to the clipboard).

As an example, suppose there is a group called "Photography Enthusiasts Community," a platform for photography enthusiasts to exchange techniques and share their work. User B (the second user) is an active member of this group and wants to invite his friends to join. User B logs into the "Photography Enthusiasts Community" application and accesses the group's session page. The page displays the group's history, a list of online members, and a button to generate an invitation link. User B clicks the "Generate Invitation Link" button, triggering the link generation interactive control. This action sends a trigger event to the server, indicating that User B wants to generate an entry link. Upon receiving User B's trigger event, the server begins responding to the user's link creation operation. The server retrieves the group name of "Photography Enthusiasts Community" from its database; this is the group's identifier and will be used in the invitation link. The server obtains User B's terminal identifier from the background logs. This identifier is unique and used to identify User B's terminal, ensuring the security and traceability of the invitation link. The server uses the retrieved group name and User B's terminal identifier to generate a unique invitation link. This link contains the necessary information, allowing other users to join the "Photography Enthusiasts Community" group. The generated invitation link is sent back to User B's device and displayed on the session page. User B can copy this link and share it with his friends via email, social media, or other means.

In step 1530, a group string is generated based on the target group name and the terminal identifier.

A group string is a randomly generated string. Group strings are typically unique, identifying the target group; different groups will have different group strings.

In the specific implementation of this embodiment, a pseudo-random number generation algorithm or a predetermined encryption algorithm can be used to generate a random string based on the target group name and terminal identifier, and this random string can be used as the group string for the target group. The group string for the target group must be unique. The predetermined encryption algorithm includes, but is not limited to, the SHA-256 encryption algorithm.

In some embodiments, to generate a unique group string based on the target group name and terminal identifier, obtain the name of the target group, such as "Photography Enthusiast Community". Obtain the terminal identifier of the second object, such as a user's device ID or a unique session token. Combine the target group name and terminal identifier into a single string. This can be achieved by simply concatenating the two strings, for example: "Photography Enthusiast Community" + "Device ID12345". Select a predetermined encryption algorithm, such as SHA-256, to generate the group string. SHA-256 is a secure hash algorithm that generates fixed-length hash values with good uniqueness and tamper resistance. Hash the combined string using the selected encryption algorithm. For example, hash "Photography Enthusiast Community Device ID12345" using the SHA-256 algorithm to generate a unique hash value. Use the generated hash value as the group string. This string, generated based on the target group name and terminal identifier, is unique and can be used to identify the target group. Before using the group string in actual applications, its uniqueness should be verified. This can be done by checking if the same group string already exists in the database. If it does, the group string needs to be regenerated. The verified group string is stored in the database and associated with the target group and the terminal identifier of the second object. The group string is used to identify the target group and referenced when needed (such as when generating an invitation link).

In step 1540, if it is determined that the group string satisfies the first condition, the group string is encoded into an entry link, and the entry link is displayed for the second object.

The first condition is used to implement conflict detection of group strings, in order to determine whether the group string of the target group is unique and whether it is a duplicate of the group string of other groups.

In this specific implementation, firstly, the group string is checked for uniqueness based on a first condition. If the randomly generated group string is unique, then the group string satisfies the first condition. Next, the group string is encoded using URL encoding or a custom encoding rule to generate the entry link of the target group, wherein the entry link of the target group is unique.

In some embodiments, the uniqueness of the group string must be ensured before generating the entry link to avoid conflicts with group strings from other groups. A group string is generated based on the target group name and terminal identifier. This can be achieved by hashing the combined string using an encryption algorithm such as SHA-256. Next, the uniqueness of the generated group string is checked. This typically involves querying a database to confirm whether the group string already exists. If the group string already exists in the database, it means it conflicts with another group's group string and does not meet the first condition. If the group string does not exist in the database, it means it is unique and meets the first condition. Once it is determined that the group string meets the first condition (i.e., it is unique), it can be encoded into an entry link. Encoding can use standard URL encoding rules to ensure the group string is securely transmitted in the URL. Custom encoding rules can also be used to increase the complexity of the entry link and prevent easy guessing or abuse. The encoded group string is then combined with the application's domain name or a specific routing path to create the entry link for the target group. For example, if the application's domain name is `example.com` and the encoded group string is `abc123`, then the entry link might be `https://example.com/join/abc123`. The generated entry link is displayed to the second object. This can be achieved by displaying a button or link in the application's interface. The second object can copy this entry link and share it with others via email, social media, or other means, inviting them to join the target group. The application ensures that each entry link is unique and secure, effectively preventing group string conflicts, while providing users with a convenient invitation mechanism.

In a specific example, the entry link can be formatted as "https://example.com/group?token=xxxx", where "xxxx" represents the group string of the target group.

The advantage of this embodiment is that by setting up a link generation interactive control in the conversation page of each group, group members can directly trigger the link generation interactive control to generate an entry link for a single group, improving operational convenience. Furthermore, when generating the entry link, the server generates a unique random string based on the group name and the terminal identifier of the terminal triggering the control. This random string is encoded according to predetermined rules and a fixed format, ensuring that entry links for different groups are different and that the generated entry links have good format consistency.

Referring to Figure 16, in some embodiments, the process of determining that the group string satisfies the first condition specifically includes, but is not limited to, the following steps 1610-1630:

Step 1610: Obtain the pre-defined relationship lookup table;

Step 1620: Compare the group string with each candidate string;

Step 1630: If the group string is determined to be different from all candidate strings, then the group string satisfies the first condition.

Steps 1610-1630 are described in detail below.

In step 1610, a predetermined relationship lookup table is obtained.

The predefined relationship lookup table is used to indicate the correspondence between each candidate group and the candidate string.

Candidate groups refer to other session groups created within the application platform.

Candidate strings refer to group strings of other session groups in the application platform.

In this specific implementation, the predefined relationship lookup table is stored by the server in the background. The candidate groups and their corresponding candidate strings in the predefined relationship lookup table are continuously updated as entry links for each group are created. The candidate strings for each candidate group in the application are recorded in the predefined relationship lookup table. Therefore, with authorization, the predefined relationship lookup table maintained by the server can be directly accessed.

In some embodiments, the pre-defined relationship lookup table is a key data structure in the application platform used to manage the mapping between groups and group strings. The pre-defined relationship lookup table is a data structure that records the mapping relationship between all candidate groups and their corresponding candidate strings in the application platform. Each candidate group has a unique candidate string, generated using a specific algorithm to uniquely identify the group. Candidate groups refer to other session groups already created in the application platform. These groups may have different topics, purposes, and members. The candidate string is the group string for each candidate group, generated by combining the group name and terminal identifier, and processed using an encryption algorithm. The pre-defined relationship lookup table is typically stored in a backend database on the server. Whenever a new group entry link is created, the server generates a new group string, associates it with the corresponding group, and then updates the pre-defined relationship lookup table. This update is dynamic; as groups are created and entry links are generated, the pre-defined relationship lookup table is continuously updated to reflect the latest group and group string mapping relationship. With authorization, applications can access the pre-defined relationship lookup table maintained by the server. This is typically achieved through API requests. The application sends a request to the server to retrieve the pre-defined relationship lookup table data. After verifying the validity of the request, the server returns the contents of a predefined relationship lookup table. Once the application obtains this table, it can use it to verify the uniqueness of group strings, ensuring no conflicts occur when generating new entry links. The application can also use the predefined relationship lookup table to parse entry links, determine the group corresponding to the link, and thus allow users to join the appropriate group.

In step 1620, the group string and each candidate string are compared to determine whether the group string is unique.

In some embodiments, ensuring the uniqueness of the group string is crucial in the application, as it directly relates to group identification and security. The application generates a group string based on the target group's name and the terminal identifier of a second object. This is typically achieved by hashing the combined string using an encryption algorithm such as SHA-256. The application needs to access a predefined lookup table maintained by the server, which contains all existing candidate groups and their corresponding candidate strings. This can be achieved by sending an API request to the server, which, after verifying the request's validity, returns the predefined lookup table data. The application compares the generated group string with each candidate string in the predefined lookup table. If the generated group string is different from all candidate strings, then the group string is unique, satisfying the first condition. If the generated group string is the same as any candidate string, then the group string already exists, does not satisfy the first condition, and needs to be regenerated. If the group string is unique, the application can continue to use it to generate entry links. If the group string is not unique, the application needs to regenerate the group string and compare it again until a unique string is found. To improve comparison efficiency, applications can use data structures such as hash tables to store candidate strings in a predefined lookup table, allowing the comparison process to be completed in constant time. Applications can also check the uniqueness of group strings immediately upon generation, rather than generating them first and then comparing them, to reduce unnecessary computation.

In step 1630, if it is determined that the group string is different from all candidate strings, then the group string is determined to satisfy the first condition.

In some embodiments, if the group string is determined to be different from all candidate strings, indicating that the group string does not conflict with other candidate strings and the group string is unique, then the group string is determined to satisfy the first condition. If the group string is determined to be the same as one of the candidate strings, indicating that the group string conflicts with a candidate string and the group string is not unique, and the same random string represents at least two groups, then the group string is determined to not satisfy the first condition. A new random string is then generated based on the target group name and the terminal identifier of the second object. If the generated random string is unique, it is encoded as the group string of the target group.

As an example, suppose there's an application called "Healthy Living Community" where users can create and join various health-related groups. When a user wants to create a new group and generate an entry link, the application needs to ensure that the generated group string is unique. User A wants to create a new group called "Vegetarianism Exchange." He fills in the group name in the application and submits a creation request. The application generates a group string based on the group name and A's device ID. For example, it might use the SHA-256 algorithm to hash "Vegetarianism Exchange" and User A's device ID, generating a unique hash value as the group string. After generating the group string, the application needs to retrieve a predefined lookup table maintained by the server. This is typically achieved by sending an API request to the server. After verifying the request's validity, the server returns all current candidate groups and their corresponding candidate strings. The application compares the generated group string with all candidate strings in the predefined lookup table. This can be done by iterating through the predefined lookup table, comparing the group string with each candidate string one by one. If the generated group string is different from all candidate strings, then the group string is unique, satisfying the first condition. If the generated group string is identical to any candidate string, it means that the group string already exists, does not meet the first condition, and needs to be regenerated. Once the group string is determined to be unique, the application encodes it into an entry link. For example, the group string is encoded using URL encoding rules and combined with the application's domain name to generate a unique entry link. The application displays the generated entry link to user A. User A can share this link with others, inviting them to join the "Vegetarian Exchange" group. A predefined lookup table is retrieved, the group string is compared with candidate strings, the uniqueness of the group string is determined, and a unique entry link is generated. This design ensures that each group has a unique identifier, prevents group string conflicts, and improves application reliability and user experience.

Figure 17 shows a schematic diagram of the predefined relationship lookup table. Specifically, in the predefined relationship lookup table, the candidate group string for each candidate group is the key, and the group name for each candidate group is the value, so that the group name and other group information of each candidate group can be found through the candidate group string. Among them, the candidate group string "K77qzd" is used to indicate the badminton interest group, the candidate group string "7qe31a5" is used to indicate the tennis interest group, the candidate group string "Zk485qz" is used to indicate the basketball interest group, and the candidate group string "Yq142nm" is used to indicate the table tennis interest group.

The advantage of this embodiment is that by using a predetermined relationship lookup table to store the group information and group strings of each group in key-value pairs, and using the group string as the search keyword and the group information as the value, it is possible to find and retrieve the group information of each group based on the group string (or entry link), thereby improving the efficiency of group information retrieval and transmission. Furthermore, the relationship lookup table can be used to check whether each newly generated group string conflicts with an existing group string, ensuring that the group string (or entry link) of each group is unique.

As shown in Figure 18A, the group members include Object 1, Object 2, and Object 3. After Object 1 opens the basketball interest group's session page, if it wants to generate an entry link for the basketball interest group, Object 1 will click the "Generate Link" button on the session page, causing the server to create an entry link for the basketball interest group.

As shown in Figure 18B, the group members include Object 1, Object 2, and Object 3. Once the entry link is generated, the session page will display the message "Successfully created" and provide the entry link for the basketball interest group: "https://example.comgroup?token=Zk485qz". At this point, Object 1 can copy the entry link and paste it into any editing area in the application platform.

Figure 19 illustrates the process executed by the application server when creating an entry link for a target group. In step 201, the second object selects the target group to generate a shareable link; in step 202, it uploads information such as the target group's name and the second object's terminal identifier; in step 203, it generates a unique group string and stores the group name and other information using this group string as the key; in step 204, it concatenates the group strings into a group link and displays the group link. Specifically, first, the second object selects to generate a shareable link (entry link) for the target group on the target group's session page. Next, it uploads the stored target group's name, the second object's terminal identifier, and other information to the server. The server generates a unique group string based on these information and stores the group name and other information as the value, using this group string as the key. Finally, it concatenates the group strings into a group link and displays the group link, the specific implementation of which is similar to steps 1510-1540 above. For brevity, these details are not elaborated further.

Referring to Figure 20, in some embodiments, when the target group includes multiple subgroups, the process of creating the target group specifically includes, but is not limited to, the following steps 2010-2040:

Step 2010: In response to the link creation request from the second object, display the link creation page;

Step 2020: Based on the input operation of the second object on the link creation page, determine the subgroup links of each target subgroup;

Step 2030: Generate a group string based on multiple subgroup links and the terminal identifier of the second object;

Step 2040: If it is determined that the group string meets the first condition, then encode the group string into an entry link and display the entry link for the second object.

Steps 2010-2040 are described in detail below.

In step 2010, in response to the link creation request of the second object, the link creation page is displayed.

The link creation page is used to provide objects with the ability to integrate multiple groups into one large group and create entry links for this large group, so as to realize the aggregation and nesting of groups, allowing objects to quickly access multiple groups.

In this specific implementation, when a second object logs into the application platform and wants to share multiple groups through a single entry link, the second object sends a link creation request, triggering a composite group link generation process on the application platform. Based on this, the server responds to the second object's link creation request by displaying a link creation page on the application platform, allowing the second object to add group information for the multiple groups to be shared within the same entry link. This group information includes, but is not limited to, the group links (entry links) for each group and the group names.

In some embodiments, when a second object wants to share multiple groups through a single entry link, the application needs to provide a link creation page so that the object can consolidate multiple groups and create a single entry link for a large group. The second object logs into the application platform and accesses the interface where it wants to create a composite group link. The object clicks the "Create Link" button or option to send a link creation request. Upon receiving the link creation request, the application triggers the composite group link generation process. This is designed to allow objects to consolidate multiple groups into a single large group and create a unified entry link. The server responds to the link creation request by displaying the link creation page on the application platform. The link creation page provides a user interface that allows objects to add and manage the groups to be consolidated. The object adds group information for the multiple groups to be consolidated on the link creation page. Group information includes, but is not limited to, the group links (entry links) for each group and the group name. The object can view and manage the list of added groups. The object can add new groups and delete or edit existing group information. Once the object has completed adding and managing the groups, it can click the "Generate Link" button. The application collects all added group information and generates a composite group link. The composite group link allows the object to access multiple groups through a single entry link. When other users click this link, they will be able to access all the integrated groups, enabling aggregation and nesting between groups. The object can share the generated composite group link with other users via email, social media, or other means. It allows for quick invitations to join multiple groups, improving the efficiency of social interaction. The application can respond to the second object's link creation request, displaying the link creation page and allowing the object to integrate multiple groups into a unified entry link.

In step 2020, the subgroup links of each target subgroup are determined based on the input operations of the second object on the link creation page.

Subgroup links are used to connect to the session page of the target subgroup, allowing objects to quickly navigate to or access the session page of the target subgroup.

In this specific implementation, the target group of the entry link to be created by the second object is the parent group of multiple groups to be shared, and the multiple groups to be shared through a single entry link are multiple target subgroups of the target group. Based on this, firstly, the second object enters the group information of each target subgroup (e.g., group name, entry link of the target subgroup, etc.) on the link creation page. Then, in response to the input operation of the second object on the link creation page, the server extracts the content entered by the second object for each target subgroup, obtaining the subgroup links of each target subgroup.

In some embodiments, when creating an entry link that can be shared across multiple groups, the second object needs to specify details of each target subgroup on the link creation page. The second object logs into the application platform and accesses the link creation page. This page provides an interface for entering and managing group information. The object enters the group information for each target subgroup on the link creation page. This information typically includes the group name and the entry link for the target subgroup. The object can enter this information manually or select and add it from an existing list of groups in the application. The server responds to the second object's input by parsing and extracting the input. The server identifies and extracts the entry link for each target subgroup; these links are URLs that connect to the target subgroup's session page. To ensure the validity of the subgroup links, the server may validate each link. The validation process may include checking whether the link points to a valid group page and whether the object has permission to access these groups. Once the subgroup links are extracted and validated, the server associates these links with the target groups and stores them in the application's database. Based on the stored subgroup links, the server generates a composite group link. This link contains information about the entry links to all target subgroups. A composite group link can be a unique URL that, when clicked, displays a list of all target subgroups or directly navigates to the conversation pages for those groups. The second object can share the generated composite group link with other users through various channels such as email and social media. Users receiving the link can click it to quickly access all integrated target subgroups and enjoy a convenient group access experience.

To save space, the process of determining the subgroup links of each target subgroup based on the input operation of the second object on the link creation page in this application embodiment will be described in detail below. It will not be repeated here.

The specific implementation process of steps 2030-2040 is similar to that of steps 1530-1540 above. The difference is that the group string in step 1530 is generated based on the target group name and terminal identifier, while the group string in step 2030 is generated based on multiple subgroup links and terminal identifiers. For the sake of brevity, these details will not be elaborated further.

As shown in Figure 21A, when the second object wants to create a common entry link for multiple groups, the application platform displays a page for creating a composite group link. The page displays a type editing area for selecting the information entry type for subgroups and a value editing area for entering specific information about the subgroups. Additionally, the page provides a group deletion control for deleting group information from a specific subgroup and a group addition control for adding a subgroup to the group information entry area. At this point, the second object selects "Subgroup Name" as the information entry type for a subgroup in the type editing area of the first row, and then enters "Basketball Interest Group" in the value editing area of the first row. Similarly, the second object selects "Subgroup Link Name" as the information entry type for a subgroup in the type editing area of the second row, and then enters the entry link for the tennis interest group, "https://example.com/group?token=7qe31a5", in the value editing area of the second row to create a common entry link for both the basketball and tennis interest groups.

As shown in Figure 21B, when the second object selects "Subgroup Name" as the data type for the target subgroup in the type editing area of the first row, a pop-up window will display a list of all groups in the application platform when the second object clicks the value editing area of the first row. This list includes groups such as the Basketball Interest Group and the Badminton Interest Group. If the second object selects the Basketball Interest Group from the list, "Basketball Interest Group" will be displayed in the value editing area of the first row, allowing the second object to quickly select the group to add. Based on the second object's selection, the value editing area corresponding to the "Subgroup Name" will be automatically filled.

The advantage of this embodiment is that it provides a way to package group links of multiple groups into a new entry link, realizing the combination of group links of multiple target subgroups. It can generate a single entry link based on the group name or group link of each target subgroup, allowing objects to quickly access multiple groups by clicking the nested link (entry link). It also allows objects to share multiple groups with other objects while sharing a single entry link, which brings convenience to objects to quickly access multiple groups and improves the efficiency of group information transmission.

Since the second object can enter the subgroup name or subgroup link of the target subgroup on the link creation page, the server's processing method will vary depending on the group information entered by the second object.

In some embodiments, determining the subgroup links for each target subgroup includes:

If it is determined that the second object entered the subgroup name of the target subgroup in the link creation page, then a subgroup string is generated based on the subgroup name, and the subgroup string is encoded into a subgroup link.

In the specific implementation of this embodiment, if it is determined that the second object entered the name of a subgroup of the target subgroup on the link creation page, then a subgroup link of the target subgroup needs to be generated based on the subgroup name. The specific implementation process is similar to the method of generating the entry link in steps 1530-1540 above. To save space, it will not be described in detail.

If it is determined that the second object entered a subgroup link of the target subgroup in the link creation page, then the subgroup link is subject to a second verification, and the subgroup link that passes the second verification is used to generate the group string.

In the specific implementation of this embodiment, if it is determined that the second object entered a subgroup link of the target subgroup on the link creation page, the entered subgroup link needs to be formatted and validated for correctness to ensure that the entered subgroup link is correct. Then, the validated subgroup link and other target subgroup links are combined to form a group link list, and a group string is generated using the multiple subgroup links in the group link list.

The advantage of this embodiment is that it takes into account the different group information of the input target subgroups and sets up corresponding processing steps. For the input subgroup name, it converts it into a subgroup link; for the input subgroup link, it performs a verification operation, thereby generating the subgroup links of each target subgroup that need to be combined, so as to combine multiple subgroup links into a single entry link and improve the efficiency of group management.

Referring to Figure 22, in some embodiments, the process of performing a second verification on subgroup links specifically includes, but is not limited to, the following steps 2210-2250:

Step 2210: Validate the format of subgroup links;

Step 2220: If the format verification is successful, obtain the predefined relationship lookup table;

Step 2230: Parse the subgroup string of the target subgroup from the subgroup link;

Step 2240: Compare the subgroup string with each candidate string;

Step 2250: If the subgroup string is determined to be the same as a candidate string, then the second verification is deemed successful.

Steps 2210-2250 are described in detail below.

The predefined relationship lookup table is used to indicate the correspondence between each candidate group and the candidate string, which has been schematically described in Figure 17 above and will not be repeated here.

In step 2210, firstly, the required link format for the entry links of each group in the application platform is invoked. Next, based on the required link format for the entry links of each group, the subgroup links are format-validated to determine whether their format matches the standard link format.

In some embodiments, within an application platform, entry links for various groups typically need to adhere to certain format specifications to ensure link consistency and identifiability. The application platform first needs to define the format of the entry links. This format may include the protocol (such as HTTP or HTTPS), domain name, path, and query parameters. For example, a typical entry link format might be: `https://example.com/group?id=GROUP_ID`, where `GROUP_ID` is the unique identifier of the group. The application stores the defined link format in a configuration file or database on the server for retrieval and verification when needed. When an entry link needs to be generated or verified, the application retrieves the predefined link format from the configuration file or database. This is achieved using variables or constants in the programming language to ensure the consistency and maintainability of the link format. Format validation of subgroup links is a crucial step in ensuring link validity and security. The application uses regular expressions or other string manipulation methods to check whether subgroup links conform to the defined link format. For example, regular expressions can be used to match the link's protocol, domain name, path, and query parameters. The application iterates through each subgroup link, performing format validation one by one. If the subgroup link format matches the defined link format, validation passes. If the subgroup link format does not match, validation fails, and the application needs to notify the user or take other measures. For subgroup links that pass validation, the application can continue to use them to generate compound groups. For subgroup links that fail validation, the application may need to prompt the user to re-enter or correct the link format. To improve efficiency, the application can automate the format validation process, providing real-time feedback to the user on whether the links meet the requirements. This can be achieved through front-end JavaScript validation or back-end server validation.

In step 2220, if the format of the subgroup link matches the link format, the format verification is deemed successful, indicating that the input subgroup link conforms to the predetermined group link format, and the correctness and existence of the subgroup link need to be verified. Based on this, the predetermined relationship lookup table is obtained in the manner described in step 1610 above. If the format of the subgroup link does not match the link format, the format verification is deemed unsuccessful, and the second verification is deemed unsuccessful, prompting the second object to re-enter the correct subgroup link.

In some embodiments, if the format of the subgroup link matches the defined link format, the application determines that the format validation has passed. The input subgroup link is structurally correct and conforms to the application's expected format. Although the format validation has passed, the application still needs to verify the correctness and existence of the subgroup link. This is to ensure that the link is not only structurally correct but also actually points to a valid group. The application retrieves a predefined lookup table maintained by the server, following the previously defined steps. This lookup table contains all existing groups and their corresponding group strings. The application compares the group identifier in the subgroup link with the record in the predefined lookup table. If the group identifier exists in the lookup table and the corresponding information matches, then the validation passes. If the group identifier does not exist or the information is inconsistent, the validation fails. If the correctness and existence validations pass, the application can continue to use the subgroup link to generate composite groups. If the validation fails, the application needs to notify the second object and request that the correct subgroup link be re-entered. If the format of the subgroup link does not match the defined link format, the application determines that the format validation has failed. The input link is structurally incorrect and does not conform to the application's expected format. For subgroup links that fail format validation, the application needs to remind the second object to re-enter the correct link. This can be achieved by displaying error messages, highlighting input fields, or providing formatting guidelines. To improve user experience, the application can provide real-time formatting validation feedback to help secondary users correct input errors promptly. This can be achieved through front-end JavaScript validation, checking the format of entered links in real time.

In step 2230, since the subgroup link consists of a fixed string and a group string, the subgroup link is split according to the link format to parse out the subgroup string of the target subgroup.

In some embodiments, the application needs to explicitly specify the format of the subgroup link. The link format can be `https://example.com/group?id=GROUP_STRING`, where `GROUP_STRING` is the group string. The fixed string portion includes the protocol (e.g., `https://`), the domain name (e.g., `example.com`), and the path (e.g., `/group`). The application uses string manipulation methods to split the subgroup link into the fixed string and the group string. Once the link is split, the application can extract the group string portion. For example, if the link is `://example.com/group?id=abc123`, then the group string is `abc123`. If the group string contains URL-encoded characters, the application needs to decode them to obtain the original group string. For example, if the group string is `abc%20123`, the application needs to decode it to `abc 123`. After extracting the group string, the application may need to validate it to ensure it conforms to the expected format and length. Once validation is successful, the application can store the group string in memory or use it directly to access the target subgroup's session page. If errors occur during the splitting or extraction of group strings, the application needs to capture these errors and provide appropriate feedback to the user. For example, if a link is incorrectly formatted, the application can display an error message prompting the user to re-enter the correct link.

In step 2240, for each candidate string, the candidate string is compared with the subgroup string to determine whether the subgroup string in the input subgroup link is a group string of a certain group.

In some embodiments, the application needs to access a predefined lookup table maintained by the server. This lookup table contains all existing groups and their corresponding group strings. The application extracts the subgroup string from the input subgroup link. This is typically done by parsing specific parts of the link. For each candidate string, the application compares it with the subgroup string. This can be done with a simple string comparison operation. If the subgroup string is exactly the same as a candidate string, then it can be determined that the subgroup string in the input subgroup link corresponds to the group to which the candidate string belongs. Once a matching candidate string is found, the application can record the matching result, including the group's identifier, name, and other information. Based on the matching result, the application can perform appropriate actions, such as allowing the user to access the group's session page or adding the group to a compound group link. If the subgroup string does not match any of the candidate strings, then it can be determined that the subgroup string in the input subgroup link does not correspond to any existing group. The application needs to notify the user that the input link may be incorrect or the group may not exist. The application can use a data structure (such as a hash table) to store the candidate strings in the predefined lookup table, allowing the comparison process to be completed in constant time.

In step 2250, if the subgroup string is determined to be the same as a candidate string, it indicates that the input subgroup string actually exists and can point to a group, then the second verification is determined to be successful. If the subgroup string is determined to be different from any candidate string, it indicates that the input subgroup string does not exist and cannot point to a group, then the second verification is determined to be unsuccessful.

In some embodiments, the application compares the input subgroup string with each candidate string in a predetermined lookup table. This lookup table contains all existing groups and their corresponding group strings. If the subgroup string is exactly the same as a candidate string, it can be determined that the input subgroup string exists and can point to the corresponding group. When the subgroup string matches a candidate string, the application determines that the second verification has passed. The input subgroup link is valid and can be used to access or merge the corresponding group. The application can record information about the matched groups, such as the group identifier, name, etc. This information can be used for operations such as generating compound group links or allowing users to access groups. If the subgroup string is different from all candidate strings, it can be determined that the input subgroup string does not exist and cannot point to any group. When the subgroup string does not match any candidate string, the application determines that the second verification has failed. This means that the input subgroup link is invalid and cannot be used to access or merge groups. In the case of a failed second verification, the application needs to notify the user that the input link may be incorrect or the group may not exist. This can be achieved by displaying an error message, prompting the user to re-enter the link, etc.

The advantage of this embodiment is that it performs format verification on the input subgroup links, and when it is determined that the input subgroup links conform to the predetermined group link format, it performs correctness and existence verification on the subgroup links according to the candidate strings of each candidate group stored in the predetermined relationship lookup table, so as to determine that the input subgroup links are real and can accurately point to a certain group in the application, thereby improving the accuracy of link creation.

In this embodiment, the link creation page has multiple group information addition windows and a group supplement control.

The group information addition window is used to provide the object with the name of the subgroup or the link of the subgroup to which the target subgroup is added.

The group addition control is used to add a group information entry area for a subgroup, thereby increasing the number of target subgroups in the target group to be merged.

Please refer to Figure 23. In some embodiments, step 2020 specifically includes, but is not limited to, the following steps 2310-2320:

Step 2310: Based on the triggering of the group supplement control by the second object, display the supplement window on the link creation page;

Step 2320: Based on the input operations of the second object in the multiple group information addition window and supplement window, determine the subgroup links of each target subgroup.

Steps 2310-2320 are described in detail below.

In step 2310, if the second object has filled in the subgroup information of each target subgroup in the subgroup information editing area displayed on the link creation page, but has not yet filled in the subgroup information of all target subgroups to be included, the second object will trigger the group supplement control on the link creation page. Based on this, the server will detect the trigger event of the group supplement control and continue to display more supplement windows on the link creation page so that the second object can continue to enter the subgroup information of the target subgroups to be included.

In some embodiments, within an application platform, when a second object edits subgroup information on a link creation page, it may need to add multiple target subgroups. If the second object has not yet completed the input of all target subgroups, it can continue adding more subgroup information by triggering a group add-on control. The second object enters the information for each target subgroup in the subgroup information editing area of the link creation page. This information typically includes the group name and entry link. When the second object deems it necessary to add more target subgroups, it triggers a group add-on control on the link creation page. This is usually a button or link labeled "Add More," "Add Group," etc. The server detects the triggering event of the group add-on control via front-end JavaScript or other technologies. The second object can continue to enter the subgroup information of the target subgroups to be included in a new add-on window. This process can be repeated multiple times until the second object has completed the input of all target subgroups. For each newly added subgroup information, the application performs format validation and existence validation to ensure that the entered information is valid and correct. Once the validation passes, the server stores this information in the database and associates it with the composite group link. Once all target subgroup information has been entered and verified, the server generates a composite group link containing entry links for all target subgroups. The application allows second objects to dynamically add information for multiple target subgroups on the link creation page, enhancing user interface flexibility and user experience.

The specific implementation process of step 2320 is similar to the two cases of determining the subgroup links of each target subgroup mentioned above, and will not be repeated here for the sake of saving space.

As shown in Figure 25A, after the second object enters the subgroup information for the basketball and tennis interest groups in the two editing areas displayed on the link creation page, and needs to enter more subgroup information, the second object will click the group supplement control (the plus button in the figure) on the link creation page. At this time, the link creation page will display a new editing line (supplement window). Based on this, the second object selects "Subgroup Name" in the type editing area of the newly added editing line and enters "Badminton Interest Group" in the value editing area, so that the generated entry link can simultaneously navigate other objects to the basketball, tennis, and badminton interest groups.

The advantage of this embodiment is that it provides an input channel for adding target subgroups to a target group, and can flexibly and freely determine the number of target subgroups to be included in a target group, thereby improving the flexibility and diversity of group management.

In this embodiment, the link creation page has multiple group information addition windows and a group deletion control.

The group deletion control is used to delete the group information of a subgroup, thereby reducing the number of target subgroups to be merged into the target group.

Please refer to Figure 24. In some embodiments, step 2020 specifically includes, but is not limited to, the following steps 2410-2420:

Step 2410: Based on the triggering of the group deletion control by the second object, delete one of the multiple group information addition windows;

Step 2420: Based on the input operation of the second object in the window of the retained multiple group information, determine the subgroup links of each target subgroup.

Steps 2310-2320 are described in detail below.

In step 2410, after the second object fills in the subgroup information of each target subgroup in the subgroup information editing area displayed on the link creation page, it finds that some subgroups are not suitable for placement in the target group. The second object will trigger the group deletion control corresponding to the target subgroup to be deleted on the link creation page. Based on this, the server will detect the triggering event of the group deletion control for the target subgroup and clear an editing row corresponding to the target subgroup and the subgroup information in the editing row on the link creation page.

In some embodiments, within an application platform, when creating a composite group link, a second object may find that some of its added subgroups are not suitable to be included in the target group. In this case, the second object can remove these unsuitable subgroups by triggering a group deletion control. The second object enters or selects information for each target subgroup in the subgroup information editing area of the link creation page. This information typically includes the group name and entry link. After completing the input of all subgroup information, the second object may review these subgroups and find that some are not suitable to be included in the target group. For each unsuitable subgroup, the second object triggers the corresponding group deletion control on the link creation page. This is typically a button, link, or icon labeled "Delete" or "Remove," located next to each subgroup information editing line. The server detects the triggering event of the group deletion control via front-end JavaScript or other technologies, involving sending an AJAX request to the server to notify it that specific subgroup information needs to be deleted. Once the server detects the triggering event, it responds to the request, clearing an editing line corresponding to the target subgroup on the link creation page, along with all subgroup information in that line. After deleting the subgroup information, the server updates the composite group link, removing the entry link of the deleted subgroup. This ensures that the final generated composite group link only includes target subgroups deemed appropriate by the second object. If the second object is satisfied with the subgroup selection, it can save the changes. The server stores the updated subgroup information in the database and associates it with the composite group link. The server generates a composite group link containing entry links to all selected target subgroups. This link can be shared by the second object with other users, allowing them to access all integrated target subgroups. The application allows the second object to dynamically remove inappropriate subgroups during link creation, improving the flexibility of the user interface and user experience. This design allows users to easily adjust and optimize the composite group link, ensuring it only contains relevant and appropriate target subgroups.

The specific implementation process of step 2420 is similar to the two cases of determining the subgroup links of each target subgroup mentioned above, and will not be repeated here for the sake of saving space.

As shown in Figure 25B, after the second object enters subgroup information for the basketball interest group, tennis interest group, and badminton interest group in the multiple editing areas displayed on the link creation page, the second object wants the generated entry link to simultaneously navigate to the tennis interest group and the badminton interest group for other objects, but not to the basketball interest group. At this point, the second object will click the group deletion control (the minus button in the figure) after the editing row of the "basketball interest group" subgroup information, deleting the basketball interest group's group information on the link creation page, retaining only the tennis interest group's group link and the badminton interest group's group name.

The advantage of this embodiment is that it provides an input channel for the group information of the target subgroups of the target group to be deleted, and can flexibly and freely adjust the target subgroups to be included in a target group, thereby improving the flexibility of group management.

As shown in Figure 26, which is an overall flowchart of creating an entry link according to another embodiment of this application, in step 401, the second object inputs multiple group names or group links, and a link title to generate a shareable link; in step 402, the group names are converted into group links; in step 403, the list of multiple group links, the terminal identifier of the second object, the link title, and other information are uploaded; in step 404, a unique group string is generated, and the group string is used as a key to store the group list and other information; in step 405, the group strings are concatenated into an entry link and displayed. This describes the process executed by the application server when creating an entry link for a target group consisting of multiple subgroups. Specifically, firstly, the second object inputs multiple group names or group links, and the link title of the target group on the link creation page to generate a shareable link, the specific implementation process of which is similar to steps 2010-2020 above. Next, the application's front-end server converts the group name input by the second object into a group link, and uploads a list of multiple group links, the second object's terminal identifier, terminal title, etc., to the application's back-end server. The back-end server generates a unique group string and stores the group list and other information using this group string as the key. Finally, the group strings are concatenated into an entry link, which is then displayed. The specific implementation process is similar to steps 2030-2040 above. To save space, it will not be elaborated further.

Detailed description of how the entry link is displayed as the target group name with a link tag in this application embodiment.

Since the entry links in this application embodiment can exist in various scenarios such as session windows, group announcements, and documents, when entry links are placed together with other text data, it is often necessary to identify and display the entry links in dense text data in order to clearly indicate the target group based on the entry links. Based on this, this application embodiment provides a scheme for identifying and displaying entry links based on regular expressions, which can improve the efficiency of entry link location and the efficiency of group information transmission.

Referring to Figure 27, in some embodiments, the process of displaying the entry link as the target group name with a link tag specifically includes, but is not limited to, the following steps 2710-2720:

Step 2710: Based on the predefined regular expression, locate the entry link on the first page and extract the group string from the entry link;

Step 2720: If it is determined that the group string is associated with the target group name of the target group, then the entry link is displayed as the target group name with the link tag.

Steps 2710-2720 are described in detail below.

In step 2710, a predefined regular expression is used to indicate the correct representation of the entry link of the target group. The predefined regular expression can be understood as the correct link format of the entry link.

In this specific implementation, firstly, the server checks if any content on the first page matches a predetermined regular expression. Next, the content matching the predetermined regular expression is used as the located entry link. Finally, the entry link is split and the string is extracted according to the required link format to obtain the group string within the entry link.

In step 2720, firstly, a candidate string matching the group string is searched in the predetermined relationship object table, and the group information corresponding to the candidate string matching the group string is extracted. The specific process is similar to steps 2220-2250 above. Next, when a candidate string matching the group string exists, the target group name associated with the group string is determined, and the group name is parsed from the extracted group information to construct the target group name with a link tag. Finally, the entry link is displayed as the target group name with the link tag.

In some embodiments, the application first searches a predefined relational object table based on the group string. This table contains all existing groups and their corresponding group strings. If a candidate string matching the group string is found, the application extracts the group information corresponding to that candidate string. This information typically includes the group name, group identifier, etc. From the extracted group information, the application parses the group name. This is usually a field in the group information that directly represents the group name. The application combines the parsed group name with an entry link to construct a target group name with a link tag. This typically involves wrapping the group name in an HTML `<a>` tag, making it a clickable link. The application displays the target group name with the link tag to the user. When the user clicks this link, they are directed to the corresponding target group's session page.

As shown in Figure 28, which is an overall flowchart of displaying group names and basic group information according to another embodiment of this application, in step 301, the terminal of the first object browses the first page on the application platform, triggering the location and parsing of the entry link on the first page; in step 302, the entry link of the target group is located and identified on the first page; in step 303, the entry link is parsed to obtain the group string; in step 304, the detailed information of the target group is obtained based on the group string; in step 305, the basic group information of the target group is obtained and displayed. The process executed by the application server when parsing the entry link and displaying it as the target group name with a link tag is as follows: Specifically, firstly, the terminal of the first object browses the first page on the application platform. Based on this, the server detects the browsing event of the terminal of the first object on the first page, triggering the location and parsing of the entry link on the first page. The server locates and identifies the entry link of the target group on the first page and parses the entry link to obtain the group string, the specific process of which is similar to step 2710 above.

In some embodiments, the server obtains the detailed information of the target group based on the group string, retrieves the group name of the target group from the detailed information, and displays the group name to the terminal of the first object. The specific process is similar to step 2720 above. Finally, the server obtains the basic group information of the target group from the detailed information and displays the basic group information. The specific process is similar to step 340 above. For the sake of brevity, it will not be described in detail again.

The advantage of this embodiment is that it identifies and locates entry links based on regular expressions, extracts group strings from entry links, and then extracts and displays the group information (target group name, basic group information, etc.) of the target group based on the group strings. This improves the efficiency of locating entry links and the efficiency of transmitting group information.

Detailed implementation diagrams of the group display method in the application of this application embodiment.

The implementation details of the group display method in the application of this application embodiment will be described in detail below with reference to FIG29.

In step 2901, the second target terminal inputs the group names and group link requests of multiple groups into the application platform to generate a composite group link;

In step 2902, the application platform converts the input group name into a group link via the server;

In step 2903, the server combines the converted group links with the input group links to form a group link list;

In step 2904, the server generates a random string based on the group link list, the terminal identifier of the second object terminal, etc.

In step 2905, the server performs key collision detection on the random string. If the detection passes, the random string and the group link list are stored as key-value pairs.

In step 2906, the server encodes the random string into an entry link for a compound group and returns it to the application platform;

In step 2907, the application platform displays the entry link of the composite group to the second object terminal;

In step 2908, the first object's terminal logs into the application and accesses the first page;

In step 2909, the application platform displays the entry link of the composite group as the group name with a link tag;

In step 2910, the mouse of the first object's terminal hovers around the group name with the link tag;

In step 2911, the application platform displays the names of the multiple subgroups included in the composite group, with links attached.

In step 2912, the mouse of the first object's terminal hovers around a subgroup name with a link tag;

In step 2913, the application platform displays the basic information of the subgroup.

In step 2914, the terminal of the first object double-clicks the link marker of the subgroup name of the subgroup;

In step 2915, the application platform determines through the server whether the terminal of the first object is in the subgroup;

In step 2916, the server returns the detection results;

In step 2917, if it is determined that the terminal of the first object is a member of the subgroup, the subgroup's session page is displayed.

It is understood that the specific processes of steps 2901-2907 are similar to steps 2010-2040 in the above embodiments. The specific processes of steps 2908-2909 are similar to step 320 in the above embodiments. The specific processes of steps 2910-2913 are similar to step 330 in the above embodiments. The specific processes of steps 2914-2917 are similar to steps 1110-1120 in the above embodiments. To save space, they will not be described in detail here.

Description of apparatus and devices in embodiments of this application

It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

Figure 30 is a structural schematic diagram of a group display device 3000 in an application provided in this application embodiment. The group display device 3000 in the application includes:

The first display unit 3010 is configured to display a first page in the application. The first page contains the target group name of the target group. The target group name has a link tag for the entry link of the target group. The entry link is created by a second object in the target group and is associated with the target group name of the target group when it is created.

The second display unit 3020 is configured to display basic information of the target group in response to a dwell operation triggered around the target group name. The target area is an area in the first page where the distance between the display position of the target group name and the target area is less than a distance threshold. The basic information is used to prompt the first object whether the link mark has been triggered.

The third display unit 3030 is configured to display the session page of the target group in response to a trigger on a link tag.

In some embodiments, the target group name on the first page is determined in the following way:

If the second object in the target group has enabled name display for the first object's terminal when the entry link is created, then the link tag of the entry link will be constructed as the target group name.

In some embodiments, the target group name on the first page is determined in the following way:

The group name specified for the terminal of the first object when the second object creates the entry link is determined as the target group name corresponding to the terminal of the first object. When the second object creates the entry link, different group names are specified for different object terminals.

In some embodiments, the target group name on the first page is determined in the following way:

Among the multiple candidate group names, the candidate group name that corresponds to the first object preference of the terminal of the first object is determined as the target group name. Among them, the multiple candidate group names are associated with the entry link when the second object creates the entry link.

In some embodiments, the third display unit 3030 is configured as follows:

In response to a trigger on a link tag, if the first object is determined to be included in the target group, the session page for the target group is displayed.

In some embodiments, the third display unit 3030 is configured to: obtain the candidate terminal identifiers of the terminals of each candidate object in the target group; if it is determined that the terminal identifier of the terminal of the first object is consistent with one of the candidate terminal identifiers, then it is determined that the target group includes the first object.

In some embodiments, the third display unit 3030 is configured as follows:

In response to a trigger on a link tag, a query message is displayed, wherein the query message is used to ask the terminal of the first object whether to display the session page of the target group;

In response to an affirmative answer to the query message, the session page for the target group is displayed.

In some embodiments, the third display unit 3030 is configured as follows:

In response to a trigger on a link tag, an authorization request is sent to the second object;

In response to receiving an authorization response from the second object, the session page for the target group is displayed.

In some embodiments, the third display unit 3030 is configured as follows:

In response to a triggering of the link tag, if it is determined that the first object is not included in the target group, the authorization request is sent to the second object.

In some embodiments, the basic information of the target group includes at least one of the information set when the second object creates the target group and the information extracted from the target group by the application platform based on the basic information extraction rules.

In some embodiments, the target group includes multiple target subgroups, and the entry links are synthesized based on the sub-entry links created for each target subgroup by the second object;

The basic information of the target group includes the target subgroup name of each target subgroup. The target subgroup name is associated with the target subgroup when the second object creates the entry link. The target subgroup name has a link tag.

The third display unit 3030 is configured as follows:

In response to a link tag on the target subgroup name, display the target subgroup's session page.

In some embodiments, the third display unit 3030 is configured as follows:

The entry link for the target group is created in the following way:

Display the target group's session page to the second target;

In response to the link creation operation of the second object in the session page of the target group, obtain the target group name of the target group and the terminal identifier of the second object;

Generate a group string based on the target group name and terminal identifier;

If the group string is determined to satisfy the first condition, the group string is encoded into an entry link, and the entry link is displayed for the second object.

In some embodiments, the third display unit 3030 is configured as follows:

Obtain a predefined relationship lookup table, which indicates the correspondence between each candidate group and the candidate string;

Compare the group string with each candidate string;

If the group string is determined to be different from all candidate strings, then the group string satisfies the first condition.

In some embodiments, the target group includes multiple target subgroups;

The entry link for the target group is created in the following way:

A display module (not shown) is configured to display a link creation page in response to a link creation request from a second object;

The determination module (not shown) is configured to determine the subgroup links of each target subgroup based on the input operation of the second object in the link creation page;

A generation module (not shown) is configured to generate a group string based on multiple subgroup links and the terminal identifier of the second object;

An encoding module (not shown) is configured to encode the group string into an entry link and display the entry link for the second object if it is determined that the group string meets the first condition.

In some embodiments, determining the subgroup links for each target subgroup includes:

If it is determined that the second object entered the subgroup name of the target subgroup in the link creation page, then a subgroup string is generated based on the subgroup name, and the subgroup string is encoded into a subgroup link;

If it is determined that the second object entered a subgroup link of the target subgroup on the link creation page, then the subgroup link is subject to a second verification, and the subgroup link that passes the second verification is used to generate the group string.

In some embodiments, a second verification of subgroup links includes:

Perform format validation on subgroup links;

If the format validation is successful, a predefined relationship lookup table is obtained, which indicates the correspondence between each candidate group and the candidate string.

Parse the subgroup string of the target subgroup from the subgroup link;

Compare the subgroup string with each candidate string;

If the subgroup string is determined to be the same as a candidate string, then the second verification is considered successful.

In some embodiments, the link creation page has multiple group information addition windows and a group supplement control;

The module (not shown) is configured as follows:

Based on the triggering of the group supplement control by the second object, the supplement window is displayed on the link creation page;

Based on the input operations of the second object in multiple group information addition windows and supplementary windows, the subgroup links of each target subgroup are determined.

In some embodiments, the link creation page has multiple group information addition windows and a group deletion control;

The module (not shown) is configured as follows:

Based on the triggering of the group deletion control by the second object, one of the multiple group information addition windows is deleted;

Based on the input operations of the second object in the window that retains multiple group information, the subgroup links of each target subgroup are determined.

In some embodiments, the target group name is displayed in the following manner:

Based on a predefined regular expression, locate the entry link on the first page and extract the group string from the entry link;

If it is determined that the group string is associated with the target group name of the target group, the entry link will be displayed as the target group name with the link tag.

In some embodiments, the target group including the terminals of the first object is determined by the following:

Obtain the candidate terminal identifiers for each candidate terminal in the target group;

If the terminal identifier of the terminal of the first object is determined to match a candidate terminal identifier, then the target group is determined to include the terminal of the first object.

In some embodiments, the authorization response of the second object is generated in the following manner:

Obtain the terminal reputation and creation timestamp of the terminal of the first object;

The terminal score of the first object's terminal is determined based on terminal reputation and creation timestamp;

If the terminal score is greater than the predetermined score, an authorization response is generated.

Referring to Figure 31, which is a structural block diagram of a portion of a terminal implementing the group display method in an application according to an embodiment of this application, the terminal includes: a radio frequency (RF) circuit 3110, a memory 3115, an input unit 3130, a display unit 3140, a sensor 3150, an audio circuit 3160, a wireless fidelity (WiFi) module 3170, a processor 3180, and a power supply 3190, among other components. Those skilled in the art will understand that the terminal structure shown in Figure 31 does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

The RF circuit 3110 can be configured to receive and transmit signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with the processor 3180; in addition, it transmits uplink data designed to be sent to the base station.

The memory 3115 can be configured to store software programs and modules, and the processor 3180 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 3115.

The input unit 3130 can be configured to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the target terminal. Specifically, the input unit 3130 may include a touch panel 3131 and other input devices 3132.

Display unit 3140 can be configured to display input or provided information, as well as various menus of the target terminal. Display unit 3140 may include display panel 3141.

Audio circuitry 3160, speaker 3161, and microphone 3162 provide an audio interface.

In this embodiment, the processor 3180 included in the terminal can execute the group display method in the application of the previous embodiment.

The terminals in this application embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to data security, blockchain, data storage, and information technology.

Figure 32 is a structural block diagram of a portion of the server in an application implementing the group display method of this application. The server can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 3222 (e.g., one or more processors) and memory 3232, and one or more storage media 3230 (e.g., one or more mass storage devices) for storing application programs 3242 or data 3244. The memory 3232 and storage media 3230 may be temporary or persistent storage. The program stored in the storage media 3230 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the server. The CPU 3222 may be configured to communicate with the storage media 3230 and execute the series of instruction operations in the storage media 3230 on the server.

The server may also include one or more power supplies 3226, one or more wired or wireless network interfaces 3250, one or more input/output interfaces 3258, and/or one or more operating systems 3241, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

The central processing unit 3222 in the server can be configured to execute the group display method in the application of the present application.

This application also provides a computer-readable storage medium configured to store program code, which is configured to execute the group display method in the applications of the foregoing embodiments.

This application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the group display method in the application described above.

The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And/or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and/or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character "/" generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims (22)

A group display method in an application, applied to a terminal of a first object, the method comprising: The application displays a first page containing the target group name of the target group, the target group name having a link tag for an entry link of the target group, the entry link being created by a second object in the target group and associated with the target group name of the target group at the time of creation; In response to a dwell action triggered around the target group name, basic information about the target group is displayed; In response to a trigger on the link tag, the session page for the target group is displayed. According to the method of claim 1, the target group name is determined in the following manner: If the second object of the target group has enabled name display for the terminal of the first object when the entry link is created, then the link tag of the entry link is constructed as the name of the target group. According to the method of claim 1, the target group name is determined in the following manner: The group name specified by the second object for the terminal of the first object when creating the entry link is determined as the target group name corresponding to the terminal of the first object, wherein the second object specifies different group names for different object terminals when creating the entry link. According to the method of claim 1, the target group name of the first page is determined by the following method: The candidate group name that corresponds to the first object preference of the terminal of the first object among the multiple candidate group names is determined as the target group name, wherein the multiple candidate group names are associated with the entry link when the second object creates the entry link. The method of claim 1, wherein displaying the session page of the target group in response to a trigger on the link tag, comprises: In response to a trigger on the link tag, if it is determined that the first object is included in the target group, the session page of the target group is displayed. According to the method of claim 5, wherein determining that the target group includes the first object includes: Obtain the candidate terminal identifier of the terminal of each candidate object in the target group; If it is determined that the terminal identifier of the terminal of the first object matches one of the candidate terminal identifiers, then the target group is determined to include the first object. The method of claim 1, wherein displaying the session page of the target group in response to a trigger on the link tag, comprises: In response to a triggering of the link tag, an inquiry message is displayed, wherein the inquiry message is used to ask the terminal of the first object whether to display the session page of the target group; In response to an affirmative answer to the query message, the session page for the target group is displayed. The method of claim 1, wherein displaying the session page of the target group in response to a trigger on the link tag, comprises: In response to a triggering of the link tag, an authorization request is sent to the second object; In response to receiving the authorization response from the second object, the session page of the target group is displayed. The method of claim 8, wherein sending an authorization request to the second object in response to a triggering of the link tag includes: In response to a triggering of the link tag, if it is determined that the first object is not included in the target group, the authorization request is sent to the second object. According to the method of claim 1, the basic information of the target group includes at least one of the information set when the second object creates the target group and the information extracted from the target group by the application platform based on the basic information extraction rules. According to the method of claim 1, the target group includes multiple target subgroups, and the entry link is synthesized based on the sub-entry links created by the second object for each target subgroup; The basic information of the target group includes the target subgroup name of each target subgroup. The target subgroup name is associated with the target subgroup when the second object creates the entry link. The target subgroup name carries the link tag. The step of displaying the session page of the target group in response to the triggering of the link tag includes: In response to a triggering of the link tag on the target subgroup name, the session page of the target subgroup is displayed. According to the method of claim 1, the entry link of the target group is created in the following manner: Display the target group's session page to the second object; In response to the link creation operation of the second object in the session page of the target group, the target group name of the target group and the terminal identifier of the second object are obtained; Generate a group string based on the target group name and the terminal identifier; If the group string is determined to satisfy the first condition, then the group string is encoded into the entry link. According to the method of claim 12, wherein determining that the group string satisfies the first condition includes: Obtain a predetermined relationship lookup table, wherein the predetermined relationship lookup table is used to indicate the correspondence between each candidate group and the candidate string; The group string is compared with each of the candidate strings; If it is determined that the group string is different from each of the candidate strings, then the group string is determined to satisfy the first condition. According to the method of claim 12, after generating the group string based on the target group name and the terminal identifier, the method further includes: If it is determined that at least one of the candidate strings exists in the group string, then it is determined that the group string does not satisfy the first condition; A random string is regenerated based on the target group name and the terminal identifier of the second object. If the generated random string is unique, it is encoded as the group string of the target group to obtain the entry link. According to the method of claim 1, the target group includes a plurality of target subgroups; The entry link for the target group is created in the following way: In response to the link creation request from the second object, the link creation page is displayed; Based on the input operation of the second object on the link creation page, the subgroup links of each of the target subgroups are determined; A group string is generated based on the multiple subgroup links and the terminal identifier of the second object; If the group string is determined to satisfy the first condition, then the group string is encoded into the entry link. According to the method of claim 15, wherein determining the subgroup links of each of the target subgroups includes: If it is determined that the second object entered the subgroup name of the target subgroup in the link creation page, then a subgroup string is generated based on the subgroup name, and the subgroup string is encoded into the subgroup link; If it is determined that the second object entered a subgroup link of the target subgroup on the link creation page, then the subgroup link is subjected to a second verification, and the subgroup link that passes the second verification is used to generate the group string. According to the method of claim 16, the second verification of the subgroup links includes: Perform format validation on the subgroup links; If the format verification is successful, a predetermined relationship lookup table is obtained, wherein the predetermined relationship lookup table is used to indicate the correspondence between each candidate group and the candidate string; Parse the subgroup string of the target subgroup from the subgroup link; The subgroup string is compared with each of the candidate strings; If it is determined that the subgroup string is the same as one of the candidate strings, then the second verification is deemed successful. According to the method of claim 1, the target group name is displayed in the following manner: Based on a predefined regular expression, the entry link is located on the first page, and the group string in the entry link is extracted; If it is determined that the group string is associated with the target group name of the target group, then the target group name with the link tag is displayed. A group display device in an application, applied to a first object's terminal, the device comprising: The first display module is configured to display a first page in the application, the first page containing the target group name of the target group, the target group name having a link tag for an entry link of the target group, the entry link being created by a second object in the target group and associated with the target group name of the target group at the time of creation; The second display module is configured to display basic information about the target group in response to a dwell operation triggered around the target group name; The third display module is configured to display the session page of the target group in response to a trigger on the link tag. An electronic device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the group display method in an application according to any one of claims 1 to 18. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the group display method in an application according to any one of claims 1 to 18. A computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform a group display method in an application according to any one of claims 1 to 18.