A method and system for end-to-end address book synchronization

Abstract

The application discloses an end-to-end communication record synchronization method and system, relates to the technical field of communication, and saves user personal communication record data in a private device, satisfies the convenient and safe use of the user in multiple terminals, and thus guarantees that the personal communication record data can be recovered, synchronized, conveniently saved and found, and accessed and used by the user at any time and in any place. The data of the user communication record does not need to be saved in a platform, is completely stored in the private device, and finally realizes the functions of the synchronization, recovery and storage of the user communication record data in multiple terminals, avoids data leakage to a larger extent compared with previous methods, guarantees the safety of the data, and realizes the convenient personal data management.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and specifically to a method and system for end-to-end address book synchronization. Background Technology

[0002] In current internet communication, service providers store users' contact information in the cloud via cloud platforms, enabling contact synchronization across different devices. This allows for contact recovery on reset devices and downloading to new devices, significantly improving convenience. However, if this cloud platform is maliciously compromised, it can lead to data leakage. To address this, service providers typically enhance data encryption algorithms to improve the security of cloud platform data storage. However, the data content remains transparent and accessible to the service provider, and this approach doesn't effectively prevent malicious attacks, nor does it guarantee maximum protection against contact data leakage, privacy, or security. Summary of the Invention

[0003] The purpose of this invention is to propose an end-to-end contact synchronization method and system. By changing the storage of contact data to private devices instead of cloud storage, the leakage of contact data is minimized, and the user's data truly belongs to them.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] An end-to-end contact synchronization method, implemented based on a client, a private device, and an application platform, includes the following steps:

[0006] The application platform provides address book application distribution services for clients and private devices;

[0007] Users download and install the Contacts app from the application platform via the client, launch the Contacts app and authorize it, and then request contact data from the private device through the Contacts app;

[0008] Private devices download and install the address book application from the application platform, and use the address book application to provide address book services. Based on the client's request, the stored address book data is securely synchronized with the client.

[0009] Preferably, the client includes a main client, member clients authenticated by the main client, other terminals authenticated by the main client, and other terminals of member clients authenticated by the main client.

[0010] Preferably, the client that successfully binds to the private device for the first time is designated as the primary client. The primary client uses the public and private keys between itself and the corresponding private device for root authentication. The primary client's authentication of member clients or other terminals is based on this root authentication dependency.

[0011] Preferably, the client and the private device use the OAuth2 authentication and authorization scheme and employ end-to-end encrypted transmission.

[0012] Preferably, after the main client performs root authentication, i.e., after the main client and the private device exchange public and private keys in encrypted form, the main client generates a unique identifier for the administrator, User ID. When the main client authenticates the installed address book application, the address book application identifies and compares the string identifier of the User ID, and then obtains the access permission Scope of the address book application. At the same time, the address book application generates an independent record list, including: the unique identifier of the address book application, Applet ID, the authentication key of the address book application, Applet secret, Scope, and User ID.

[0013] Preferably, after being authenticated by the main client, the member client generates a unique identifier (User ID) and obtains the access permissions (Scope) and unique identifier (Applet ID) of the address book application. When the member client establishes authentication with the installed address book application, the address book application generates an independent record list, including: the Applet ID string, the address book application's authentication key (Applet secret), the Scope, and the User ID.

[0014] Preferably, the main client authorizes other terminals of the main client by setting an authentication method; the member client authorizes other terminals of the member client by setting an authentication method.

[0015] Preferably, the address book application distribution service provided by the application platform includes: accepting address book applications developed and designed by developers, and providing registration, publishing, storage, installation and update services for address book applications, so as to enable the normal installation and update of address book applications on private devices and clients.

[0016] Preferably, the address book application needs to obtain the private device's ID information (Box ID) before it runs. This Box ID is obtained by the user when binding the private device using the client.

