Marriage and love social platform relationship state management method and device and computer equipment

Abstract

This invention belongs to the field of computer network communication technology and relates to a method, device, and computer equipment for managing relationship status on a dating and social networking platform. The method includes: establishing a unified status coding system; implementing mutual exclusion lock management for user status in a matchmaking mode; constructing a forced entry channel for matchmaker operations; setting a unified entry function for relationship status; defining a formula for retrieving the scope of historical matchmakers; constructing a hierarchical visibility control matrix, returning status information of different granularities based on the relationship type between the viewer and the target user—including romantic partners, historical matchmakers, matchmakers, the public, and platform administrators—and implementing a unilateral breakup atomic operation, allowing users to end their romantic relationship without the other party's consent, while setting a 24-hour cooling-off period after the breakup. This eliminates the data disconnect between matchmakers and the platform, achieves status management and mutual exclusion control, protects the right to know of historical matchmakers, enables hierarchical information visibility, provides a traceable and fraud-proof system foundation, and protects user autonomy.

Description

Technical Field

[0001] This invention relates to the field of computer network communication technology, and in particular to a method, apparatus, and computer equipment for managing relationship status on a dating and social networking platform. Background Technology

[0002] With the rapid development of internet technology, online dating and social networking platforms have become an important channel for people to find romantic partners. Existing dating and social networking platforms generally fall into two categories: one is a matchmaker-led matchmaking model, where platform matchmakers connect users; the other is a user-initiated dating model, where users browse and initiate interactions independently.

[0003] However, existing technologies have the following technical problems in relational state management: First, there is a serious disconnect between matchmaker operations and platform data. In the current matchmaking model, matchmakers often rely on verbal information from users to determine their relationship status, then record the results offline or retroactively in the system. This method leads to a time lag and inconsistency between the user status recorded in the platform system and the actual situation. Matchmakers may continue to act as matchmakers for users who are already in a relationship, causing user inconvenience and damaging the platform's reputation.

[0004] Second, status management is rudimentary and lacks mutual exclusion control. Existing platforms generally use a binary "single / non-single" status management approach, which cannot precisely express intermediate states such as "being matched," "dating," and "being in a relationship." In the matchmaking mode, users may maintain matchmaking relationships with multiple people simultaneously, creating a technical vulnerability of "playing multiple people at once." In the dating mode, the process of users getting to know each other and establishing a romantic relationship lacks a clear status transition path.

[0005] Third, users' right to know is severely lacking. When a user's ex-partner or current partner enters into a romantic relationship, the existing platform does not proactively inform the user, which may lead to the user continuing to maintain contact with the person they are already in a relationship with without their knowledge, objectively creating opportunities for emotional fraud.

[0006] Fourth, information visibility lacks tiered control. Existing platforms display the same level of status information to all users, which fails to protect the privacy of users in relationships and also fails to meet the needs of matchmakers and administrators for complete status information.

[0007] Fifth, the relationship termination mechanism is inadequate. Existing platforms typically require the consent of both parties to end a romantic relationship. If one party is unwilling to end it, the other party cannot extricate themselves, thus restricting the user's autonomy. Summary of the Invention

[0008] To address the aforementioned technical problems, this invention provides a method for managing relationship status on a dating and matchmaking platform, employing the following technical solution, including the following steps: S1. Establish a unified state coding system, assign each user in the platform a discrete state code that includes at least the initial state, matchmaking / dating, dating, and romance, and configure the corresponding state transition path according to the matchmaking or dating mode selected by the user, and force verification that the user's state is the initial state when each relationship establishment operation is initiated. S2, in the matchmaking mode, implements mutual exclusion lock management on user status to ensure that any user can be in a non-initial state with at most one other user at the same time, and sets a 48-hour automatic confirmation window for the matchmaking status, and completes the status transfer from matchmaking to dating through a two-way confirmation mechanism. S3 establishes a forced entry channel for matchmaker operations into the system. All matchmaker matchmaking, confirmation, and abandonment operations are called through a dedicated API interface. Before executing a matchmaking operation, the target user's status is queried and verified in real time. If the status is not initial, the operation is rejected. All matchmaker operations are logged and audited throughout the entire process. S4, set a unified entry function for the dating status. When both parties are in a dating status in the matchmaking mode or both parties are in a dating status in the friendship mode, the status of both parties is updated to dating synchronously through this entry function in a transactional consistency manner, and the process of informing the historical matchmaker is triggered asynchronously after the status is updated. S5 defines a formula for the search scope of historical matchmakers. Based on this formula, the system automatically retrieves the set of historical matchmakers for users who are in a romantic relationship. It then sends a de-identified notification to each historical matchmaker in the set via a message queue and uses a unique index to prevent duplicate notifications. S6 constructs a hierarchical visibility control matrix, returning status information of different granularities based on the relationship type between the viewer and the target user—including romantic partners, historical matchmakers, matchmakers, the public, and platform administrators—and implements unilateral breakup atomic operations, allowing users to end romantic relationships without the other party's consent, while setting a 24-hour cooling-off period after the breakup.

[0009] Preferably, the specific method for establishing a unified state coding system in step S1 is as follows: Create a status field user_status for each user in the platform's backend relational database. Store the status using an enumeration type or a small integer type. The status codes are defined as: 0 - Initial status, 1 - In the process of matchmaking / making friends, 2 - In the process of dating, 3 - In a relationship. Create a state change history table, state_change_log, to record the user ID, original state, target state, operator type, and change time for each state change, thus achieving traceability of all state changes; The mode-specific state mapping is implemented by creating a state transition configuration table, state_transition_config. This table contains at least the fields of mode type, original state, target state, and whether the transition is allowed. At the code level, a mode-aware state transition verification function is implemented. This function queries the state transition configuration table based on the current user's mode type to determine whether the transition from the original state to the target state is legal. The initial state mandatory verification is implemented by calling the state pre-check interface before each matchmaking, dating, or relationship request. This interface queries whether the user's current state code is equal to 0. If it is not 0, the operation is rejected and the error code ERR_STATE_NOT_INITIAL is returned. At the same time, an optimistic locking update statement UPDATE user_relationship_state SETstate_code = 1, partner_user_id = partner identifier WHERE user_id = user identifier AND state_code = 0 is used to avoid concurrent state pollution.

