A device contact identity and cloud coordination account sub-domain transfer and usage measurement method and system for external cooperation of intelligent devices

Abstract

The application discloses a device contact identity and cloud collaboration account sub-domain transfer and usage measurement method and system for external collaboration of intelligent devices. A device contact identity is configured for an intelligent device; after the intelligent device meets the cloud collaboration service authorization conditions, the device management domain issues authorization and returns creation authorization information without the device contact identity; the intelligent device locally generates a cloud collaboration account identity distinguished from the device contact identity and registers to the cloud collaboration service domain, and the cloud collaboration service domain saves service records and usage records without saving the direct reverse mapping of both. In external collaboration, the intelligent device forms a service qualification certificate without the device contact identity based on local authorization, and the transfer service completes verification, external calling and usage measurement accordingly, and accesses external services with a unified upstream identity. The application can reduce the risk of long-term combination of device management information and daily cloud collaboration behavior while retaining device management and service measurement capabilities.

Description

Technical Field

[0001] This invention relates to the fields of smart devices, external collaboration, relay services, identity management, privacy protection, and usage metering, specifically to a method and system for device communication identity and cloud collaboration account domain-based relay and usage metering for external collaboration of smart devices. Background Technology

[0002] Smart devices deployed in homes, offices, hotel rooms, elderly care facilities, showrooms, or commercial spaces typically require both remote device management and the ability to utilize third-party large-scale models, visual models, search services, or other external collaborative services to complete complex tasks. The former requires devices to have a stable ability to identify and communicate with the smart device throughout its management cycle, supporting device activation, online management, system messages, emergency notifications, and remote updates; the latter requires the platform to handle service authorization, call relay, anomaly control, and usage metering.

[0003] If the same device contact identity is used for both device management and external collaboration for an extended period, device lifecycle information, online contact information, cloud call behavior, and usage patterns can easily aggregate under the same identity, leading to an overly centralized device behavior profile. Completely eliminating identifiable identities, on the other hand, would make device management difficult, service authorization difficult, call measurement difficult, and anomaly control difficult.

[0004] Existing model gateways typically provide unified access, call forwarding, model routing, and cost statistics, and existing identity solutions can handle device identity or account identity separately. However, ordinary platform proxies do not provide a domain-specific solution suitable for smart device scenarios to address the following technical contradictions: on the one hand, smart devices need to retain a device identity that can be identified and contacted within the device management cycle; on the other hand, daily external collaboration should avoid long-term merging with device contact identities; at the same time, the service provider still needs to complete service authorization, cloud call forwarding, usage metering, and anomaly control. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for separating device contact identity and cloud collaboration account for external collaboration of smart devices and for usage measurement. This method separates device contact identity and cloud collaboration account identity according to purpose while preserving device manageability, service measurability, and external collaboration executableness. This reduces the risk of device management information and daily cloud collaboration behavior being automatically merged into a single trajectory on the service provider side.

[0006] To achieve the above objectives, this invention configures a device contact identity for smart devices. This device contact identity is used to identify and contact the smart device during the device management cycle, and is used for at least one of the following: device activation, lifecycle management, online communication, remote configuration, system updates, system messages, fault diagnosis, or emergency notifications. After confirming that the smart device corresponding to the device contact identity meets the cloud collaboration service authorization conditions, the service provider, through the device management domain, issues a cloud collaboration service authorization to the smart device and records the service authorization status corresponding to the device contact identity in the device management domain.

[0007] When a user initiates a cloud collaboration account creation request on the smart device side, the device management domain returns a creation permission result and creation authorization information based on the service authorization status, and records the cloud collaboration account lifecycle information corresponding to the device's contact identity. This cloud collaboration account lifecycle information may include at least one of the following: whether it has been created, creation time, number of creations, last deregistration time, current creation status, or other information related to cloud collaboration account lifecycle management, without storing the specific cloud collaboration account identity. Subsequently, the smart device generates a cloud collaboration account identity locally that is distinct from the device's contact identity, and registers this cloud collaboration account identity to the cloud collaboration service domain based on the creation authorization information.

[0008] After verifying the creation authorization information, the cloud collaboration service domain saves service records based on the cloud collaboration account identity. These service records can be used for at least one of the following: service qualification verification, session context maintenance, usage metering, anomaly detection, or service deactivation. Simultaneously, the cloud collaboration service domain does not save a direct reverse lookup mapping between the cloud collaboration account identity and the device contact identity. Therefore, the service provider side forms two separate record domains based on their purpose: the device management domain and the cloud collaboration service domain. The former can save device management and account lifecycle information related to the device contact identity, while the latter can save service records related to the cloud collaboration account identity. However, the two are not automatically merged through direct mapping.