[0017] Preferably, when a user authorizes the contacts application, the contacts application retrieves the authorization code (Auth Code) through the concatenated URL and sends an authorization page to the user. Based on the access token (Access Token) of the authorized content selected by the user on the authorization page, the contacts application invokes the authorized permissions to obtain basic application information, including the contact permission groups and permission list. After the user confirms the permission list, the client uses the authorized Access Token to confirm the authorization process by invoking the authorized AuthConfirm path. Simultaneously, the corresponding private device generates relevant authorization information for the contacts application.

[0018] Preferably, during the authorization process of the address book application, if the user has already authorized, the authorization code information will be returned via callback; if authorization has not been granted or the authorization has expired, the authorization failure information will be returned via callback.

[0019] Preferably, after the user confirms authorization to the address book application, the client calls back the concatenated URL, and the address book application obtains the user's authorization information across domains through the URL call. This information includes the Auth Code returned encrypted with a specified key.

[0020] Preferably, the address book application obtains an Access Token and a Refresh Token through an Authorization Code; after the Access Token expires, it uses the Refresh Token to obtain new Access Tokens and Refresh Tokens.

[0021] Preferably, the Auth Code can be obtained again by calling the function before it expires without user confirmation; if it expires, the user needs to confirm it again.

[0022] Preferably, the address book application deployed on the client side works in conjunction with the CardDAV service deployed on the private device to achieve address book synchronization.

[0023] An end-to-end address book synchronization system includes a client, a private device, and an application platform; wherein,

[0024] The application platform is used to provide address book application distribution services for clients and private devices;

[0025] The client is used to download and install the address book application from the application platform, launch the address book application, and request address book data from the private device through the address book application;

[0026] Private devices are used to download and install contact applications from application platforms, implement contact services through contact applications, and securely synchronize stored contact data with the client according to the client's request.

[0027] Preferably, the client includes a main client, member clients authenticated by the main client, other terminals authenticated by the main client, and other terminals of member clients authenticated by the main client.

[0028] The beneficial effects achieved by this invention are as follows:

[0029] The method and system provided by this invention store users' personal contact list data on private devices, while simultaneously enabling convenient and secure multi-device use. This ensures that personal contact list data can be promptly recovered, synchronized, easily saved, and retrieved, allowing users to access and use it anytime, anywhere across multiple devices. Furthermore, user contact list data does not need to be stored on a platform; the data is entirely stored on the private device. Ultimately, this achieves multi-device synchronization, recovery, and storage of user contact list data, while significantly reducing the risk of data leakage compared to previous methods, ensuring data security while enabling convenient personal data management. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of a contact synchronization system proposed in this invention;

[0031] Figure 2 This is a screenshot of the Contacts application authorization page;

[0032] Figure 3 This is a flowchart illustrating the process of the main client authorizing the address book application;

[0033] Figure 4 This is a flowchart illustrating the process of obtaining cross-domain authorization for installing a contact application on a client side. Detailed Implementation

[0034] To make the above features and advantages of the present invention more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings.

[0035] This embodiment specifically implements a contact synchronization system and method proposed in this invention. The system includes a client, a private device, and an application platform. The client and the private device synchronize contact data through an installed contact application. Specifically, the contact application is a software tool that enables personalized functions on the client and allows access to the private device for contact data synchronization; it is a prerequisite for the contact functionality. The application platform is responsible for distributing the contact application. Figure 1 As shown.

[0036] Specifically, the client corresponds to the private device. Users install the address book application on the client and launch and authorize it. The authorization process involves the user confirming the permissions the address book application can access. The private device is a hardware device used to store address book data and is responsible for synchronizing it with the client. It is a type of private server, including a processor and memory, and has the address book application installed, providing address book services. Encrypted transmission of address book data is achieved through an end-to-end secure transmission module that works in conjunction with the client side. The application platform provides application distribution services to the client and private device, including accepting address book applications developed by developers and providing services such as registration, publishing, storage, installation, and updates to ensure the normal installation and updates of the address book application on both the private device and the client.