[0010] Preferably, the specific method for managing the mutex lock state in the matchmaking mode in step S2 is as follows: Before each state change, a mutual exclusion check function is executed. This function first determines whether the current user's mode type is a matchmaking mode and whether the target state is not the initial state. If so, it checks whether the current user has a non-initial state record with a non-empty partner user identifier. If it does, it throws an exception and refuses the state change. At the database level, a partially unique index is created using the formula `CREATE UNIQUE INDEX idx_user_nonzero_state ON user_relationship_state (user_id) WHERE state_code != 0` to ensure that only one record of a user exists in a non-initial state. The 48-hour confirmation window and automatic reset are implemented in the following ways: Once a matchmaker successfully connects two people, the system creates a matchmaking record (matchmaking_record). This record contains an expiration time field (expire_time = NOW() + INTERVAL 48 HOUR). Every 10 minutes, a scheduled task scans for records that are pending confirmation and have an expiration time less than the current time. For each expired record, the system resets the status of both users to 0, deletes or marks the matchmaking record as expired, and sends an expiration notification to both users. The two-way confirmation mechanism is implemented by adding a first-party agreement field and a second-party agreement field to the matchmaking record table. When either party's user clicks "agree to interact" through the client, the confirmation interface is called to update the corresponding party's agreement field. After each update, the system checks whether both parties' agreement fields are true. If so, the system uses a transaction to synchronize the status of both users to "interacting" and points the user identifiers of the cooperating parties to each other. If either party refuses, the status of both users is reset to 0.

[0011] Preferably, the specific method for forcibly entering the matchmaker operation into the system in step S3 is as follows: Develop a dedicated API endpoint for matchmakers. All requests must carry a matchmaker identity token generated based on the JWT or OAuth2 protocol. The API endpoint should include at least a matchmaking interface, a status query interface, and a confirmation interface. After receiving the request, the backend server first verifies the matchmaker's identity and permissions in the token. If the verification is successful, the operation log is recorded in the matchmaker_operation_log table. This table contains at least the matchmaker's identifier, operation type, set of user identifiers involved, operation result, and timestamp fields. The real-time status query and rejection mechanism is implemented by providing a status query interface. Before making a match, the matchmaker calls this interface and passes in the target user identifier. The backend queries the user's real-time status code and returns a boolean value indicating whether the match is possible. When the matchmaker attempts to make a match, the system automatically calls this interface to verify both parties. If either party returns a false boolean value indicating whether the match is possible, the matchmaking operation is rejected, and the atomicity of the query and subsequent update is guaranteed using the database row lock statement SELECT ... FOR UPDATE. The end-to-end logging and auditing is achieved by creating a matchmaker audit log table, matchmaker_audit_log. This table records at least the matchmaker identifier, target user identifier, operation action, request parameters, response result, IP address, user agent, and creation time. A log archiving policy is set to retain logs for at least 2 years, and a read-only database instance is used for storage to prevent log tampering.

[0012] Preferably, the specific implementation of the unified entry function for the relationship status in step S4 is as follows: Implement a unified entry function named enter_love_status, which takes three parameters: first user identifier, second user identifier, and source mode. Inside the function, the state validity is first checked based on the source pattern: if the source pattern is a matchmaking pattern, then the current state codes of the first user and the second user are both equal to 2, i.e., they are in a relationship. If the source mode is the dating mode, then check whether the current status codes of the first user and the second user are both equal to 1, i.e., the dating status. If any validation fails, a value error exception is thrown; if the validation passes, the following operations are performed sequentially within the database transaction: update the status code of the first user to 3 (i.e., in a relationship) and set the partner user identifier to the second user; update the status code of the second user to 3 (i.e., in a relationship) and set the partner user identifier to the first user; insert a relationship record into the love_record table to record the first user, the second user, and the start time. After the transaction is committed, the historical notification trigger function is called asynchronously, and a relationship confirmation notification is pushed to the first user and the second user respectively. The transaction consistency guarantee is implemented by using the transaction context manager of the database engine. If any database update statement executed within the transaction block fails, all operations are automatically rolled back to ensure the atomicity of the state updates for both parties.

[0013] Preferably, the meaning of the formula for the historical matchmaker retrieval range in step S5 is as follows: H(u) = {p ∣ ∃ r ∈ R : (r.user_id_a = u ∨ r.user_id_b = u) ∧r.contact_id = p ∧ r.meet_time≥(T now - 6 months) ∧ p ≠ v} In: where H(u) represents the set of historical matchmakers for user u; p represents the historical matchmaking object; R represents the set of all matchmaking records in the platform; r represents a matchmaking record; r.user_id_a represents the identifier of the first-party user in the matchmaking record; r.user_id_b represents the identifier of the second-party user in the matchmaking record; r.contact_id represents the identifier of the other-party user paired with user u in the matchmaking record; r.meet_time represents the time when the matchmaking relationship was established between the two parties in the matchmaking record; T now This represents the current system time; 6months represents the preset 6-month time window; v represents user u's current romantic partner; this formula is used to filter out matchmaking partners from all matchmaking records who simultaneously meet four conditions: there is a matchmaking record with user u, the matchmaking time is within 6 months of the present, and the partner is not user u's current romantic partner, ultimately forming a set of historical matchmakers for whom notifications need to be sent.

[0014] Preferably, the asynchronous batch notification mechanism and the anti-duplicate notification method in step S5 are implemented as follows: In the historical notification trigger function, the historical matchmaker identification list is first obtained by querying using structured query language according to the historical matchmaker retrieval range formula. The query statement is: SELECT DISTINCT CASE WHEN user_id_a = User ID THEN user_id_b ELSE user_id_a END AS contact_id FROM matchmaking_record WHERE (user_id_a = User ID OR user_id_b = User ID) AND meet_time >= DATE_SUB(NOW(), INTERVAL 6 MONTH) AND (CASE WHEN user_id_a = User ID THEN user_id_b ELSE user_id_a END) != Romantic Partner Identifier; Iterate through the list of historical matchmakers, generate a message body for each historical matchmaker that includes notification type, recipient user identifier, notification content, and whether to display the romantic partner flag, serialize the message body into a JSON string, and publish it to the specified topic or queue of the message queue. Independent consumer processes pull messages from the message queue and send notifications to clients in batches by calling push services, including APNS, FCM, and in-site messaging. The method of preventing duplicate notifications is achieved by creating a historical notification log table, which contains fields for user identifier, notified user identifier, relationship record identifier, and notification time. A unique index is created on the combined field of user identifier, notified user identifier, and relationship record identifier. When inserting a notification record, the INSERT IGNORE statement is used. If there is a unique index conflict, the insertion is ignored, thereby avoiding duplicate notifications. Simultaneously, frequency control logic is set: before generating a notification, the historical notification record table is queried to determine whether the same historical intermediary has been notified to the same user within 6 months; if so, the current notification is skipped.