[0009] When a smart device initiates an external collaboration request, it first determines whether the request is allowed based on its locally stored cloud collaboration service authorization status. If allowed, the smart device generates a service qualification certificate (excluding device contact identity) based on its current cloud collaboration service authorization and sends this certificate along with the external collaboration request. The relay service then performs service qualification verification, external collaboration invocation, and usage metering based on the cloud collaboration account identity and the service qualification certificate. The service qualification certificate can be verified by the relay service itself or its verifiable content, without needing to look up the record corresponding to the device contact identity based on the cloud collaboration account identity. After completing the service qualification verification, the relay service does not store the service qualification certificate as a long-term association key between the cloud collaboration account identity and the device contact identity, and uses the unified upstream identity on the relay service side to access the external collaboration service, ensuring that the data sent to the external collaboration service does not contain the device contact identity. After the external collaboration service returns a result, the relay service returns the result to the cloud collaboration account session that initiated the external collaboration request and records the corresponding usage information in the cloud collaboration service domain based on the cloud collaboration account identity.

[0010] Compared with the prior art, the present invention has at least the following beneficial effects: I. Without eliminating device communication capabilities, device communication identities and cloud collaboration account identities are separated by purpose, reducing the risk of natural aggregation of device management information and daily cloud collaboration activities. II. The device management domain can store device management and account lifecycle information related to the device communication identity, but not the specific cloud collaboration account identity; the cloud collaboration service domain can store service records related to the cloud collaboration account identity, but not the direct reverse lookup mapping between the cloud collaboration identity and the device communication identity. III. The service provider can still complete authorization issuance, device management, external collaboration relay, usage statistics, and service deactivation without disrupting the service operation loop due to identity domain separation. IV. External collaboration services only see the unified upstream identity of the relay service side and do not receive device communication identities, thereby reducing the ability of third-party service sides to identify the true user entity. V. By generating cloud collaboration account identities locally on the smart device and controlling their cancellation by the smart device holding the account control information, the lifecycle of the cloud collaboration account can be separated from the lifecycle of the device communication identity. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the domain-separated architecture for device communication identity and cloud collaborative account as described in this invention.

[0012] Figure 2 This is a schematic diagram of the service authorization and cloud collaboration account creation process described in this invention.

[0013] Figure 3 This is a schematic diagram of the external collaborative transfer and usage measurement process described in this invention.

[0014] Figure 4 This is a schematic diagram of the cloud collaborative account cancellation and reconstruction process described in this invention. Detailed Implementation

[0015] The present invention will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0016] like Figure 1 As shown, smart devices correspond to at least two types of identities: device contact identity and cloud collaboration account identity. The device contact identity can be formed after the device is activated at the factory and can be written to a protected storage area, ensuring its identifiability and contactability for at least one device management cycle. In some embodiments, the device contact identity can be a unique and fixed device identifier; in other embodiments, it can be a device identifier that can stably identify the corresponding smart device within a predetermined management cycle. The cloud collaboration account identity is created by the user on the smart device side as needed and is used for external collaboration service access and usage metering.

[0017] The device management domain can store at least one of the following: device contact identity, service authorization status, authorization validity period, available quota, package type, whether cloud collaboration account creation is allowed, cloud collaboration account creation time, creation count, last deregistration time, current creation status, or other account lifecycle information. The cloud collaboration service domain can store at least one of the following: cloud collaboration account identity, account validity status, call usage, session context, abnormal status, deactivated status, or other service records. The device management domain and the cloud collaboration service domain can adopt independent identifier spaces, independent data tables, or logically isolated record structures; the device management domain does not store specific cloud collaboration account identities, and the cloud collaboration service domain does not store direct reverse lookup fields or query interfaces between cloud collaboration account identities and device contact identities.