[0037] According to some implementation methods, the client side is not limited to a single user or a single terminal. Specifically, the client side can have one user using multiple terminals simultaneously, with the first authenticated terminal serving as the primary client. The client side can also have more than one user, with the first authenticated user serving as the administrator and the other users as members; the clients used by the members are called member clients. Similarly, each member on the client side is not limited to using only one terminal; they can use multiple terminals simultaneously, with the first terminal serving as the member client. The aforementioned clients and terminals can be the same or different types of electronic devices, such as desktop computers, laptops, tablets, mobile phones, etc., and are not limited thereto.

[0038] According to some implementation methods, this system adopts the OAuth2 authentication and authorization scheme to enable convenient access for multiple users and multiple terminals. To ensure the security of users' personal data, an end-to-end encrypted transmission method is used, without going through third-party services, thus maximizing the protection of users' contact book synchronization function and data security.

[0039] According to some implementation methods, user authorization and authentication are required to achieve secure data synchronization across multiple devices. After successful installation and authorization, the corresponding contact list authorization permissions are selected to enable the function. The aforementioned multiple users and multiple terminals serve as the authorization entities, namely the main client, member clients authenticated by the main client, other terminals authenticated by the main client, and other terminals of member clients authenticated by the main client. These authorization entities have a hierarchical relationship in authentication. The main client, being authorized and authenticated, can be considered a trusted entity to ensure data security.

[0040] According to some implementation methods, the address book application needs to obtain the unique identifier (BoxID) of the private device before it can run. This BoxID is obtained when the user binds the private device using their client. The address book application is installed on both the private device and the client, and is launched, authorized, and uses the desired functions and services by the user on the client side. The client that successfully binds to the private device for the first time is designated as the primary client. Other terminals become active after obtaining the BoxID through activation based on the primary client.

[0041] According to some implementation methods, the main client authentication is a more stringent root authentication, based on the public and private keys of the private device and the corresponding client. Subsequent authentication of other member clients and terminals relies on this root authentication. After the main client and the private device have a pre-existing encrypted exchange of public and private keys, the main client generates a unique identifier for its administrator identity: User ID: Admin. When the main client authenticates with the address book application, the application identifies and compares this User ID string to obtain access permissions for the address book application. During the mutual authentication process between the main client and the address book application, the application generates an independent record list, including the address book application's unique identifier Applet ID string, the address book application's authentication key Applet secret string, the address book application's access permissions Scope, and the User ID string Admin.

[0042] In some implementation methods, the authentication subject of the address book application is the member client. Multiple users can use it independently on a private device, but authorization from the main client administrator user is required. In this case, the member client generates a unique User ID to identify the member user. With authorization, the application and client can also be used in conjunction. The authorized user is the member user. The member user must first establish an authentication relationship with the main client to obtain access to the address book application and the Applet ID. When a member user establishes authentication with the address book application, the application generates a separate list of records, including the Applet ID string, the Applet secret string, the Scope, and the User ID string.

[0043] According to some embodiments, the authorization entities of the address book application include other terminals authenticated by the client, and other terminals of the member clients authenticated by the main client. To achieve convenient access, users on the main client side and the member client side can simultaneously authorize logins on other terminals at any time, enabling the linked use of other terminals and the application. To enable the main client side to use the application at any time and place, based on the authentication method set on the main client side, such as the combination of QRcode scanning and authorization code, after successful verification, the user can log in on any other terminal and directly access the application functions to achieve convenient operations. The same applies to member clients. Multiple terminals of multiple users can access the application at any time and place.

[0044] According to some embodiments, when different users obtain access rights to the same Applet ID, the specific function selection and function permissions of the address book application are independently determined by each user, and the application call data between users is isolated. There is no possibility of random access, transfer, or call of information in the default settings, thus ensuring the information security of each user and enabling them to enjoy the autonomy of personal data.