[0015] Preferably, the specific implementation of the hierarchical visibility control matrix in step S6 is as follows: Implement a visibility function named get_visible_state. This function takes two parameters: the viewer identifier and the target user identifier. Inside the function, the viewer's role type is first determined. Role types include romantic partner, historical matchmaker, matchmaker, public, and platform administrator. The function returns different visibility information based on different role types: If the viewer is the romantic partner and the viewer ID is equal to the target user's collaborator ID, then information containing the target user's complete status code and the collaborator ID is returned. If the viewer's role is the historical matchmaker, the returned status description is "in a relationship" and is desensitized information that does not contain any information about the romantic partner. If the viewer's role is matchmaker, the system returns information containing the target user's complete status code and the partner user's identifier. If the viewer's role is public, then further query the target user's privacy settings mode. If it is public mode and the target user's status code is "in a relationship", then return the status description as "in a relationship". Otherwise, return empty status information. If the viewer is a platform administrator, the system will return information including the target user's complete status code, the partner user's identifier, and the complete status change history. The visibility function is called at the application interface layer and dynamically serializes the returned JSON object according to the requester's identity, thereby achieving hierarchical control where different roles see different levels of status information.

[0016] To address the aforementioned technical problems, the present invention also provides a relationship status management device for a dating and social networking platform, which employs the following technical solution, including: The status establishment module is used to establish a unified status coding system, assigning each user in the platform a discrete status code that includes at least the initial status, matchmaking / dating, dating, and romance. Based on the matchmaking or dating mode selected by the user, the module configures the corresponding status transition path and enforces verification that the user's status is the initial status when each relationship establishment operation is initiated. The mutual exclusion lock management module is used to implement mutual exclusion lock management on user status in the matchmaking mode, ensuring that any user can be in a non-initial state with at most one other user at the same time, and setting a 48-hour automatic confirmation window for the matchmaking status, and completing the status transfer from matchmaking to dating through a two-way confirmation mechanism. The channel construction module is used to build a channel for forced entry of matchmaker operations into the system. All matchmaker matchmaking, confirmation, and abandonment operations are called through a dedicated API interface. Before executing a matchmaking operation, the target user's status is queried and verified in real time. If the status is not initial, the operation is rejected. All matchmaker operations are logged and audited in the entire chain. The entry setting module is used to set a unified entry function for the dating status. When both parties are in a dating status in the matchmaking mode or both parties are in a dating status in the friendship mode, the entry function will update the status of both parties to "dating" in a transactional consistency manner, and asynchronously trigger the notification process of the historical matchmaker after the status update. The retrieval definition module is used to define the formula for the retrieval scope of historical matchmakers. Based on this formula, it automatically retrieves the set of historical matchmakers of users who have entered a romantic relationship. It sends de-identified notifications to each historical matchmaker in the set through a message queue and uses a unique index to prevent duplicate notifications. The matrix module is used to construct a hierarchical visibility control matrix. Based on the relationship type between the viewer and the target user—including romantic partners, past matchmakers, matchmakers, the public, and platform administrators—it returns status information at different granularities and enables unilateral breakup atomic operations, allowing users to end romantic relationships without the other party's consent, while also setting a 24-hour cooling-off period after the breakup.

[0017] To address the aforementioned technical problems, the present invention also provides a computer device that employs the technical solution described below, comprising a memory and a processor. The memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the relationship status management method for the aforementioned online dating platform.

[0018] Compared with the prior art, the present invention has the following main advantages: First, it eliminates the data disconnect between matchmakers and the platform. By forcing matchmaker operations into the system channel and implementing real-time status verification, all matchmaker operations must be completed through the system API. This ensures that the user status within the platform always matches the actual relationship status, fundamentally solving the data inconsistency problem caused by manual judgment and offline operations.

[0019] Second, it enables refined state management and mutual exclusion control. By using a unified state coding system, the state is expanded from a binary search to four discrete states, supporting intermediate state management. In the matchmaking mode, mutual exclusion locks and unique indexes ensure that a user can only maintain a non-initial state with one person at a time, eliminating the technical vulnerability of "having multiple partners simultaneously."

[0020] Third, the right of historical matchmakers to be informed is guaranteed. A historical matchmaker retrieval formula accurately identifies the recipients who need to be notified, and batch notifications are achieved through an asynchronous message queue. Notification content is anonymized to inform the public while protecting the privacy of current contacts, and a unique indexing mechanism prevents duplicate notifications.

[0021] Fourth, it enables layered information visibility. Through a visibility permission matrix, different roles can see status information at different granularities, balancing the needs of transparency and privacy protection.

[0022] Fifth, it provides a traceable and fraud-proof system foundation. End-to-end log auditing, state change history records, and tamper-proof read-only storage together constitute a complete chain of evidence, providing technical support for dispute arbitration and fraud prevention analysis.

[0023] Sixth, protect user autonomy. The unilateral breakup mechanism allows users to end the relationship without the other party's consent, and a 24-hour cooling-off period prevents emotionally driven repeated actions. Attached Figure Description

[0024] To more clearly illustrate the solutions in this invention, the accompanying drawings used in the description of the embodiments of this invention will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 This is a flowchart of an embodiment of the relationship status management method for the dating social platform of the present invention; Figure 2 This is a schematic diagram of the structure of an embodiment of the relationship status management device for the dating social platform of the present invention; Figure 3 This is a schematic diagram of the structure of an embodiment of the computer device of the present invention. Detailed Implementation

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein in the specification is for the purpose of describing particular embodiments only and is not intended to limit the invention; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings are used to distinguish different objects and not to describe a particular order.