[0018] like Figure 2As shown, in one embodiment, the cloud collaboration service authorization conditions may include valid subscription, valid package authorization, available prepaid credit, payment confirmation, pre-installed authorization, or other conditions that indicate the current smart device is qualified to use the cloud collaboration service. Taking a fixed-period subscription as an example, after a user purchases a one-year cloud collaboration service, the service provider completes payment confirmation and issues a one-year valid cloud collaboration service authorization to the corresponding smart device based on the device's contact identity. Taking a prepaid credit as an example, after the user completes credit top-up, the service provider may also issue a cloud collaboration service authorization corresponding to the available credit to the corresponding smart device. The authorization may include at least one of the following: authorization validity period, authorization status, authorization verification information, available credit information, or package type information, and is written to the protected storage area of ​​the smart device. The device management domain simultaneously records the current service authorization validity and corresponding authorization status of the device.

[0019] When a user subsequently initiates a request to create a cloud collaboration account on the smart device side, the smart device submits its device contact identity and current service authorization status to the device management domain. After successful verification by the device management domain, it returns an authorization result and creation authorization information, and updates the cloud collaboration account lifecycle information corresponding to that device, such as at least one of the following: creation time, number of creations, or current account status. However, it does not generate or save a specific cloud collaboration account identity. Upon receiving the authorization result, the smart device generates the cloud collaboration account identity and account control information locally and registers the cloud collaboration account identity along with the creation authorization information to the cloud collaboration service domain.

[0020] The creation authorization information is used to prove to the cloud collaboration service domain that the current smart device has obtained the service qualification to create a cloud collaboration account. This creation authorization information can be a one-time credential, time-limited credential, or other authorization data issued by the device management domain and independently verifiable by the cloud collaboration service domain, used solely for account creation qualification verification. It does not include the device contact identity or the identity of the cloud collaboration account to be created. Independent verification means that the cloud collaboration service domain can complete the qualification verification based on the creation authorization information itself or its verifiable content, without needing to look up the corresponding record of the device contact identity using the identity of the cloud collaboration account to be created. The account control information may include keys, signature capabilities, token control information, or other data that can prove account control. The cloud collaboration service domain can register the account after verifying the creation authorization information and verify, based on the account control information, that subsequent call or cancellation requests are indeed initiated by the smart device holding the account control information. After registration, the creation authorization information is not stored as a long-term association key between the cloud collaboration account identity and the device contact identity. Since the cloud collaboration account identity is generated locally on the smart device, and the device management domain does not store the specific cloud collaboration account identity, the device management record and the cloud collaboration service record are maintained in different record domains; no query fields or interfaces are set between the different record domains to directly look up the device contact identity using the cloud collaboration account identity. In some implementations, the independent verification of the creation authorization information can be achieved cryptographically: the device management domain uses a signing key to digitally sign or generate a message authentication code for the verifiable content of the creation authorization information (such as creation qualification, validity period or validity conditions, one-time random number or serial number), and the cloud collaboration service domain uses the corresponding verification key or verification parameters to complete the verification only based on the verifiable content and its signature, without needing to look up the device contact identity using the cloud collaboration account identity to be created; specific signing and verification methods can be found in the external collaboration relay embodiment below, and this invention does not limit the specific cryptographic algorithm.

[0021] like Figure 3As shown, when a user initiates a task requiring external models, external search, or other external collaborative capabilities, the smart device can first complete the necessary task preparation locally. When local authorization is valid, it forms a service qualification certificate based on the current cloud collaborative service authorization. Then, it sends the external collaborative request and the service qualification certificate to the relay service through its cloud collaborative account identity. The service qualification certificate can be signature data, tokens, proof values, or other verifiable authorization data derived from the current cloud collaborative service authorization. The relay service can complete service qualification verification based on the service qualification certificate itself or its verifiable content, without needing to reverse-query the device contact identity record based on the cloud collaborative account identity. After verification, the relay service does not save the service qualification certificate as a long-term association key between the cloud collaborative account identity and the device contact identity. Subsequently, the relay service uses its unified upstream identity to access the external collaborative service. The external collaborative service receives the relay service's identity and task payload, but not the device contact identity. In some implementations, the independent verifiability of the service qualification certificate can be achieved through cryptography. Specifically, the device management domain or authorized issuer holds the issuing key and digitally signs or generates a message authentication code for the verifiable content of the service qualification certificate. The verifiable content may include the service authorization scope, authorization validity period or valid conditions, available credit, an identifier bound to the current cloud collaboration account identity, and at least one of a one-time random number, serial number, or timestamp. The relay service holds a verification key or verification parameter corresponding to the issuing key. Based solely on the verifiable content carried by the service qualification certificate and its signature or message authentication code, it can verify that the certificate was indeed issued by a legitimate issuer, that the authorization scope is valid, and that it has not expired or been replayed, thereby completing the service qualification verification. The verification key or verification parameter itself is not encoded and does not depend on the device contact identity. Therefore, the relay service does not need to reverse-lookup the device contact identity based on the cloud collaboration account identity when completing the above verification, and the verification process itself does not provide a way to restore the device contact identity from the service qualification certificate or verification key. In other embodiments, the relay service may also combine the signature generated by the smart device using the account control information to verify that the current request was indeed initiated by the smart device holding the cloud collaboration account. The verification methods for the aforementioned digital signatures, message authentication codes, or verifiable credentials may include, but are not limited to, asymmetric digital signatures based on public and private keys, message authentication codes based on shared keys, or signature verification based on verifiable credentials. This invention does not limit specific cryptographic algorithms. The aforementioned signature and verification methods are also applicable to the independent verification of the authorization information created above by the cloud collaboration service domain. After completing the verification, the relay service does not save the service qualification certificate, nor does it use it as a long-term association key between the cloud collaboration account identity and the device contact identity.