[0045] According to some embodiments, the process of authorizing and implementing the address book application functions is as follows: During the user authorization authentication process, the user needs to agree to call their address book permissions. The authorization code Auth Code is obtained by calling the URL spliced by the address book application that contains the authorization code Auth Code. The address book application will send a user authorization page (see Figure 2 ) to the user subject at the requesting end. Based on the content that the user selects to authorize and the authorized access credential Access Token, the address book application calls the specific application permissions Auth Scopes authorized by the user to obtain the basic application information on the client side after authorization. This information includes the permission group and permission list selected by the user to apply for, that is, the permission group and permission list of the address book. After the user views and confirms the popped-up permission list, the client side (i.e., each authorized entity side after authentication) uses the authorized Access Token to confirm the authorization process by calling the authorized Auth Confirm path (authorization confirmation path). At the same time, the corresponding private device side has generated relevant authorization information for this address book application. During the address book application authorization process, if the user has already given an authorization instruction, the authorization code information will be returned in the callback; if not authorized or the authorization has expired, an authorization failure information will be returned in the callback. As Figure 3 shown.

[0046] According to some embodiments, after the user confirms the authorization, the client calls back the spliced URL, and the address book application can obtain the user's authorization information across domains through this URL. This information includes the AuthCode encrypted and returned by the specified key, as Figure 4As shown. Cross-domain access to the authorization code is an optional optimization solution. When the contact application is already authorized by the user, there is no need to go through the authentication and authorization process again; the code can be obtained directly.

[0047] According to some implementation methods, the address book application can obtain an Access Token and a Refresh Token through the Auth Code. Users can call open business interfaces within their authorized scope, such as current user information. After the Access Token expires, a new Access Token and Refresh Token can be obtained using the Refresh Token.

[0048] According to some implementation methods, the address book application obtains the relevant peer key and random vector when it obtains the Access Token; the Refresh Token is to ensure that the session can still be renewed after the Access Token expires.

[0049] According to some implementation methods, the Auth Code has an expiration time. If it can still be obtained again before it expires without user confirmation, the user needs to confirm it again after it expires.

[0050] According to some implementation methods, the address book service provided by the private device is an interface service that is deployed and configured. The address book application is implemented based on the address book service. When the address book application is selected based on the user's actual needs, the address book application is called and run based on the address book service.

[0051] According to some implementation methods, the address book application deployed on the client side works with the CardDAV service deployed on the private device to achieve address book synchronization. Configuration and use are achieved through created accounts. After configuration, the automatic synchronization function of the address book application is implemented based on the address book application system and calls to the CardDAV service. Users can choose to import contacts from their address book or vCard contacts to create their own space address book application. Because the address book application itself is designed for multi-device sharing and multi-user use, users can manage their space's address book across multiple devices, such as viewing and deleting. When a user uses multiple devices, the client will display the user's authorization record, including basic information and device identifiers for each terminal, to facilitate user management.

[0052] According to some implementation methods, the synchronization function of the address book application can also support synchronization with other APP software on the user's terminal, in addition to the client software. Provided the APP software supports CardDAV service, the user needs to enter the corresponding CardDAV account to be synchronized according to the prompts. This will then synchronize and display the address book data and enable address book management operations such as viewing and deleting.

[0053] Although the present invention has been disclosed above with reference to embodiments, it is not intended to limit the present invention. Appropriate modifications or equivalent substitutions made by those skilled in the art to the technical solutions of the present invention should be covered within the protection scope of the present invention, which is defined by the claims.

Claims

1. A method for end-to-end address book synchronization, implemented based on a client, a private device, and an application platform, characterized in that, The method includes the following steps: The application platform provides address book application distribution services for clients and private devices; Users download and install the Contacts app from the application platform via the client, launch the Contacts app and authorize it, and then request contact data from the private device through the Contacts app; Private devices download and install the address book application from the application platform, and implement address book services through the address book application. Based on the client's request, the stored address book data is securely synchronized with the client. The client includes a main client, member clients authenticated by the main client, other terminals authenticated by the main client, and other terminals of member clients authenticated by the main client. The client that successfully binds to the private device for the first time is the default main client. The main client uses the public and private keys between itself and the corresponding private device for root authentication. The main client's authentication of member clients or other terminals is based on this root authentication dependency. The client and the private device use the OAuth2 authentication and authorization scheme. After the main client performs root authentication, i.e., after the main client and the private device exchange public and private keys in encrypted form, the main client generates a unique identifier for the administrator, User ID. When the main client authenticates the installed address book application, the address book application identifies and compares the User ID with the string identifier, and then obtains the address book application's access permissions, Scope. At the same time, the address book application generates an independent record list, including: the address book application's unique identifier, Applet ID, the address book application's authentication key, Applet secret, Scope, and User ID. After being authenticated by the main client, the member client generates a unique identifier (User ID) and obtains access permissions (Scope) and a unique identifier (Applet ID) for the Contacts application. When the member client establishes authentication with the installed Contacts application, the Contacts application generates an independent list of records, including: the Applet ID string, the Applet secret authentication key of the Contacts application, the Scope, and the User ID.