[0027] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0029] It should be noted that the relationship status management method of the dating and social networking platform provided in this embodiment of the invention is generally executed by a server / terminal device, and correspondingly, the relationship status management device of the dating and social networking platform is generally set in the server / terminal device.

[0030] It should be understood that the number of terminal devices, networks, and servers is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be used. Example

[0031] Please refer to Figure 1 The flowchart illustrates an embodiment of the relationship status management method for a dating social platform according to the present invention. The relationship status management method for the dating social platform includes the following steps: The purpose of step S1 is to establish a semantically unified, computable, and scalable state expression system for the entire online dating platform, and to support different flow rules for matchmaking and friendship modes under the same state encoding. This step forms the data foundation for all subsequent management actions.

[0032] In practice, step S1 further includes the following steps: S11 defines a unified state coding system.

[0033] A status field `user_status` is created for each user in the platform's backend relational database, stored using an enumeration type or a small integer type. The status codes are defined as follows: 0 - Initial state (no relationship established with anyone), 1 - In the process of matchmaking / dating (indicates a confirmed match in blind date mode, and a parallel relationship in dating mode), 2 - In the process of dating (only used in blind date mode, indicating both parties have agreed to date), 3 - In a relationship (finalized romantic relationship, unified in both modes). A status change history table `state_change_log` is also created to record the user ID, original state, target state, operator type, and change time for each status change, ensuring traceability of all status changes.

[0034] S12, perform mode-specific state mapping.

[0035] This is achieved by creating a state transition configuration table `state_transition_config`, which at least contains fields for mode type, original state, target state, and whether a transition is allowed. A mode-aware state transition validation function is implemented at the code level. This function queries the state transition configuration table based on the current user's mode type to determine whether the transition from the original state to the target state is legal. For the matchmaking mode, the legal transition paths are 0→1 (matchmaking), 1→2 (agree to date), and 2→3 (dating); for the dating mode, the legal transition paths are 0→1 (dating) and 1→3 (directly dating).

[0036] S13: Perform a mandatory check on the initial state.

[0037] Before each matchmaking, dating, or relationship request, a status pre-check interface is called. This interface checks if the user's current status code is equal to 0. If it is not 0, the operation is rejected and the error code ERR_STATE_NOT_INITIAL is returned. Simultaneously, an optimistic locking update statement is used: UPDATE user_relationship_state SET state_code = 1, partner_user_id = partner identifier WHERE user_id = user identifier AND state_code = 0. If the number of rows affected by the update is 0, it means the status has been changed by other operations, requiring a rollback and retry or an error report, thus avoiding concurrent state pollution.

[0038] S2 controls the mutual exclusion and flow of the matchmaking mode status.

[0039] The purpose of step S2 is to implement one-on-one exclusive relationship management in the matchmaking mode, prohibit users from being in a matchmaking or dating state with multiple people at the same time, and eliminate the possibility of one-to-many relationships.

[0040] In practice, step S2 further includes the following steps: S21, manage the state of the mutex lock in the matchmaking mode.

[0041] Before each state change, a mutual exclusion check function is executed. This function first determines whether the current user's mode type is "dating" and whether the target state is a non-initial state. If so, it checks whether the current user has a non-initial state record with a non-nullable partner user identifier. If such a record exists, an exception is thrown and the state change is rejected. At the database level, a partially unique index is created: `CREATE UNIQUE INDEX idx_user_nonzero_state ON user_relationship_state (user_id) WHERE state_code != 0` to ensure that a user can only have one non-initial state record.

[0042] S22, 48-hour confirmation window and automatic reset during the connection process.

[0043] Once a matchmaker successfully connects two people, the system creates a matchmaking record (matchmaking_record) containing an expiration time field: expire_time = NOW() + INTERVAL 48 HOUR. A scheduled task scans for records with a pending status and an expiration time less than the current time every 10 minutes. For each expired record, the status of both users is reset to 0, the record is deleted or marked as expired, and an expiration notification is sent to both users.

[0044] S23, set up a two-way confirmation mechanism for agreeing / rejecting.

[0045] This is achieved by adding a "First Party's Agreement" field and a "Second Party's Agreement" field to the matchmaking record table. When either user clicks "Agree to Engage" through the client, the confirmation interface is called to update the corresponding party's agreement field. After each update, the system checks whether both parties' agreement fields are true. If so, a transaction is used to synchronize the status of both users to "Entering Engagement" and the user identifiers of the cooperating parties are set to point to each other. If either party refuses, the status of both users is reset to 0.

[0046] S3: Force matchmaker operations into the system and perform real-time status verification.

[0047] The purpose of step S3 is to completely eliminate the traditional flaw of matchmakers judging the status based on the user's verbal statement, and to achieve forced synchronization between the matchmaker's operation and the platform data.

[0048] In practice, step S3 further includes the following steps: S31, forces the call to the matchmaker operation interface.

[0049] Develop a dedicated API endpoint for matchmakers. All requests must carry a matchmaker identity token generated based on the JWT or OAuth2 protocol. The API endpoint should include at least a matchmaking interface, a status query interface, and a confirmation interface. Upon receiving a request, the backend server first verifies the matchmaker's identity and permissions in the token. If the verification is successful, the operation log is recorded in the `matchmaker_operation_log` table. This table should contain at least the matchmaker identifier, operation type, set of user identifiers involved, operation result, and timestamp fields.

[0050] S32 performs real-time status queries and sets up a rejection mechanism.

[0051] A status query interface is provided. Before matchmaking, the matchmaker calls this interface, passing in the target user's identifier. The backend queries the user's real-time status code and returns a boolean value indicating whether matchmaking is possible. When the matchmaker attempts to match, the system automatically calls this interface to verify both parties. If either party returns a false boolean value indicating matchmaking is possible, the matchmaking operation is rejected. The database row-level locking statement `SELECT ... FOR UPDATE` ensures the atomicity of the query and subsequent updates.

[0052] S33 records the entire process log of the matchmaker's operations for auditing.

[0053] Create a matchmaker audit log table, `matchmaker_audit_log`, which should record at least the matchmaker identifier, target user identifier, action performed, request parameters, response result, IP address, user agent, and creation time. Configure a log archiving policy to retain logs for at least two years, using a read-only database instance to prevent log tampering.