[0022] The relay service can record usage information corresponding to the cloud collaboration account identity in the cloud collaboration service domain. This usage information may include at least one of the following: number of calls, number of input tokens, number of output tokens, total number of tokens, model service category, call duration, call status code, cost estimate, or abnormal status. Here, a token is the unit of word usage in the model call. The service provider can use this information to perform service consumption statistics, capacity planning, anomaly detection, and necessary service shutdowns. Under fixed-period subscription, fixed-amount packages, or unlimited-amount packages, the user does not need to perceive token consumption each time.

[0023] The relay service can record usage information corresponding to the cloud collaboration account identity in the cloud collaboration service domain. This usage information may include at least one of the following: number of calls, number of input tokens, number of output tokens, total number of tokens, model service category, call duration, call status code, cost estimate, or abnormal status. Here, a token is the unit of word usage in the model call. The service provider can use this information to perform service consumption statistics, capacity planning, anomaly detection, and necessary service shutdowns. Under fixed-period subscription, fixed-amount packages, or unlimited-amount packages, the user does not need to perceive token consumption each time.

[0024] In one authorization update embodiment, the authorization update is performed on the cloud collaboration service authorization corresponding to the smart device, rather than being completed independently by the cloud collaboration account identity. The authorization update may include renewal, quota replenishment, package switching, or other operations that cause changes in the cloud collaboration service authorization status. After the user completes the authorization update on the smart device side, the service provider returns the updated cloud collaboration service authorization to the smart device based on the device's contact identity. The updated cloud collaboration service authorization may carry at least one of the updated authorization validity period, available quota, package type, or authorization status. The smart device updates its locally stored authorization status accordingly. Subsequently, when the smart device initiates an external collaboration request through the current cloud collaboration account, the smart device can form an updated service qualification certificate based on the updated cloud collaboration service authorization. After verifying the updated service qualification certificate, the relay service updates the service status corresponding to the current cloud collaboration account identity. The updated service qualification certificate does not include the device contact identity and, after verification and service status update, is not stored as a long-term association key between the cloud collaboration account identity and the device contact identity. Therefore, the device-side authorization update result can take effect naturally in subsequent call chains without establishing a long-term external association between the cloud collaboration account identity and the device contact identity during the authorization update.

[0025] In some embodiments, the relay service may include a primary relay service and a backup relay service. When the primary relay service is unavailable, the smart device or the relay service may switch external collaboration requests to the backup relay service; the backup relay service continues to perform service qualification verification and usage metering based on the cloud collaboration account identity to reduce the impact of single point of failure on external collaboration capabilities.

[0026] like Figure 4 As shown, when a user requests to delete a cloud collaboration account, the smart device can submit a request to the device management domain for device contact identity, current service authorization status, and account cancellation status. After confirming the service authorization status, the device management domain updates the cloud collaboration account lifecycle information for the corresponding device, such as the most recent cancellation time, current creation status, or at least one of other information related to account lifecycle management. Simultaneously, the smart device holding the account control information submits a cancellation request confirmed by the account control information to the cloud collaboration service domain. After successful verification, the cloud collaboration service domain deletes or invalidates the service record corresponding to the cloud collaboration account identity.