2. The method as described in claim 1, characterized in that, The application platform provides contact application distribution services including: accepting contact applications developed by developers, and providing registration, publishing, storage, installation and update services for contact applications, so as to enable the normal installation and update of contact applications on private devices and clients.

3. The method as described in claim 1, characterized in that, Before the address book application can run, it needs to obtain the private device's ID information, Box ID, which is obtained by the user when binding the private device using the client.

4. The method as described in claim 1, characterized in that, When a user authorizes the contacts application, the contacts application retrieves the authorization code (Auth Code) through the concatenated URL and sends an authorization page to the user. Based on the access token (Access Token) of the authorized content selected by the user on the authorization page, the contacts application invokes the authorized permissions to obtain basic application information, including the contact permission groups and permission list. After the user confirms the permission list, the client uses the authorized AccessToken to confirm the authorization process by calling the authorized Auth Confirm path; At the same time, the corresponding private device generates relevant authorization information for the address book application; During the authorization process for the contacts application, if the user has already authorized the application, the authorization code will be returned via callback; if the user has not yet authorized the application or the authorization has expired, the authorization failure message will be returned via callback. After the user confirms authorization to the contacts application, the client sends a callback to the concatenated URL. The contacts application then uses this URL to obtain the user's authorization information across domains. This information includes an Auth Code that is encrypted with a specified key and returned.

5. The method as described in claim 4, characterized in that, The address book application obtains an Access Token and a Refresh Token through an Authorization Code; after the Access Token expires, it uses the Refresh Token to obtain new Access Tokens and Refresh Tokens. If the Auth Code can be retrieved again before it expires without user confirmation, then user confirmation is required after it expires.

6. The method as described in claim 1, characterized in that, The address book application deployed on the client side works in conjunction with the CardDAV service deployed on the private device to achieve address book synchronization.

7. A system for end-to-end contact list synchronization, characterized in that, This includes clients, private devices, and application platforms; among them, The application platform is used to provide address book application distribution services for clients and private devices; The client is used to download and install the address book application from the application platform, launch the address book application, and request address book data from the private device through the address book application; Private devices are used to download and install contact applications from application platforms, implement contact services through contact applications, and securely synchronize stored contact data with the client according to the client's request; The client includes a main client, member clients authenticated by the main client, other terminals authenticated by the main client, and other terminals of member clients authenticated by the main client. The client that successfully binds to the private device for the first time is the default main client. The main client uses the public and private keys between itself and the corresponding private device for root authentication. The main client's authentication of member clients or other terminals is based on this root authentication dependency. The client and the private device use the OAuth2 authentication and authorization scheme. After the main client performs root authentication, i.e., after the main client and the private device exchange public and private keys in encrypted form, the main client generates a unique identifier for the administrator, User ID. When the main client authenticates the installed address book application, the address book application identifies and compares the User ID with the string identifier, and then obtains the address book application's access permissions, Scope. At the same time, the address book application generates an independent record list, including: the address book application's unique identifier, Applet ID, the address book application's authentication key, Applet secret, Scope, and User ID. After being authenticated by the main client, the member client generates a unique identifier (User ID) and obtains access permissions (Scope) and a unique identifier (Applet ID) for the Contacts application. When the member client establishes authentication with the installed Contacts application, the Contacts application generates an independent list of records, including: the Applet ID string, the Applet secret authentication key of the Contacts application, the Scope, and the User ID.

Images