[0054] S4, triggers a unified entry point and history notification for the relationship status.

[0055] The purpose of step S4 is to unify the dating and matchmaking modes in terms of the status of being in a relationship, and to automatically trigger the notification process from the historical matchmaker.

[0056] In practice, step S4 further includes the following steps: S41, set the unified entry function for the relationship status.

[0057] Implement a unified entry function named `enter_love_status`, which accepts three parameters: a first user identifier, a second user identifier, and a source pattern. Internally, the function first performs a status validity check based on the source pattern: if the source pattern is a dating pattern, it checks if both parties' current status codes are equal to 2 (dating); if the source pattern is a friendship pattern, it checks if both parties' current status codes are equal to 1 (friends). If the check passes, within a database transaction, both parties' statuses are synchronously updated to 3 (in a relationship), and they are mutually pointed to each other's user identifiers, and a relationship record is inserted. After the transaction is committed, the historical notification trigger function is asynchronously called, and a notification is pushed to both parties.

[0058] S42 ensures transaction consistency during state changes in a romantic relationship.

[0059] Using the database engine's transaction context manager, all operations are automatically rolled back if any database update statement executed within a transaction block fails, ensuring the atomicity of state updates for both parties.

[0060] S5 defines the search scope for historical matchmakers, and automatically notifies historical matchmakers and provides duplicate notifications.

[0061] The purpose of step S5 is to protect the right of past matchmakers to know and prevent users from suddenly entering into romantic relationships without informing their past partners.

[0062] In practice, step S5 further includes the following steps: S51: Define the scope of historical matchmakers search.

[0063] The retrieval formula is defined as follows: H(u) = {p | r ∈ R : (r.user_id_a = u ∨ r.user_id_b = u) ∧ r.contact_id = p ∧ r.meet_time≥(T now- 6 months) ∧ p ≠ v} In: where H(u) represents the set of historical matchmakers for user u; p represents the historical matchmaking object; R represents the set of all matchmaking records in the platform; r represents a matchmaking record; r.user_id_a represents the identifier of the first-party user in the matchmaking record; r.user_id_b represents the identifier of the second-party user in the matchmaking record; r.contact_id represents the identifier of the other-party user paired with user u in the matchmaking record; r.meet_time represents the time when the matchmaking relationship was established between the two parties in the matchmaking record; T now This represents the current system time; 6 months represents the preset 6-month time window; v represents user u's current romantic partner; this formula is used to filter out matchmaking partners from all matchmaking records who simultaneously meet four conditions: there is a matchmaking record with user u, the matchmaking time is within 6 months of the present, and the partner is not user u's current romantic partner, ultimately forming a set of historical matchmakers for whom notifications need to be sent.

[0064] S52, set up an asynchronous batch notification mechanism.

[0065] In the historical notification trigger function, a list of historical matchmakers is first retrieved using a structured query language based on the historical matchmaker retrieval range formula. This list is then iterated through, and a message body is generated for each historical matchmaker, containing the notification type, recipient user ID, notification content, and whether to display a romantic partner flag. The message body is then serialized into a JSON string and published to a message queue. A separate consumer process pulls messages from the message queue and batch-calls the push service to send notifications to clients.

[0066] S53, anonymize the notification content and do not disclose the recipients.

[0067] The notification template is fixed as "Your previously acquainted {username} has recently established a romantic relationship," and does not include the name of the romantic partner, the partner's ID, or any information that could be used to infer their identity.

[0068] S54 performs anti-duplicate notification and frequency control.

[0069] This is achieved by creating a historical notification log table, `historical_notification_log`, which has a unique index on a combined field of user ID, notified user ID, and relationship record ID. When inserting a notification record, the `INSERT IGNORE` statement is used; if a unique index conflict occurs, the insertion is ignored, thus avoiding duplicate notifications. Simultaneously, frequency control logic is implemented: before generating a notification, the table is queried to determine if the same historical matchmaker has already notified the same user within the past six months; if so, the current notification is skipped.

[0070] S6 implements layered visibility control and sets up a unilateral breakup mechanism.

[0071] The purpose of step S6 is to enable different roles to see status information at different granularities and to give users the right to unilaterally end a romantic relationship.

[0072] In its specific implementation, S6 further includes the following steps: S61, Set the hierarchical visibility permission matrix.

[0073] Implement a visibility function named `get_visible_state` that returns different information based on the viewer's role: if the viewer is a romantic partner and the current collaborator, return the complete status code and collaborator identifier; if the viewer is a past matchmaker, return a de-identified "in a relationship" status; if the viewer is a matchmaker, return the complete status code and collaborator identifier; if the viewer is a member of the public, return limited information based on privacy settings; if the viewer is a platform administrator, return the complete status, collaborator identifier, and history records.

[0074] S62 performs a unilateral break-off atomic operation.

[0075] Implement the breakup interface function break_up, which updates the status of the user initiating the breakup to 0 and clears the partner identifier within the transaction, updates the relationship record end time, pushes the breakup notification to the partner, and marks the broken-up flag in the partner's relationship status table.

[0076] S63, clears post-breakup status remnants and notifications.

[0077] A 24-hour cooling-off period is set, preventing either party from initiating romantic relationships or matchmaking requests with the other within 24 hours of the breakup. A scheduled task clears breakup markers older than 24 hours. Optionally, the reasons for the breakup are collected and recorded in a breakup reason log table for fraud prevention analysis.