[0027] If the user is still within the valid service authorization period, the device management domain can again return an approval result, allowing the user to generate a new cloud collaboration account identity locally on the smart device. The device management domain can record that the device has ever created a new cloud collaboration account, but it does not save the specific string of the previous or next account.

[0028] In a home scenario implementation, the device contact identity DEVICE-01 is used to receive system OTA and emergency notifications; after the user purchases a one-year cloud collaboration service, the smart device obtains local authorization. The user then creates a cloud collaboration account CLOUD-A. The device management domain records that DEVICE-01 has obtained service authorization and has created a cloud collaboration account once, but does not store CLOUD-A; the cloud collaboration service domain stores the call volume, abnormal status, and service validity period of CLOUD-A, but does not store its direct mapping to DEVICE-01.

[0029] When CLOUD-A initiates an external model call, the relay service accesses the target model service with a unified upstream identity, and the model service does not accept DEVICE-01. If CLOUD-A is subsequently deregistered by the user, the cloud collaboration service domain deletes or invalidates CLOUD-A's service record; if the user recreates CLOUD-B within the service authorization period, the device management domain can update the account lifecycle information corresponding to DEVICE-01, but does not save CLOUD-B's specific identity.

[0030] This invention can also be implemented as a system. The system includes intelligent devices, a device management domain, a cloud collaborative service domain, a relay service, and an external collaborative service interface. The intelligent devices may include a device identity management unit, a local authorization verification unit, a cloud collaborative account generation unit, and an account lifecycle control unit; the device management domain may include a service authorization management unit and a device status recording unit; the cloud collaborative service domain may include an account verification unit, a service recording unit, a usage recording unit, and an anomaly control unit; the relay service may include a qualification verification unit, a usage metering unit, a unified exit call unit, and a primary / backup switchover unit.

[0031] In different implementations, the device management domain, cloud collaboration service domain, and relay service can be deployed separately, or they can be implemented as logically isolated functional domains within the same service providing platform; as long as they meet the restrictions of identifier space isolation, record field isolation, and direct reverse lookup interface described in this invention, the domain-based processing can be achieved.

Claims

1. A method for device communication identity and cloud collaboration account domain-based transfer and usage metering for external collaboration of smart devices, characterized in that, Applied to systems including smart devices, device management domains, cloud collaboration service domains, relay services, and external collaboration services, the method includes: Configure a device contact identity for a smart device. The device contact identity is used to identify and contact the smart device during the device management cycle, and is used for at least one of the following: device activation, lifecycle management, online communication, remote configuration, system update, system message, fault diagnosis, or emergency notification. After confirming that the smart device corresponding to the device contact identity meets the cloud collaboration service authorization conditions, the device management domain issues a cloud collaboration service authorization to the smart device and records the service authorization status corresponding to the device contact identity in the device management domain. In response to a user's request to create a cloud collaboration account on the smart device side, the device management domain returns an permission to create and creation authorization information based on the service authorization status, and records the cloud collaboration account lifecycle information corresponding to the device contact identity, without saving the cloud collaboration account identity generated locally by the smart device. The creation authorization information is used to prove that the current smart device has the service qualification to create a cloud collaboration account, and does not include the device contact identity and the cloud collaboration account identity to be created. The smart device generates a cloud collaboration account identity locally that is distinct from the device contact identity, and registers the cloud collaboration account identity to the cloud collaboration service domain based on the creation authorization information. After verifying the creation authorization information, the cloud collaboration service domain saves service records based on the cloud collaboration account identity, but does not save the direct reverse lookup mapping between the cloud collaboration account identity and the device contact identity. Furthermore, after registration, the creation authorization information is not saved as a long-term association key between the cloud collaboration account identity and the device contact identity. When the smart device initiates an external collaboration request, provided that the cloud collaboration service authorization on the smart device's local machine is valid, the smart device generates a service qualification certificate based on the current cloud collaboration service authorization that does not include the device's contact identity, and sends the service qualification certificate along with the external collaboration request. The relay service performs service qualification verification, external collaboration invocation, and usage metering based on the cloud collaboration account identity and the service qualification certificate. The relay service completes the service qualification verification based on the service qualification certificate itself or its verifiable content, without needing to look up the record corresponding to the device's contact identity based on the cloud collaboration account identity. After completing the service qualification verification, the relay service does not save the service qualification certificate as a long-term association key between the cloud collaboration account identity and the device's contact identity, and uses the unified upstream identity on the relay service side to access the external collaboration service, so that the data sent to the external collaboration service does not include the device's contact identity. The relay service sends the result returned by the external collaboration service to the cloud collaboration account session that initiated the external collaboration request, and records the corresponding usage information in the cloud collaboration service domain based on the cloud collaboration account identity.