[0078] This invention can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0079] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0080] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, 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 flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0081] Example 2 Further reference Figure 2 As a response to the above Figure 1 The present invention provides an embodiment of a relationship status management device for a dating and social networking platform, which is implemented in accordance with the method shown. Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0082] like Figure 2As shown, the relationship status management device 70 of the dating and social networking platform described in this embodiment includes: a status establishment module 71, a mutex lock management module 72, a channel construction module 73, an entry setting module 74, a retrieval definition module 75, and a matrix module 76. Wherein: The state establishment module 71 is used to establish a unified state coding system, assign each user in the platform a discrete state code that includes at least the initial state, matchmaking / friendship, dating, and romance, and configure the corresponding state transition path according to the matchmaking mode or friendship mode selected by the user, and forcibly verify whether the user's state is the initial state when each relationship establishment operation is initiated. The mutual exclusion lock management module 72 is used to implement mutual exclusion lock management on user status in the matchmaking mode, ensuring that any user can be in a non-initial state with at most another user at the same time, and setting a 48-hour automatic confirmation window for the matchmaking status, and completing the state transfer from matchmaking to dating through a two-way confirmation mechanism. The channel construction module 73 is used to construct a channel for forced entry of matchmaker operations into the system. All matchmaker matchmaking, confirmation, and abandonment operations are called through a dedicated API interface. Before executing a matchmaking operation, the target user's status is queried and verified in real time. If the status is not initial, the operation is rejected. All matchmaker operations are logged and audited in the entire chain. The entry setting module 74 is used to set a unified entry function for the dating status. When both parties are in a dating status in the matchmaking mode or both parties are in a dating status in the friendship mode, the entry function will update the status of both parties to dating in a transactional consistency manner, and asynchronously trigger the notification process of the historical matchmaker after the status update. The retrieval definition module 75 is used to define the formula for the retrieval range of historical matchmakers. Based on the formula, it automatically retrieves the set of historical matchmakers of users who have entered a romantic relationship. It sends a de-identified notification to each historical matchmaker in the set through a message queue and uses a unique index to prevent duplicate notifications. Matrix module 76 is used to construct a hierarchical visibility control matrix. Based on the relationship type between the viewer and the target user—including romantic partners, historical matchmakers, matchmakers, the public, and platform administrators—it returns status information at different granularities and implements unilateral breakup atomic operations, allowing users to end romantic relationships without the other party's consent, while also setting a 24-hour cooling-off period after the breakup.

[0083] Example 3 To address the aforementioned technical problems, embodiments of the present invention also provide a computer device. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a basic structural block diagram of the computer device in this embodiment.

[0084] The aforementioned computer device 8 includes a memory 81, a processor 82, and a network interface 83 that are interconnected via a system bus. It should be noted that only the computer device 8 with components 81, 82, and 83 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0085] The aforementioned computer devices can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. These devices can facilitate human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0086] The aforementioned memory 81 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the aforementioned memory 81 may be an internal storage unit of the aforementioned computer device 8, such as the hard disk or memory of the computer device 8. In other embodiments, the aforementioned memory 81 may also be an external storage device of the aforementioned computer device 8, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 8. Of course, the aforementioned memory 81 may also include both the internal storage unit and its external storage device of the aforementioned computer device 8. In this embodiment, the aforementioned memory 81 is typically used to store the operating system and various application software installed on the aforementioned computer device 8, such as computer-readable instructions for relationship status management methods of dating and social networking platforms. In addition, the aforementioned memory 81 can also be used to temporarily store various types of data that have been output or will be output.

[0087] In some embodiments, the processor 82 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 82 is typically used to control the overall operation of the computer device 8. In this embodiment, the processor 82 is used to execute computer-readable instructions stored in the memory 81 or to process data, such as executing computer-readable instructions for the relationship status management method of the aforementioned online dating platform.

[0088] The network interface 83 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 8 and other electronic devices.

[0089] Example 4 The present invention also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the relationship status management method of the dating social platform described above.

[0090] The beneficial effects of implementing the above embodiments are as follows: First, it eliminates the data disconnect between matchmakers and the platform. By forcing matchmaker operations into the system channel and implementing real-time status verification, all matchmaker operations must be completed through the system API. This ensures that the user status within the platform always matches the actual relationship status, fundamentally solving the data inconsistency problem caused by manual judgment and offline operations.

[0091] Second, it enables refined state management and mutual exclusion control. By using a unified state coding system, the state is expanded from a binary search to four discrete states, supporting intermediate state management. In the matchmaking mode, mutual exclusion locks and unique indexes ensure that a user can only maintain a non-initial state with one person at a time, eliminating the technical vulnerability of "having multiple partners simultaneously."

[0092] Third, the right of historical matchmakers to be informed is guaranteed. A historical matchmaker retrieval formula accurately identifies the recipients who need to be notified, and batch notifications are achieved through an asynchronous message queue. Notification content is anonymized to inform the public while protecting the privacy of current contacts, and a unique indexing mechanism prevents duplicate notifications.

[0093] Fourth, it enables layered information visibility. Through a visibility permission matrix, different roles can see status information at different granularities, balancing the needs of transparency and privacy protection.

[0094] Fifth, it provides a traceable and fraud-proof system foundation. End-to-end log auditing, state change history records, and tamper-proof read-only storage together constitute a complete chain of evidence, providing technical support for dispute arbitration and fraud prevention analysis.

[0095] Sixth, protect user autonomy. The unilateral breakup mechanism allows users to end the relationship without the other party's consent, and a 24-hour cooling-off period prevents emotionally driven repeated actions.

[0096] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0097] Obviously, the embodiments described above are merely some embodiments of the present invention, not all embodiments. The accompanying drawings show preferred embodiments of the present invention, but do not limit the patent scope of the present invention. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the patent protection scope of this invention.

Claims

1. A method for managing relationship status on a dating and social networking platform, characterized in that, Includes the following steps: S1. Establish a unified state coding system, assign each user in the platform a discrete state code that includes at least the initial state, matchmaking / dating, dating, and romance, and configure the corresponding state transition path according to the matchmaking or dating mode selected by the user, and force verification that the user's state is the initial state when each relationship establishment operation is initiated. S2, in the matchmaking mode, implements mutual exclusion lock management on user status to ensure that any user can be in a non-initial state with at most one other user at the same time, and sets a 48-hour automatic confirmation window for the matchmaking status, and completes the status transfer from matchmaking to dating through a two-way confirmation mechanism. S3 establishes a forced entry channel for matchmaker operations into the system. All matchmaker matchmaking, confirmation, and abandonment operations are called through a dedicated API interface. Before executing a matchmaking operation, the target user's status is queried and verified in real time. If the status is not initial, the operation is rejected. All matchmaker operations are logged and audited throughout the entire process. S4, set a unified entry function for the dating status. When both parties are in a dating status in the matchmaking mode or both parties are in a dating status in the friendship mode, the status of both parties is updated to dating synchronously through this entry function in a transactional consistency manner, and the process of informing the historical matchmaker is triggered asynchronously after the status is updated. S5 defines a formula for the search scope of historical matchmakers. Based on this formula, the system automatically retrieves the set of historical matchmakers for users who are in a romantic relationship. It then sends a de-identified notification to each historical matchmaker in the set via a message queue and uses a unique index to prevent duplicate notifications. S6 constructs a hierarchical visibility control matrix, returning status information of different granularities based on the relationship type between the viewer and the target user—including romantic partners, historical matchmakers, matchmakers, the public, and platform administrators—and implements unilateral breakup atomic operations, allowing users to end romantic relationships without the other party's consent, while setting a 24-hour cooling-off period after the breakup.

2. The relationship status management method for a dating and social networking platform according to claim 1, characterized in that, The specific method for establishing a unified state coding system in step S1 is as follows: Create a status field user_status for each user in the platform's backend relational database. Store the status using an enumeration type or a small integer type. The status codes are defined as: 0 - Initial status, 1 - In the process of matchmaking / making friends, 2 - In the process of dating, 3 - In a relationship. Create a state change history table, state_change_log, to record the user ID, original state, target state, operator type, and change time for each state change, thus achieving traceability of all state changes; The mode-specific state mapping is implemented by creating a state transition configuration table, state_transition_config. This table contains at least the fields of mode type, original state, target state, and whether the transition is allowed. At the code level, a mode-aware state transition verification function is implemented. This function queries the state transition configuration table based on the current user's mode type to determine whether the transition from the original state to the target state is legal. The initial state mandatory verification is implemented by calling the state pre-check interface before each matchmaking, dating, or relationship request. This interface queries whether the user's current state code is equal to 0. If it is not 0, the operation is rejected and the error code ERR_STATE_NOT_INITIAL is returned. At the same time, an optimistic locking update statement UPDATE user_relationship_state SETstate_code = 1, partner_user_id = partner identifier WHERE user_id = user identifier AND state_code = 0 is used to avoid concurrent state pollution.

3. The relationship status management method for a dating and social networking platform according to claim 1, characterized in that, The specific method for managing the mutex lock state in the matchmaking mode in step S2 is as follows: Before each state change, a mutual exclusion check function is executed. This function first determines whether the current user's mode type is a matchmaking mode and whether the target state is not the initial state. If so, it checks whether the current user has a non-initial state record with a non-empty partner user identifier. If it does, it throws an exception and refuses the state change. At the database level, a partially unique index is created using the formula `CREATE UNIQUE INDEX idx_user_nonzero_state ON user_relationship_state (user_id) WHERE state_code != 0` to ensure that only one record of a user exists in a non-initial state. The 48-hour confirmation window and automatic reset are implemented in the following ways: Once a matchmaker successfully connects two people, the system creates a matchmaking record (matchmaking_record). This record contains an expiration time field (expire_time = NOW() + INTERVAL 48 HOUR). Every 10 minutes, a scheduled task scans for records that are pending confirmation and have an expiration time less than the current time. For each expired record, the system resets the status of both users to 0, deletes or marks the matchmaking record as expired, and sends an expiration notification to both users. The two-way confirmation mechanism is implemented by adding a first-party agreement field and a second-party agreement field to the matchmaking record table. When either party's user clicks "agree to interact" through the client, the confirmation interface is called to update the corresponding party's agreement field. After each update, the system checks whether both parties' agreement fields are true. If so, the system uses a transaction to synchronize the status of both users to "interacting" and points the user identifiers of the cooperating parties to each other. If either party refuses, the status of both users is reset to 0.

4. The relationship status management method for a dating and social networking platform according to claim 1, characterized in that, The specific method for forcibly entering the matchmaker operation into the system in step S3 is as follows: Develop a dedicated API endpoint for matchmakers. All requests must carry a matchmaker identity token generated based on the JWT or OAuth2 protocol. The API endpoint should include at least a matchmaking interface, a status query interface, and a confirmation interface. After receiving the request, the backend server first verifies the matchmaker's identity and permissions in the token. If the verification is successful, the operation log is recorded in the matchmaker_operation_log table. This table contains at least the matchmaker's identifier, operation type, set of user identifiers involved, operation result, and timestamp fields. The real-time status query and rejection mechanism is implemented by providing a status query interface. Before making a match, the matchmaker calls this interface and passes in the target user identifier. The backend queries the user's real-time status code and returns a boolean value indicating whether the match is possible. When the matchmaker attempts to make a match, the system automatically calls this interface to verify both parties. If either party returns a false boolean value indicating whether the match is possible, the matchmaking operation is rejected, and the atomicity of the query and subsequent update is guaranteed using the database row lock statement SELECT ... FOR UPDATE. The end-to-end logging and auditing is achieved by creating a matchmaker audit log table, matchmaker_audit_log. This table records at least the matchmaker identifier, target user identifier, operation action, request parameters, response result, IP address, user agent, and creation time. A log archiving policy is set to retain logs for at least 2 years, and a read-only database instance is used for storage to prevent log tampering.

5. The relationship status management method for a dating and social networking platform according to claim 1, characterized in that, The specific implementation method of the unified entry function for the relationship status in step S4 is as follows: Implement a unified entry function named enter_love_status, which takes three parameters: first user identifier, second user identifier, and source mode. Inside the function, the state validity is first checked based on the source pattern: if the source pattern is a matchmaking pattern, then the current state codes of the first user and the second user are both equal to 2, i.e., they are in a relationship. If the source mode is the dating mode, then check whether the current status codes of the first user and the second user are both equal to 1, i.e., the dating status. If any validation fails, a value error exception is thrown; if the validation passes, the following operations are performed sequentially within the database transaction: update the status code of the first user to 3 (i.e., in a relationship) and set the partner user identifier to the second user; update the status code of the second user to 3 (i.e., in a relationship) and set the partner user identifier to the first user; insert a relationship record into the love_record table to record the first user, the second user, and the start time. After the transaction is committed, the historical notification trigger function is called asynchronously, and a relationship confirmation notification is pushed to the first user and the second user respectively. The transaction consistency guarantee is implemented by using the transaction context manager of the database engine. If any database update statement executed within the transaction block fails, all operations are automatically rolled back to ensure the atomicity of the state updates for both parties.