2. The method according to claim 1, characterized in that, The creation authorization information is a one-time credential, time-limited credential, or other authorization data issued by the device management domain and independently verifiable by the cloud collaboration service domain, used only for verifying the eligibility of creating a cloud collaboration account.

3. The method according to claim 1, characterized in that, The cloud collaboration account identity consists of an account identifier and account control information generated locally by the smart device. The account control information is used to prove control over the cloud collaboration account identity.

4. The method according to claim 1, characterized in that, The device management domain and the cloud collaboration service domain use independent identifier spaces. The device management domain stores service authorization status and cloud collaboration account lifecycle information using the device contact identity as the primary key, and the cloud collaboration service domain stores service records using the cloud collaboration account identity as the primary key. There are no query fields or interfaces between the two for directly querying the device contact identity from the cloud collaboration account identity.

5. The method according to claim 1, characterized in that, In response to the smart device completing the authorization update on the device side and obtaining the updated cloud collaboration service authorization, the smart device updates the locally stored authorization status; When the smart device subsequently initiates an external collaboration request, the smart device generates an updated service qualification certificate based on the updated cloud collaboration service authorization, and the relay service updates the service status corresponding to the current cloud collaboration account identity after verifying the updated service qualification certificate. The updated service qualification certificate does not include the device contact identity, and after the verification and service status update are completed, it is not stored as a long-term association key between the cloud collaboration account identity and the device contact identity.

6. The method according to claim 1, characterized in that, The relay service includes a primary relay service and a backup relay service. When the primary relay service is unavailable, the smart device or the relay service will switch the external collaboration request to the backup relay service, and the backup relay service will continue to perform service qualification verification and usage metering based on the cloud collaboration account identity.

7. The method according to claim 1, characterized in that, When the relay service accesses externally, it uses a unified upstream identity, making the relationship between the device contact identity and the cloud collaboration account identity invisible to the external collaboration service.

8. The method according to claim 1, characterized in that, In response to a user's cloud collaboration account cancellation request initiated on the smart device side, the smart device submits a cancellation status request corresponding to the device contact identity to the device management domain, and the device management domain updates the cloud collaboration account lifecycle information corresponding to the device contact identity; simultaneously, the smart device holding the account control information submits a cancellation request confirmed by the account control information to the cloud collaboration service domain, and the cloud collaboration service domain deletes or invalidates the service record corresponding to the cloud collaboration account identity after verification.

9. A device communication identity and cloud collaboration account domain-based transfer and usage metering system for external collaboration of smart devices, characterized in that, This includes smart devices, a device management domain, a cloud collaboration service domain, a relay service, and external collaboration service interfaces. The device management domain stores device contact identity, service authorization status, and cloud collaboration account lifecycle information. When creation is permitted, it generates creation authorization information that does not include the device contact identity or the identity of the cloud collaboration account to be created, without storing the specific cloud collaboration account identity. The smart device generates a cloud collaboration account identity distinct from the device contact identity locally, stores the local authorization status, updates the local authorization status after authorization updates, and forms a service qualification certificate without the device contact identity based on the current cloud collaboration service authorization. The cloud collaboration service domain registers the cloud collaboration account identity after verifying the creation authorization information, and stores service records and service status based on the cloud collaboration account identity. The system and usage records generated by the relay service do not store a direct reverse lookup mapping between the cloud collaboration account identity and the device contact identity, and after registration, the creation authorization information is not stored as a long-term association key between the cloud collaboration account identity and the device contact identity; the relay service is used to complete external collaborative calls, service qualification verification and usage metering based on the cloud collaboration account identity and the service qualification certificate, and completes service qualification verification based on the service qualification certificate itself or its verifiable content without reverse lookup of the record corresponding to the device contact identity based on the cloud collaboration account identity, and after completing the service qualification verification, the service qualification certificate is not stored as a long-term association key between the cloud collaboration account identity and the device contact identity, and the unified upstream identity is used to access external collaborative services.

10. An electronic device or computer-readable storage medium, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program, or the computer-readable storage medium storing a computer program; when the computer program is executed by the processor, it implements the method according to any one of claims 1 to 8.

Images