6. The relationship status management method for a dating and social networking platform according to claim 1, characterized in that, The meaning of the formula for the historical matchmaker retrieval range in step S5 is as follows: H(u) = {p ∣ ∃ r ∈ R : (r.user_id_a = u ∨ r.user_id_b = u) ∧r.contact_id = p ∧ r.meet_time≥(T now - 6 months) ∧ p ≠ v} In: where H(u) represents the set of historical matchmakers for user u; p represents the historical matchmaking object; R represents the set of all matchmaking records in the platform; r represents a matchmaking record; r.user_id_a represents the identifier of the first-party user in the matchmaking record; r.user_id_b represents the identifier of the second-party user in the matchmaking record; r.contact_id represents the identifier of the other-party user paired with user u in the matchmaking record; r.meet_time represents the time when the matchmaking relationship was established between the two parties in the matchmaking record; T now This represents the current system time; 6 months represents the preset 6-month time window; v represents user u's current romantic partner; this formula is used to filter out matchmaking partners from all matchmaking records who simultaneously meet four conditions: there is a matchmaking record with user u, the matchmaking time is within 6 months of the present, and the partner is not user u's current romantic partner, ultimately forming a set of historical matchmakers for whom notifications need to be sent.

7. The relationship status management method for a dating and social networking platform according to claim 1, characterized in that, The specific implementation methods of the asynchronous batch notification mechanism and the anti-duplicate notification in step S5 are as follows: In the historical notification trigger function, the historical matchmaker identification list is first obtained by querying using structured query language according to the historical matchmaker retrieval range formula. The query statement is: SELECT DISTINCT CASE WHEN user_id_a = User ID THEN user_id_b ELSE user_id_a END AS contact_id FROM matchmaking_record WHERE (user_id_a = User ID OR user_id_b = User ID) AND meet_time >= DATE_SUB(NOW(), INTERVAL 6 MONTH) AND (CASE WHEN user_id_a = User ID THEN user_id_b ELSE user_id_a END) != Romantic Partner Identifier; Iterate through the list of historical matchmakers, generate a message body for each historical matchmaker that includes notification type, recipient user identifier, notification content, and whether to display the romantic partner flag, serialize the message body into a JSON string, and publish it to the specified topic or queue of the message queue. Independent consumer processes pull messages from the message queue and send notifications to clients in batches by calling push services, including APNS, FCM, and in-site messaging. The method of preventing duplicate notifications is achieved by creating a historical notification log table, which contains fields for user identifier, notified user identifier, relationship record identifier, and notification time. A unique index is created on the combined field of user identifier, notified user identifier, and relationship record identifier. When inserting a notification record, the INSERTIGNORE statement is used. If there is a unique index conflict, the insertion is ignored, thereby avoiding duplicate notifications. Simultaneously, frequency control logic is set: before generating a notification, the historical notification record table is queried to determine whether the same historical intermediary has been notified to the same user within 6 months; if so, the current notification is skipped.

8. The relationship status management method for a dating and social networking platform according to claim 1, characterized in that, The specific implementation of the hierarchical visibility control matrix in step S6 is as follows: Implement a visibility function named get_visible_state. This function takes two parameters: the viewer identifier and the target user identifier. Inside the function, the viewer's role type is first determined. Role types include romantic partner, historical matchmaker, matchmaker, public, and platform administrator. The function returns different visibility information based on different role types: If the viewer is the romantic partner and the viewer ID is equal to the target user's collaborator ID, then information containing the target user's complete status code and the collaborator ID is returned. If the viewer's role is the historical matchmaker, the returned status description is "in a relationship" and is desensitized information that does not contain any information about the romantic partner. If the viewer's role is matchmaker, the system returns information containing the target user's complete status code and the partner user's identifier. If the viewer's role is public, then further query the target user's privacy settings mode. If it is public mode and the target user's status code is "in a relationship", then return the status description as "in a relationship". Otherwise, return empty status information. If the viewer is a platform administrator, the system will return information including the target user's complete status code, the partner user's identifier, and the complete status change history. The visibility function is called at the application interface layer and dynamically serializes the returned JSON object according to the requester's identity, thereby achieving hierarchical control where different roles see different levels of status information.

9. A relationship status management device for a dating and social networking platform, characterized in that, include: The status establishment module is used to establish a unified status coding system, assigning each user in the platform a discrete status code that includes at least the initial status, matchmaking / dating, dating, and romance. Based on the matchmaking or dating mode selected by the user, the module configures the corresponding status transition path and enforces verification that the user's status is the initial status when each relationship establishment operation is initiated. The mutual exclusion lock management module is used to implement mutual exclusion lock management on user status in the matchmaking mode, ensuring that any user can be in a non-initial state with at most one other user at the same time, and setting a 48-hour automatic confirmation window for the matchmaking status, and completing the status transfer from matchmaking to dating through a two-way confirmation mechanism. The channel construction module is used to build a channel for forced entry of matchmaker operations into the system. All matchmaker matchmaking, confirmation, and abandonment operations are called through a dedicated API interface. Before executing a matchmaking operation, the target user's status is queried and verified in real time. If the status is not initial, the operation is rejected. All matchmaker operations are logged and audited in the entire chain. The entry setting module is used to set a unified entry function for the dating status. When both parties are in a dating status in the matchmaking mode or both parties are in a dating status in the friendship mode, the entry function will update the status of both parties to "dating" in a transactional consistency manner, and asynchronously trigger the notification process of the historical matchmaker after the status update. The retrieval definition module is used to define the formula for the retrieval scope of historical matchmakers. Based on this formula, it automatically retrieves the set of historical matchmakers of users who have entered a romantic relationship. It sends de-identified notifications to each historical matchmaker in the set through a message queue and uses a unique index to prevent duplicate notifications. The matrix module is used to construct a hierarchical visibility control matrix. Based on the relationship type between the viewer and the target user—including romantic partners, past matchmakers, matchmakers, the public, and platform administrators—it returns status information at different granularities and enables unilateral breakup atomic operations, allowing users to end romantic relationships without the other party's consent, while also setting a 24-hour cooling-off period after the breakup.

10. A computer device, characterized in that, The system includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the relationship status management method for a dating and social networking platform as described in any one of claims 1 to 8.

Images