Communication method, apparatus and system

Abstract

A communication method, apparatus and system, capable of improving the security of a communication system. The method comprises: acquiring an authorization identifier, wherein the authorization identifier is used for identifying intention auxiliary information of a fourth communication apparatus; and sending a first message to the fourth communication apparatus, wherein the first message comprises the intention auxiliary information, the intention auxiliary information is borne in the authorization identifier for the first message or an access token or a one-time credential, and the intention auxiliary information is used for verifying the authorization of the fourth communication apparatus.

Description

Communication method, device and system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on March 21, 2024, with application number "202410331913.5" and invention name "Communication Method, Device and System", the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a communication method, device and system. Background Art

[0003] With the development of artificial intelligence (AI) technology, networks can accurately recognize and understand user voice and text messages, providing more intelligent services. However, this can lead to security risks in some situations. For example, an attacker could misinterpret user intent and cause the server to execute the wrong service. Preventing networks from misidentifying user intent and mitigating system security risks are urgent issues to address. Summary of the Invention

[0004] The present application provides a communication method, device, and system that can reduce security risks of the system.

[0005] In order to achieve the above objectives, the embodiments of the present application provide the following technical solutions:

[0006] In the first aspect, the present application provides a communication method, applied to a first communication device, the method comprising: obtaining an authorization identifier; the authorization identifier is used to identify intention auxiliary information of a fourth communication device; sending a first message to the fourth communication device, the first message including the intention auxiliary information, the intention auxiliary information being carried in the authorization identifier or access token or one-time credential of the first message, and the intention auxiliary information being used to verify the authorization of the fourth communication device.

[0007] In this application, the access token may be referred to as a token for short.

[0008] This application verifies the authorization of the fourth communication device using the authorization identifier and the auxiliary intent information to determine whether the fourth communication device requesting the service is authorized to initiate the service. Only when it is determined that the user has triggered an intent requiring authorization, such as a purchase, is the fourth communication device authorized, allowing it to complete the service based on the authorization, thereby improving system security.

[0009] For example, this method can be applied to scenarios where a terminal calls an intent service to implement a corresponding service. For example, in scenario 1, an intent assistant (or AI assistant) opens the door for user B at a specified time based on the terminal's intent. Another example is scenario 2, where a shopping intent service completes a purchase on a third-party platform based on the terminal's intent.

[0010] In one possible design, obtaining the authorization identifier includes:

[0011] receiving first information, the first information including contract information of a terminal or second information; the contract information is used to indicate whether the terminal subscribes to an intended service and / or indicates a range of intended services subscribed by the terminal; the second information is determined based on the contract information;

[0012] The authorization identifier is determined according to the first information.

[0013] In one possible design, the intention auxiliary information is carried in the authorization identifier and further includes:

[0014] The intention auxiliary information is stored.

[0015] In one possible design, obtaining the authorization identifier includes:

[0016] An authorization identifier is received from a third communication device.

[0017] In one possible design, the intention auxiliary information is stored in the third communication device, and before receiving the authorization identifier from the third communication device, the method further includes:

[0018] The intention assistance information is sent to the third communication device.

[0019] Exemplarily, the NIAF sends the terminal's identification and intention auxiliary information to the UDM, and obtains the corresponding authorization identification from the UDM.

[0020] In one possible design, it also includes:

[0021] receiving a verification request from a second communication device; the verification request is used to verify the consistency of the service information generated by the second communication device and the intention auxiliary information, the verification request including the authorization identifier and the service information;

[0022] Return verification information, where the verification information is used to indicate a verification result of the consistency between the service information and the intention auxiliary information.

[0023] In a possible design, before returning the verification information, it also includes:

[0024] sending the authorization identifier and the service information to a third communication device;

[0025] Receive verification information determined by the third communication device based on the authorization identifier and the service information.

[0026] For example, if a terminal expresses an intention to purchase something, the system queries and calls related intent services (such as ordering food, shopping, and booking tickets) based on this intent. The system also generates auxiliary information related to the user's communication intent (such as the time, location, location preference for ordering food / the platform for shopping, the list of items, the budget, and the time / time and location for booking tickets). After the user confirms the auxiliary information, the system instantiates the intent based on the intent authorization template. The intent service triggers the third-party platform to provide the purchase service. The third-party platform verifies the consistency between the auxiliary information and the service information. Upon successful verification, the service is completed and the user is notified.

[0027] In a possible design, before returning the verification information, it also includes:

[0028] The verification information is determined based on the authorization identifier and the service information.

[0029] In one possible design, it also includes:

[0030] receiving a first request from the fourth communication device; the first request including the intention auxiliary information and the authorization identifier; the first request being used to request consistency between the received intention auxiliary information and the locally stored intention auxiliary information corresponding to the authorization identifier;

[0031] Verifying, according to the first request, the consistency of the received intention auxiliary information with the locally stored intention auxiliary information corresponding to the authorization identifier;

[0032] Sending a first message to the fourth communication device includes:

[0033] If the received intention auxiliary information is consistent with the locally stored intention auxiliary information corresponding to the authorization identifier, the first message is sent to the fourth communication device, and the first message includes the consistent intention auxiliary information; the consistent intention auxiliary information is carried in the token of the first message or the one-time credential.

[0034] In one possible design, it also includes:

[0035] Obtain the token or the one-time credential.

[0036] In one possible design, obtaining the token or the one-time credential includes:

[0037] The access token or the one-time credential is generated.

[0038] Exemplarily, xxF\NRF receives the terminal identification and intent auxiliary information sent by NIAF and may record the intent auxiliary information. xxF\NRF may also receive a token request (which includes the intent auxiliary information), verify the consistency between the locally stored intent auxiliary information and the received intent auxiliary information, and generate an access token accordingly.

[0039] For example, NIAF generates an authorization certificate containing the intent auxiliary information and sends the authorization certificate containing the intent auxiliary information to the intent service.

[0040] In one possible design, obtaining the access token or the one-time credential includes:

[0041] The access token or the one-time credential is received from a fifth communication device.

[0042] For example, NIAF applies for the certificate of intent auxiliary information from xxF\NRF and sends it to the intent service

[0043] In one possible design, it also includes:

[0044] Deleting the intention auxiliary information;

[0045] Or send indication information to the third communication device, where the indication information is used to instruct the third communication device to delete the intention auxiliary information.

[0046] In a second aspect, a communication method is provided, which is applied to a fourth communication device, and the method includes: receiving a first message; the first message includes authorization information, and the authorization information includes: intention auxiliary information and / or an authorization identifier corresponding to the intention auxiliary information; the authorization identifier is used to identify the intention auxiliary information; the intention auxiliary information is used to verify the authorization of the fourth communication device; and sending a service request to the second communication device, and the service request includes the authorization information.

[0047] In one possible design, the authorization information is intention-assisted information and further includes:

[0048] A first request is sent to a first communication device, where the first request includes the intention assistance information and the authorization identifier.

[0049] For example, the intent service receives a service request, applies for credentials (token or one-time credentials) from xxF\NRF\NIAF, and uses the credentials to initiate a service request to the third-party platform.

[0050] According to a third aspect, a communication method is provided, which is applied to a second communication device, the method comprising: receiving a service request from a first communication device, the service request comprising the authorization information; the authorization information comprising: intention auxiliary information or an authorization identifier corresponding to the intention auxiliary information; the authorization identifier is used to identify the intention auxiliary information; the authorization information is used to verify the authorization of a fourth communication device; generating service information based on the service request; and executing the service corresponding to the service information when the service information is consistent with the intention auxiliary information.

[0051] In one possible design, it also includes:

[0052] Sending a verification request; the verification request is used to verify the consistency of the service information generated by the second communication device and the intention auxiliary information, the verification request including the authorization identifier and the service information;

[0053] Verification information is received, where the verification information is used to indicate a verification result of consistency between the service information and the intended auxiliary information.

[0054] Exemplarily, the third-party platform receives the PLMN and authorization ID, sends the authorization ID, intent assistance information, and credentials (token or one-time credentials) to the NIAF\xxF\NRF, and obtains verification information.

[0055] In one possible design, the service request includes the intention auxiliary information and further includes:

[0056] Verify the consistency between the service information and the intention auxiliary information.

[0057] In a fourth aspect, the present application provides an apparatus comprising a functional module for executing a method in any possible design of any of the above aspects of the present application, wherein the module may be implemented by software or hardware, or a combination of software and hardware, such as a processing unit and a communication unit.

[0058] In a fifth aspect, the technical solution of the present application provides a communication device, comprising: a processor, configured to execute any method of any design in any of the above aspects.

[0059] Optionally, the device further includes the memory and / or communication interface.

[0060] The communication interface is coupled to the processor, and is used to input and / or output information.

[0061] The memory is used to store computer programs, and the processor is configured to execute any of the above-mentioned methods of any design, which can be implemented as: executing the computer program stored in the memory to execute any of the above-mentioned methods of any design.

[0062] Alternatively, the processor may be a hardware-implemented circuit, such as an artificial intelligence (AI) processor, to increase operating speed. This application does not limit the specific implementation of the processor.

[0063] Optionally, the communication device may be a complete device, or a module in the device, such as a chip.

[0064] In a sixth aspect, the technical solution of the present application provides a computer-readable storage medium, including computer instructions. When the computer instructions are executed on a device, the device executes any possible design method in any of the above aspects.

[0065] In a seventh aspect, the technical solution of the present application provides a computer program product, which, when running on a device, enables the device to execute any possible design method in any of the above aspects.

[0066] In an eighth aspect, a circuit system is provided, comprising a processing circuit configured to perform the method of any possible design of any of the above aspects. The processing circuit may be implemented as a corresponding circuit component, such as one or more processors. Another example is a processor and memory. Another example is a processor and a transceiver.

[0067] In a ninth aspect, the technical solution of the present application provides a communication system, which includes at least two of the first communication device, the fourth communication device, and the second communication device in any possible design of any of the above aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] Figures 1 and 2 are schematic diagrams of a communication system provided in an embodiment of the present application;

[0069] FIG3 is a schematic diagram of a communication device provided in an embodiment of the present application;

[0070] Figures 4 to 11 are flow charts of a communication method provided in an embodiment of the present application;

[0071] FIG12 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

[0072] FIG13 is a schematic structural diagram of another communication device (such as a chip) provided in an embodiment of the present application. DETAILED DESCRIPTION

[0073] An embodiment of the present application provides a communication method, which can be applied to a fifth generation mobile network (5G), a sixth generation mobile network (6G), or other mobile communication systems. For example, an example of a network architecture involved in an embodiment of the present application is shown in FIG1 . The system includes a terminal, an access network (AN) device, an access and mobility management function (AMF) network element, a unified data management (UDM) network element, a network exposure function (NEF) network element, a network storage function (NRF) network element, an artificial intelligence generated content network function (AIGC-NF), a network intelligent agent function (NIAF), an intent authorization function (such as denoted as xxF), a server, and some network elements not shown, which are not specifically limited in the embodiment of the present application.

[0074] The devices shown in Figure 1 can communicate with each other using corresponding connection methods. For example, the terminal device can access the network through the access network device of the access network (AN). The access network includes but is not limited to the radio access network (RAN). The access network device communicates with the AMF network element through the N2 interface (not shown in the figure), and the UPF network element accesses the data network through the N6 interface (not shown in the figure).

[0075] Figure 1 only shows the connection mode between some network elements, and these network elements can also communicate with each other through other modes. In addition, the connection mode between other network elements can refer to the relevant technology, and the embodiment of the present application does not limit this. For example, the AMF network element communicates with the SMF network element through the N11 interface (not shown in the figure), and the AMF network element communicates with the UDM network element through the N8 interface (not shown in the figure).

[0076] Optionally, the terminal devices involved in the embodiments of the present application may include various handheld devices with wireless communication functions, vehicle-mounted devices, wearable devices, computing devices, or other processing devices connected to a wireless modem; and may also include a subscriber unit, a cellular phone, a smart phone, a wireless data card, a personal digital assistant (PDA), a tablet computer, a wireless modem, a handheld device, a laptop computer, a cordless phone, or a wireless local loop (WLL) station, a machine type communication (MTC) terminal device, a user equipment (UE), a mobile station (MS), or a relay user device. Among them, the relay user device may be, for example, a 5G residential gateway (RG). For the convenience of description, in the embodiments of the present application, the above-mentioned devices are collectively referred to as terminal devices.

[0077] Optionally, the access network device involved in the embodiments of the present application refers to the medium for the terminal device to access the core network. The access network device may be, for example, a 3rd generation partnership project (3GPP) access network device, such as the next generation radio access network (NG-RAN) device in the 5G network, the evolved universal terrestrial radio access network (E-UTRAN) device in the 4G network, a base station, etc. The base station may include various forms of base stations, such as: macro base stations, micro base stations (also called small stations), relay stations, access points, etc. The terminal device accesses the core network through the 3GPP access network device, which can be called a 3GPP access method. In this way, the terminal device can communicate with the core network device.

[0078] The access network device may also be a non-3GPP access network device, such as a non-3GPP interworking function (N3IWF) entity, a non-3GPP access point (AP), etc. Access points include but are not limited to routers, optical modems, etc.

[0079] The terminal device accessing the core network through a non-3GPP device is called a non-3GPP access mode. The embodiment of the present application is not limited to the form of the access network device, such as a broadband network gateway (BNG) or a convergence switch.

[0080] AIGC-NF can provide relevant parameters for intent services. For example, if the user's intention is to shop, NIAF can query AIGC-NF for the access address (such as the server access address), call parameters, output format, and other information of the intent service corresponding to the shopping intention, so as to call the intent service to generate intention auxiliary information.

[0081] AIGC-NF can also communicate with the server to call the server's capabilities to implement services such as shopping.

[0082] The server provides services tailored to the user's intent. This server can be the operator's server or a third-party server. In shopping scenarios, in some examples, NIAF can initiate a service request to the shopping platform via AIGC-NF based on the user's intent, and the shopping platform can then implement the shopping service.

[0083] Figure 1 uses the deployment of AIGC-NF within the core network as an example. The AIGC-NF can communicate with third-party platforms (servers) via the NEF, and the third-party platforms can communicate with devices within the core network via the NEF. It should be noted that Figure 1 is merely a schematic diagram of the communication system architecture of this embodiment of the present application. Of course, the system architecture can also be other, such as the future 6G network architecture, including more or fewer devices, and this embodiment does not specifically limit this.

[0084] For example, Figure 2 shows another architecture example. Unlike Figure 1, where the AIGC-NF is deployed within the core network, in Figure 2, the AIGC-NF is deployed outside the core network. In this architecture, the AIGC-NF and NIAF can communicate through the NEF. Third-party platforms can also communicate with devices within the core network through the NEF.

[0085] Through this system, users can drive third-party platforms to provide services to users, complete intended service operations such as procurement, and ensure the security of the system.

[0086] This embodiment only describes the intent service scenario for a single network element. However, the intent service may exist as a platform, operating with the cooperation of multiple network functions and functional entities. In this case, the authorization voucher will circulate repeatedly within the intent service platform before ultimately being sent to a third-party platform. The third-party platform can use information such as the PLMN in the voucher to locate the NEF on the 5GC network and request authorization verification. Furthermore, the NEF authorization mechanism also supports the CAPIF architecture, where the authorization network element can be the CCF, rather than the NRF or UDM.

[0087] It should be noted that the names of the network elements and the interfaces between the network elements in Figure 1 are only an example. In the specific implementation, the names of the network elements and the interfaces between the network elements may be other, such as the names of the network elements in the 6G network and the interface names between the network elements in the 6G network. The embodiments of the present application do not make specific limitations on this.

[0088] In the embodiment of the present application, when it is mentioned that A sends a message to B, A may send it directly to B, or A may forward it to B through other devices. The other device forwards the message to B, which may be forwarded directly or after processing.

[0089] It should be noted that the message names between the various network elements and the names of the parameters in the messages in the following embodiments of this application are only examples. Other names may be used in specific implementations, and this embodiment of the application does not specifically limit this. For example, the analytics ID in the first message may also have other names.

[0090] The following describes the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. In the description of this application, unless otherwise specified, " / " represents the meaning of "or." For example, A / B can represent A or B. "And / or" in this document is merely a description of an association relationship between associated objects, indicating that three relationships can exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, and B exists alone. Furthermore, in the description of this application, unless otherwise specified, "plurality" means two or more than two. Furthermore, to facilitate the clear description of the technical solutions in the embodiments of the present application, the words "first" and "second" are used in the embodiments of the present application to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity or order of execution, and that words such as "first" and "second" do not necessarily define differences.

[0091] In addition, the network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0092] For example, various communication devices in the embodiments of the present application can be implemented by the communication device in Figure 3. Figure 3 shows a schematic diagram of the hardware structure of the communication device provided in the embodiments of the present application. The communication device 400 includes at least one processor 401, a memory 403, and at least one communication interface 404.

[0093] The processor 401 may be a central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0094] Optionally, the communication device may include a communication line, which may include a path for transmitting information between corresponding components of the device.

[0095] The communication interface 404 uses any transceiver or other device for communicating with other devices or communication networks, such as Ethernet, RAN, wireless local area networks (WLAN), etc.

[0096] The memory 403 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program codes in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor via a communication line. The memory may also be integrated with the processor.

[0097] The memory 403 is used to store computer-executable instructions for executing the solution of the present application, and the execution is controlled by the processor 401. The processor 401 is used to execute the computer-executable instructions stored in the memory 403, thereby implementing the method provided by the embodiment of the present application.

[0098] Optionally, the computer-executable instructions in the embodiments of the present application may also be referred to as application code, which is not specifically limited in the embodiments of the present application.

[0099] In a specific implementation, as an embodiment, the processor 401 may include one or more CPUs, such as CPU0 and CPU1 in FIG. 3 .

[0100] In a specific implementation, as an embodiment, the communication device 400 may include multiple processors, such as the processor 401 and the processor 408 in FIG3 . Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0101] The structure shown in Figure 3 is merely an example. The communication device may include more or fewer components, or other component layouts, and is not limited thereto. For example, the communication device may include a processor, which may be implemented in hardware or by calling a program. Alternatively, the communication device may include a processor and memory. Alternatively, the communication device may include a processor and a communication interface.

[0102] The communication device 400 may be a general-purpose device or a dedicated device. The embodiment of the present application does not limit the type of the communication device 400.

[0103] The communication method provided in the embodiments of the present application will be described in detail below.

[0104] First, a communication system is applied to the network architecture shown in FIG. 1 or FIG. 2 , as shown in FIG. 4 , and a communication method provided in an embodiment of the present application includes the following steps:

[0105] S101: A first communication device receives a first request.

[0106] Exemplarily, the first communication device is NIAF, or NRF, or intent authorization function, or the first communication device can be a component (such as a chip) in the above device, which is not limited in the embodiment of the present application.

[0107] The first request is used to request associated information of the first intention, and the associated information is used to indicate the first intention of the terminal to use the first service provided by the second communication device; the associated information includes intention auxiliary information of the first intention, and the intention auxiliary information is used to verify whether the service information is consistent with the service information of the first service; or the associated information is verification information indicating whether the intention auxiliary information is consistent with the service information of the first service.

[0108] In the embodiment of the present application, the verification information may also be referred to as intent authorization information or other names.

[0109] Intent-assisted information, also known as intent information or by other names, can be instantiated by the AIGC-NF based on the user's intent in some embodiments to generate intent-assisted information. Alternatively, the AIGC-NF can instantiate the user's intent using an intent template. An intent template can also be called an intent authorization template.

[0110] Exemplarily, the format of the intent template is: [business type, business operation, authorization time, scenario (name, time, [supplementary information])].

[0111] Among them, the business type can be, for example, purchasing tickets for a tourist attraction, reserving a table, etc. The business operation can be, for example, purchasing tickets, reserving a table, etc. The authorization time can be, for example, the time when the user has the intention. The name in the scene can be, for example, the name of the tourist attraction, the name of the restaurant, the name of the shopping platform, etc. The time in the scene can be, for example, the time of sightseeing, the time of dining, the time of shopping, etc. The supplementary information in the scene can be, for example, the specific location of the restaurant (such as the atrium / window), the shopping list, etc.

[0112] The service information is information representing the first service generated by the server. In some embodiments, the server may generate corresponding service information according to a service request initiated by the AIGC-NF.

[0113] For example, if user A intends to purchase tickets for Attraction A between December 2nd and 4th at 10:00 AM, the auxiliary intent information instantiated by the intent template might be: [001 Attraction Ticket Purchase, 001 Ticket Purchase, December 1st 10:00, (Attraction A, December 2nd-4th 10:00)]. The service information generated by the server might be: [001 Attraction Ticket Purchase, 001 Ticket Purchase, December 1st 10:00, (Attraction A, December 2nd 10:00)].

[0114] For example, if user B's intention is to reserve a seat in the atrium at restaurant A on December 2nd at 12:00, the instantiated auxiliary information for the intent is: [002 Reserve a table, 002 Reserve a table, 12.1 10:00, (A, 12.2 12:00, Atrium)]. The instantiated service information is: [002 Reserve a table, 002 Reserve a table, 12.1 10:00, (A, 12.2 12:00, X)], where X represents the atrium.

[0115] For example, if user C's intention is to purchase the ingredients for curry chicken (chicken, curry, onions, potatoes) before 5:30 PM, the instantiated intent auxiliary information can be: [003 Shopping List, 003 Shopping, 12.1 10:00, (xx Supermarket, 12.2 before 5:30 PM, Ingredients List (chicken, curry, onions, potatoes))]. The service information can be: [003 Shopping List, 003 Shopping, 12.1 10:00, (xx Supermarket, 12.2 5:30 PM, Ingredients List (xx chicken, xx curry, xx onions, xx potatoes))].

[0116] S102: The first communication device sends associated information of the first intention to the second communication device according to the first request.

[0117] Exemplarily, the second communication device may be a server or a component in a server. The embodiment of the present application does not limit the implementation form of the second communication device.

[0118] If the auxiliary intent information of the first intent is consistent with the service information of the first service, it means that the first service is the service that the terminal user actually wants to use. Conversely, if the auxiliary intent information of the first intent is inconsistent with the service information of the first service, it means that the first service is not the service that the terminal user actually wants to use.

[0119] For example, in a scenario where the first communication device is NIAF and the second communication device is a third-party ticket purchasing server, user A tells user B during a voice call that they want to purchase tickets for Attraction A between December 2nd and 4th, 10:00 AM. The communication system identifies user A's intent and determines that the instantiated intent auxiliary information is: [001 Attraction Ticket Purchase, 001 Ticket Purchase, 12.1 10:00, (Attraction A, 12.2-12.4 10:00)]. The AIGC-NF then initiates a ticket purchase service request to the server. Based on the ticket purchase service request, the server generates service information: [001 Attraction Ticket Purchase, 001 Ticket Purchase, 12.1 10:00, (Attraction A, 12.2 10:00)]. The server sends a verification request (an example of the first request) to NIAF, requesting verification of the consistency between the service information for the ticket purchase service and user A's intent auxiliary information. After NIAF verifies that the service information for the ticket purchase service is consistent with User A's auxiliary information, indicating that the ticket purchase service is what User A actually wants. NIAF can then grant the server permission to execute the ticket purchase service. As one possible implementation, NIAF returns association information to the server, indicating the consistency between the service information for the ticket purchase service and User A's auxiliary information. Based on this association information, the server can obtain permission to purchase tickets for Attraction A and execute the ticket purchase service.

[0120] For example, AIGC-NF initiates a ticket purchase request to the server. Based on the request, the server generates the following service information: [001 Attraction Ticket Purchase, 001 Ticket Purchase, 12.1 10:00, (Attraction B, 12.2 10:00)]. In this example, the service information for the ticket purchase service is inconsistent with user A's intended auxiliary information, indicating that purchasing Attraction B tickets is not the service user A intended. This suggests that AIGC-NF may be maliciously attempting to purchase tickets. In this case, NIAF does not grant the server permission to execute the Attraction B ticket purchase request. This prevents security risks caused by executing unsafe services and improves system security.

[0121] The authorization verification method for the system-third-party platform docking scenario provided in the embodiments of this application can verify the consistency of service information and intention-assisted information to determine whether the service requested is the service the user actually wants to achieve. Only when it is determined that the user has triggered an intention that requires authorization, such as a purchase, is the corresponding associated information generated based on the user's intention, and the third-party platform is authorized so that the third-party platform can complete the service based on the authorization, which can improve system security.

[0122] The following describes different implementations of the above method. For example, in a scenario where user A wants to make a purchase during a call, the first communication device is a NIAF, and the second communication device is a payment platform (or shopping platform) server, FIG5 illustrates an example implementation. In FIG5 , the associated information is verification information, and the first request is a verification request. As shown in FIG5 , the method may include:

[0123] S201: Terminal A and terminal B establish a call connection.

[0124] For example, user A uses terminal A, and user B uses terminal B.

[0125] As a possible implementation manner, terminal A establishes a multimedia communication session (such as a voice or video call) with terminal B, and activates the intention communication function at the beginning or during the call to add the NIAF to the session.

[0126] Terminal A sends multimedia communication content to terminal B, which may include a specific communication intent, such as inviting user B to travel to a certain place or purchasing clothing, jewelry, or game props for user B. Optionally, this intent can be implicitly expressed in the communication content between the terminals in the form of unstructured data, such as natural language or text, or explicitly expressed in a specific structured data form, such as a predefined intent message format. This embodiment of the present application does not limit the format of the intent representation.

[0127] S202: NIAF identifies the intention of user A of terminal A.

[0128] As a possible implementation, NIAF obtains intent-related information from the conversation. For example, it obtains explicit / structured or implicit / unstructured intent-related information to identify user A's intent. Another example is to obtain conversation context from historical conversation data over a period of time to assist in intent recognition.

[0129] In some embodiments, NIAF can also call AI algorithm engines, external resources or services (such as web search, semantic knowledge base, etc.) to improve the accuracy of intent recognition.

[0130] In some embodiments, intent recognition may also include two-way interaction between the NIAF and the terminal, such as using intelligent question-answering methods and prompt mechanisms in AI models to communicate with users to improve the accuracy of intent recognition.

[0131] For example, in Scenario 1, the conversation between user A and user B includes the following: User A: "Come over to my house on Sunday." User B: "Sure, I'll be there around 9:00." User A: "OK, just push the door open when you're ready. I'll have the intent assistant hold the door open for you." In this example, NIAF recognizes user A's intent: User B will arrive around 9:00 on Sunday, and opens the door for User B.

[0132] For example, in scenario 2, the conversation between user A and user B includes the following: User A: "I saw a beautiful dress of style xx online. How about giving it to you as a birthday gift?" User B: "I've gained weight recently and changed my hairstyle. I'm afraid it won't fit." User A: "No problem. I'll send it to you. See if it's suitable." User B: "It looks great. I want it." User A: "Great!" In this example, NIAF identifies user A's intent as purchasing style xx.

[0133] S203. NIAF queries parameters of the registered intent service corresponding to the intent of user A based on the identified intent of user A.

[0134] As a possible implementation method, NIAF sends a query request or query notification or query indication to AIGC-NF to query the parameters of the intent service corresponding to user A's intention (such as the above-mentioned shopping intention).

[0135] Optionally, the parameters of the intent service include, but are not limited to, an access method and / or an output format of the intent auxiliary information. The access method can be indicated by, for example, an access address of the intent service, a call parameter, and the like.

[0136] S204. NIAF receives parameters of the intent service corresponding to user A's intent.

[0137] Exemplarily, NIAF receives the parameters of the intent service from AIGC-NF. For example, for the above scenario 2, NIAF can obtain the access method and output format of the intent service corresponding to the shopping intent.

[0138] S205: NIAF sends a request A to AIGC-NF. Request A is used to request generation of intention auxiliary information (intent information) corresponding to user A's intention.

[0139] As a possible implementation, NIAF sends a request A using parameters of the intent service (such as the access address) to invoke the intent service provided by AIGC-NF and generate intent auxiliary information corresponding to the intent of user A. Optionally, request A includes the intent of user A.

[0140] Optionally, NIAF can also query the network (such as base stations and other devices) for the device information of terminals A and B involved in the conversation. Device information includes but is not limited to terminal type and / or terminal capabilities. Device information can be used to adapt the subsequently generated intent-assisted information accordingly. For example, if terminal A used by user A is a mobile phone that can receive multimedia information in a flat vertical screen format, and terminal B used by user B is a VR headset that can receive panoramic 360 and 3D multimedia information. Optionally, request A can also include this device information.

[0141] Optionally, NIAF can also query the network for authorized user information corresponding to User A and User B. User information includes the user's digital human information, which includes but is not limited to the digital human's identification and image. Optionally, Request A can also include this user information.

[0142] Optionally, NIAF may also access other external services or resources, such as web search, websites, semantic knowledge bases, etc., to obtain information corresponding to the intent, such as similar semantics, related multimedia materials, etc. Optionally, request A may also include information related to the intent.

[0143] S206. AIGC-NF returns the intention auxiliary information (intent information) corresponding to the intention of user A to NIAF.

[0144] Accordingly, NIAF obtains intention assistance information from AIGC-NF.

[0145] As a possible implementation, after receiving request A, AIGC-NF invokes the intent service corresponding to user A's intent (e.g., shopping intent service) based on the intent. Using the corresponding intent template, AIGC-NF instantiates user A's intent to generate auxiliary intent information. For example, in scenario 1, AIGC-NF invokes the door-opening intent service. In scenario 2, AIGC-NF invokes the shopping intent service.

[0146] Optionally, AIGC-NF can combine user A’s digital human image, device information, etc. to generate intention auxiliary information.

[0147] S207: NIAF determines user A's intention.

[0148] As one possible implementation, NIAF sends the aforementioned auxiliary information to Terminal A, which then confirms the auxiliary information. For example, after receiving the auxiliary information regarding a shopping intention, Terminal A may display the associated content corresponding to the auxiliary information, and User A may confirm the shopping intention through, for example, interface operations.

[0149] In one or more embodiments of the present application, S201-S207 are optional steps, or can be replaced by other steps, as long as the intention of user A can be determined based on the replaced steps.

[0150] S208: NIAF initiates an authorization request to UDM. Correspondingly, UDM receives the authorization request from NIAF.

[0151] Optionally, the authorization request includes an identifier (ID) of terminal A. Optionally, the terminal identifier includes, but is not limited to, any of the following: a subscription permanent identifier (SUPI), an international mobile subscriber identity (IMSI), or a temporary ID.

[0152] Optionally, the authorization request may further include at least one of the following information: intent assistance information, intent service information, or AIGC-NF information. AIGC-NF information may include, for example, the identifier of the NF instance, the NF type, or the range of the NF instance identifier. Intent service information may include, for example, the identifier of the intent service.

[0153] S209. UDM returns information A to NIAF. Information A is used to indicate the authorization result corresponding to terminal A.

[0154] In some embodiments, the UDM queries the subscription information of terminal A based on the identifier of terminal A. This subscription information may indicate whether terminal A has subscribed to or signed up for the intended service. Based on terminal A's subscription information, the UDM may indicate the authorization result of terminal A to the NIAF. In some embodiments, if terminal A has subscribed to the intended service, the UDM determines to authorize terminal A. In some examples, the communication system may implement the intention of terminal A if authorized. Conversely, if terminal A has not subscribed to the intended service, the UDM determines not to authorize terminal A. In this case, the communication system will not implement the intention of terminal A that has not been authorized, thereby improving system security.

[0155] In the embodiment of the present application, S209 can be implemented in a variety of ways. Several examples are given below:

[0156] Method 1: Optionally, the authorization request includes the identifier of terminal A and the above-mentioned intention auxiliary information. After receiving the authorization request, UDM determines to authorize terminal A based on the contract information of terminal A. If terminal A has signed the intention service, UDM stores the intention auxiliary information and generates an authorization identifier corresponding to the intention auxiliary information. UDM can return the authorization identifier to NIAF to indicate the authorization result of terminal A. Among them, the intention auxiliary information can be identified by the authorization identifier, which can be, for example, a service identifier, a contract identifier, an event identifier, or other identifiers with equivalent meanings or functions.

[0157] On the contrary, if it is determined not to authorize terminal A based on the contract information of terminal A, the UDM does not store the intention auxiliary information and does not generate a corresponding authorization identifier.

[0158] As a possible implementation manner, the UDM stores the intention auxiliary information in the registration information of the terminal A.

[0159] Method 2: NIAF sends an authorization request to the UDM, which includes Terminal A's identifier and the aforementioned auxiliary intent information. After receiving the authorization request, the UDM queries Terminal A's contract information based on Terminal A's identifier, determines the authorization result for Terminal A based on that information, and returns the authorization result to NIAF. If the authorization result indicates verification passed, meaning Terminal A is authorized, NIAF stores the auxiliary intent information and generates an authorization identifier corresponding to the auxiliary intent information.

[0160] Method 3: NIAF sends an authorization request to UDM, which includes the identifier of terminal A to request the contract information of terminal A. Optionally, the authorization request may also include the scope of the contract information. After receiving the authorization request, UDM queries the contract information of terminal A based on the identifier of terminal A and returns the contract information to NIAF. NIAF determines the authorization result based on the contract information of terminal A. If the authorization result is that authorization is allowed, NIAF records the above-mentioned intention auxiliary information and generates an authorization identifier corresponding to the intention auxiliary information.

[0161] Different from the method 1 in which the UDM generates the authorization identifier, in the methods 2 and 3, when authorization is allowed, the NIAF stores the intention auxiliary information of the terminal A and determines the authorization identifier corresponding to the intention auxiliary information of the terminal A.

[0162] In one or more of the above methods, the integrity and non-tamperability of the authorization identifier can be ensured through client credentials assertion (CCA) or other means.

[0163] In one or more embodiments of the present application, S208 and S209 are optional steps.

[0164] S210. NIAF initiates a purchase request to the server through AIGC-NF.

[0165] Optionally, the purchase request sent by the AIGC-NF to the server includes an authorization identifier. Optionally, the purchase request may also include a public land mobile network (PLMN) ID and the above-mentioned intention auxiliary information.

[0166] S211. The server generates service information according to the purchase request.

[0167] Taking user A's intention to buy clothes of style xx as an example, the service information generated by the server may be: [001 buy clothes, 001 shopping, (style xx)].

[0168] As a possible implementation, the server may search for the NEF according to the PLMN ID, and the NEF may search for the NIAF according to the authorization identifier.

[0169] S101a: The server initiates a verification request for service information to the NIAF. The verification request includes the authorization identifier and the above service information. Optionally, the verification request may also include the ID of terminal A and the ID of the server.

[0170] As a possible implementation manner, the server sends the verification request to the NIAF determined by the NEF.

[0171] S102a. NIAF returns verification information to the server.

[0172] Corresponding to the above-mentioned method 1 (UDM stores intention auxiliary information), as a possible implementation method, after NIAF receives the verification request for service information, it initiates a verification request (an example of the second request) to UDM (an example of a third communication device), and the verification request is used to request verification information. The verification request includes the above-mentioned authorization identifier and service information. UDM can query the intention auxiliary information of terminal A based on the received authorization identifier, verify whether the received service information is consistent with the intention auxiliary information, and return the verification information to NIAF. In this method, UDM records the intention auxiliary information and verifies the consistency between the intention auxiliary information and the service information.

[0173] Corresponding to Methods 2 and 3 above (NIAF stores intent-assisted information), upon receiving a verification request, NIAF can query the locally stored intent-assisted information of Terminal A based on the authorization identifier included in the verification request, verify the consistency between the service information included in the verification request and the local intent-assisted information, and return the verification information to NIAF. In this method, NIAF records the intent-assisted information and verifies its consistency with the service information.

[0174] In one or more embodiments of the present application, the intention auxiliary information is consistent with the service information, which means that the service information conforms to the intention represented by the intention auxiliary information, and the formats of the service information and the intention auxiliary information may be consistent or inconsistent. Taking the intention of user A as an example: to purchase tickets for scenic spot A before 10:00 on December 2-12 4, the intention auxiliary information after instantiation of the intent template may be: [001 scenic spot ticket purchase, 001 ticket purchase, 12.1 10:00, (scenic spot A, 12.2-12.4 10:00)]. The service information generated by the server may be: [001 scenic spot ticket purchase, 001 ticket purchase, 12.1 10:00, scenic spot A, 12.2 10:00]. In this example, the intention auxiliary information indicates that the intention of user A is to purchase tickets for scenic spot A before 10:00 on December 2-12 4. NIAF initiates a purchase request to the server through AIGC-NF, requesting to purchase tickets for scenic spot A before 10:00 on December 2, and the server generates the above service information based on the purchase request. This service information indicates that the requested service is to purchase tickets for Attraction A before 10:00 AM on December 2nd. This service information matches the intent of User A, as indicated by the auxiliary intent information, and is therefore considered consistent with the auxiliary intent information. In this case, the service requested by the AIGC-NF from the server is the service desired by User A.

[0175] For example, NIAF initiates a purchase request to the server through AIGC-NF, requesting tickets for Attraction B before 10:00 AM on December 2nd. The server generates service information based on this purchase request. This service information indicates that the requested service is to purchase tickets for Attraction B before 10:00 AM on December 2nd. This service information does not match User A's intent to purchase tickets for Attraction A, and is therefore considered inconsistent with the auxiliary information related to the intent. In this case, the service requested by AIGC-NF from the server for Attraction B tickets is not the service User A desired.

[0176] Considering that the intent-assisted information is inconsistent with the service information, it indicates that the service requested by the AIGC-NF is not the service the user expects. Therefore, in this case, the NIAF does not authorize the AIGC-NF to prevent the AIGC-NF from triggering the execution of the unexpected service, which could potentially pose a security risk to the system. As a possible implementation, the NIAF returns verification information to the server, indicating a verification failure. This verification failure indicates that the intent-assisted information is inconsistent with the service information. Based on this verification information, the server stops executing the service corresponding to the service information (e.g., the service for purchasing tickets to Attraction B).

[0177] In other cases, after consistency verification, the intent-assisted information and the service information are consistent. NIAF returns verification information to the server, indicating successful verification. Successful verification indicates that the intent-assisted information and the service information are consistent. Based on this verification information, the server executes the service corresponding to the service information (e.g., a service to purchase clothing of style xx). This helps the server obtain authorization based on the verification information (an example of associated information) to execute the corresponding service and meet the user's intent needs.

[0178] S212, the process of deleting intention auxiliary information (intention information).

[0179] Corresponding to the above methods 2 and 3 (NIAF stores intention auxiliary information), NIAF deletes the intention auxiliary information of terminal A after the server completes the above service (such as purchasing service). In this way, the service corresponding to the intention auxiliary information can be prevented from being repeatedly executed, thereby improving security.

[0180] Alternatively, corresponding to the above-mentioned method 1 (UDM stores the intention auxiliary information), after the above-mentioned service (such as purchasing service) is completed, NIAF sends an indication message to UDM, and the indication message is used to instruct UDM to delete the above-mentioned intention auxiliary information.

[0181] Using the above method, the content of the intention expressed by the user can be identified. When the intention auxiliary information of the intention is consistent with the service information, it means that the service corresponding to the service information is the service that the user wants to implement (such as the service of purchasing xx style of clothes). NIAF sends verification information to the server for authorizing the server. The server can execute the service based on the verification information to meet the user's service execution needs.

[0182] Figure 6 shows another example of a method flow. Unlike Figure 5, where the consistency between intent-assisted information and service information is verified and authorized by UDM or NIAF, in Figure 6, the associated information is intent-assisted information. NIAF sends a token carrying intent-assisted information to the server via AIGC-NF, and the server verifies the token to determine the consistency between the intent-assisted information and service information. As shown in Figure 6, the above steps S210-S211 can be replaced by the following steps:

[0183] S301. NIAF sends a purchase request to AIGC-NF.

[0184] Optionally, the request includes an authorization identifier and intent auxiliary information. Optionally, the request may also include a PLMN ID.

[0185] S101b. AIGC-NF sends a token application request to NIAF. The token application request is used to apply for a token from NIAF.

[0186] S101b is an exemplary implementation of the above S101.

[0187] Optionally, the token application request (an example of the first request) includes an authorization identifier and intention auxiliary information. Optionally, the token application request may also include a PLMN ID.

[0188] S102b. NIAF sends a token to AIGC-NF.

[0189] Optionally, the token carries intent auxiliary information.

[0190] S102b is an exemplary implementation of S102.

[0191] In some embodiments, as a possible implementation method, corresponding to the above-mentioned methods 2 and 3, the NIAF queries the locally stored intention auxiliary information based on the authorization identifier included in the token application request. If the intention auxiliary information included in the token application request is consistent with the locally recorded intention auxiliary information, the NIAF writes the consistent intention auxiliary information into the token and sends the token to the AIGC-NF. The AIGC-NF can use this token to initiate a service request (such as a request for a shopping service) to the server. In this way, it can be ensured that the intention auxiliary information carried in the token meets the intention of user A.

[0192] As another possible implementation method, corresponding to the above method 1, NIAF instructs UDM to query the intention auxiliary information. If the intention auxiliary information received by UDM is consistent with the intention auxiliary information recorded locally by UDM, UDM instructs NIAF to write the consistent intention auxiliary information into the token and send the token to AIGC-NF.

[0193] In some other embodiments, if the intent assistance information included in the token application request is inconsistent with the intent assistance information locally recorded by the NIAF, the NIAF does not send the token to the AIGC-NF. The AIGC-NF cannot use the token to initiate a service request.

[0194] In the above example, NIAF sends a token via step S102b. In other embodiments, NIAF generates an authorization identifier and token after S207 and includes the token in the purchase request via step S301. In this case, S101b and S102b are not required.

[0195] S302. AIGC-NF initiates a purchase request to the server.

[0196] Optionally, the purchase request includes the authorization identifier and the above token. Optionally, the purchase request may also include the PLMN ID and the ID of the AIGC-NF.

[0197] S303: The server generates service information according to the purchase request.

[0198] S304. The server verifies the consistency between the service information and the intention auxiliary information (intent information) in the token.

[0199] In some embodiments, the implementation of the server verifying the consistency of service information and intention auxiliary information can refer to the relevant description of NIAF verification consistency, which will not be repeated here.

[0200] In other embodiments, the server initiates a token verification request to the NIAF. The token verification request includes the authorization identifier, service information, and the aforementioned token. Optionally, the token verification request may also include the AIGC-NF ID. The NIAF verifies the consistency between the intent-assisted information and the service information included in the token.

[0201] Using this method, the user's expressed intent can be identified. NIAF sends a token containing the intent's auxiliary information to the server. Based on this token, the server verifies the consistency between the service information and the auxiliary information in the token. Only when the service information is consistent with the auxiliary information does the server execute the corresponding service, mitigating system security risks.

[0202] Figure 7 shows another example of a method flow. Unlike Figure 6, where the NIAF sends a token carrying the intent-assisted information to the server via the AIGC-NF, in Figure 7, the NIAF carries the intent-assisted information in a one-time credential sent to the AIGC-NF. As shown in Figure 7, the above steps S301-S304 can be replaced with the following steps:

[0203] S401. NIAF sends a purchase request to AIGC-NF.

[0204] Optionally, the request includes an authorization identifier and intent auxiliary information. Optionally, the request may also include a PLMN ID.

[0205] S101c. AIGC-NF sends a credential application request to NIAF. The credential application request is used to apply for a one-time credential from NIAF.

[0206] Optionally, the credential application request (an example of the first request) includes an authorization identifier and intention auxiliary information. Optionally, the credential application request may also include a PLMN ID.

[0207] S102c. NIAF sends a one-time certificate to AIGC-NF.

[0208] The above example uses NIAF sending a token via step S102c. In other embodiments, NIAF generates an authorization identifier and a one-time credential after S207 and includes the one-time credential in the purchase request via step S401. In this case, S101c and S102c are not necessary.

[0209] S402. AIGC-NF initiates a purchase request to the server.

[0210] Optionally, the purchase request includes the authorization identifier and the one-time credential. Optionally, the purchase request may also include the PLMN ID.

[0211] S403: The server generates service information.

[0212] S404. The server verifies the consistency between the service information and the intention auxiliary information (intent information) in the one-time credential.

[0213] In some other embodiments, the server initiates a credential verification request to NIAF, the credential verification request including the authorization identifier, service information, and the one-time credential. NIAF verifies the consistency between the intent auxiliary information and the service information included in the one-time credential.

[0214] For other specific implementations of S401-S404, please refer to S301-S304 and will not be repeated here.

[0215] FIG8 shows another example of the method flow. Different from the above examples, in this example, the NRF verifies the consistency between the intention auxiliary information and the service information. As shown in FIG8, the above steps S208-S211 can be replaced by the following steps:

[0216] S501: NIAF sends an authorization request to NRF. Correspondingly, NRF receives the authorization request from NIAF.

[0217] Optionally, the authorization request includes an identifier (ID) of terminal A.

[0218] Optionally, the authorization request may further include at least one of the following information: intent assistance information, intent service information, or AIGC-NF information.

[0219] S502: The NRF returns information B to the NIAF, where the information B indicates the authorization result for the terminal A.

[0220] As a possible implementation method, NRF queries UDM for the contract information of terminal A through the ID of terminal A. If the query is successful, UDM records the intention auxiliary information in the registration information of terminal A and can generate an authorization identifier corresponding to the intention auxiliary information of terminal A.

[0221] As another possible implementation, the NRF sends Terminal A's ID and the aforementioned intent-assisted information to the UDM. Based on Terminal A's ID, the UDM queries Terminal A's contract information and, based on that contract information, feeds the authorization result back to the NRF. If authorization is granted, the NRF records the intent-assisted information and generates a corresponding authorization identifier.

[0222] As another possible implementation, the NRF queries the UDM for the contract information of the terminal A. Based on the contract information, if the verification is successful (ie, authorized), the NRF records the above-mentioned intention auxiliary information.

[0223] S503. NIAF initiates a purchase request to the server through AIGC-NF.

[0224] S504: The server generates service information according to the purchase request.

[0225] Exemplarily, the server searches for the NEF according to the PLMN ID, and the NEF searches for the corresponding NRF according to the authorization indication.

[0226] S101d: The server initiates a verification request for service information to the NRF.

[0227] Optionally, the verification request includes the ID, authorization identifier and service information of terminal A. Optionally, the verification request may also include the ID of the server.

[0228] S102d. The NRF returns verification information to the server.

[0229] As another possible implementation, the NRF stores the intent auxiliary information of terminal A. The NRF may query the intent auxiliary information corresponding to the authorization identifier included in the verification request, verify the consistency between the service information included in the verification request and the intent auxiliary information, and return the verification information to the server.

[0230] As a possible implementation, the UDM stores the intention auxiliary information of terminal A. After the NRF receives the verification request (e.g., recorded as verification request A), it may send a verification request (e.g., recorded as verification request B) to the UDM. The verification request B may include an authorization identifier and service information. The UDM may query the intention auxiliary information corresponding to the authorization identifier included in the verification request B, verify the consistency between the service information included in the verification request B and the intention auxiliary information, and return the verification information to the NRF.

[0231] In some embodiments, if the verification result is successful, the server performs the corresponding service (such as purchasing a service). Conversely, if the verification result is a failure, the server does not perform the service to improve the security of the system.

[0232] Figure 9 shows another example of a method flow. Unlike Figure 8, where the consistency between the intent auxiliary information and the service information is verified and authorized by the UDM or NRF, in Figure 9, the NRF sends a token carrying the intent auxiliary information to the server via the AIGC-NF, and the server verifies the token to determine the consistency between the intent auxiliary information and the service information. As shown in Figure 9, the above steps S503-S102d can be replaced by the following steps:

[0233] S601. NIAF sends a purchase request to AIGC-NF.

[0234] S101e, AIGC-NF sends a token application request to NRF.

[0235] Optionally, the token application request may include an authorization identifier and intention auxiliary information. Optionally, the token application request may include a PLMN ID.

[0236] S102e. NRF returns the token to AIGC-NF.

[0237] Exemplarily, when the intent auxiliary information included in the token application request is consistent with the intent auxiliary information stored in the NRF or UDM, the NRF returns the token to the AIGC-NF.

[0238] S602: The AIGC-NF sends a purchase request to the server. The purchase request includes the token. Optionally, the purchase request includes an authorization identifier and a PLMN ID.

[0239] S603: The server generates service information according to the purchase request.

[0240] S604. The server verifies the consistency between the service information and the intention auxiliary information (intent information) in the token.

[0241] Figure 10 shows another example of the method flow. Unlike Figure 9, where the NRF sends a token carrying the intent-assisted information to the server via the AIGC-NF, in Figure 10, the NRF carries the intent-assisted information in a one-time credential sent to the AIGC-NF. As shown in Figure 10, steps S601-S604 described above can be replaced with the following steps: S701-S704. The specific implementation of steps S701-S704 can be referenced in other embodiments and will not be detailed here.

[0242] Figure 11 shows another example of the method flow. As shown in Figure 11, the method may include:

[0243] S801. The first communication device obtains an authorization identifier; the authorization identifier is used to identify the intention auxiliary information of the fourth communication device.

[0244] Exemplarily, the fourth communication device is the above-mentioned AIGC-NF or a device with similar functions.

[0245] As a possible implementation, obtaining the authorization identifier can be achieved by: receiving first information and determining the authorization identifier based on the first information. The first information is the terminal's contract information or second information (such as the authorization result described above); the contract information is used to indicate whether the terminal subscribes to the intended service or the scope of the intended service subscribed by the terminal; the second information is determined based on the contract information.

[0246] Optionally, the intention auxiliary information is carried in the authorization identifier, and the first communication device can store the intention auxiliary information.

[0247] As another possible implementation, obtaining the authorization identifier may be implemented by receiving the authorization identifier from a third communication device. The intention-assisted information is stored in the third communication device. Prior to receiving the authorization identifier from the third communication device, the method further includes sending the intention-assisted information to the third communication device, whereupon the third communication device generates an authorization identifier corresponding to the intention-assisted information if the intention-assisted information passes verification, and stores the intention-assisted information.

[0248] Verification of the auxiliary intent information may mean that, based on the contract information of terminal A and the auxiliary intent information, if authorization is determined for terminal A, the auxiliary intent information passes verification. For example, if, based on the auxiliary intent information and the contract information, the intention indicated by the auxiliary intent information falls within the scope of the intent service subscribed by terminal A, the auxiliary intent information passes verification.

[0249] For a detailed description of the two methods of obtaining authorization identifiers, please refer to the aforementioned embodiments.

[0250] S802. The first communication device sends a first message to the fourth communication device. The first message includes intention auxiliary information. The intention auxiliary information is carried in the authorization identifier or access token or one-time credential of the first message. The intention auxiliary information is used to verify the authorization of the fourth communication device.

[0251] In one or more embodiments of the present application, information x is carried in y, which can be understood as y explicitly carrying x, or y implicitly indicating x. Taking the example of a first communication device being a NIAF and a fourth communication device being an AIGC-NF, the intent-assisted information can optionally be carried in an authorization identifier. This can be understood as the NIAF sending an authorization identifier to the AIGC-NF, which can indicate the corresponding intent-assisted information. Subsequently, this authorization identifier can be used by devices in the network to determine the corresponding intent-assisted information.

[0252] For example, if the first communication device is a NIAF and the fourth communication device is an AIGC-NF, the NIAF sends an authorization identifier to the AIGC-NF, where the authorization identifier identifies the corresponding intent-related auxiliary information. Alternatively, the NIAF sends a token to the AIGC-NF, where the token carries the corresponding intent-related information. Alternatively, the NIAF sends a one-time credential to the AIGC-NF, where the one-time credential carries the corresponding intent-related auxiliary information.

[0253] In one or more embodiments of the present application, a token can be used multiple times, and a one-time credential can be used only once, such as only used in a certain communication process.

[0254] Optionally, the method may also include: the first communication device receives a verification request from the second communication device; the verification request is used to verify the consistency between the service information generated by the second communication device and the intention auxiliary information, and the verification request includes an authorization identifier and service information; the first communication device returns verification information, and the verification information is used to indicate the verification result of the consistency between the service information and the intention auxiliary information.

[0255] As a possible implementation method, before returning the verification information, it also includes:

[0256] The first communication device sends the authorization identifier and service information to the third communication device; and receives verification information determined based on the authorization identifier and service information from the third communication device.

[0257] As another possible implementation manner, before returning the verification information, the method further includes: the first communication device determining the verification information based on the authorization identifier and the service information.

[0258] For a detailed description of the two methods for determining verification information, please refer to the aforementioned embodiments.

[0259] Optionally, the method may also include: the first communication device receives a first request from the fourth communication device; the first request includes intention auxiliary information and an authorization identifier; the first communication device verifies the consistency between the received intention auxiliary information and the locally stored intention auxiliary information corresponding to the authorization identifier. Accordingly, the above-mentioned first communication device sends a first message to the fourth communication device, including: if the received intention auxiliary information is consistent with the locally stored intention auxiliary information corresponding to the authorization identifier, then sending a first message to the fourth communication device, the first message including consistent intention auxiliary information; the consistent intention auxiliary information is carried in the token or one-time credential of the first message.

[0260] Optionally, the method further includes: obtaining a token or a one-time credential.

[0261] As a possible implementation manner, obtaining a token or a one-time credential includes generating a token or a one-time credential.

[0262] As a possible implementation manner, obtaining the token or the one-time credential includes: receiving the token or the one-time credential from a fifth communication device. Exemplarily, the fifth communication device is an NRF.

[0263] One or more embodiments of the present application may be referenced or used in combination with each other. For example, the explanation of a one-time credential in one embodiment may be applied to another embodiment.

[0264] In one or more embodiments of the present application, the steps performed by the NRF may be replaced by the intent authorization function. For example, the intent authorization function may perform a consistency check on the intent auxiliary information and the service information.

[0265] In one or more embodiments of the present application, the steps performed by the NIAF may be replaced by the ISF. For example, the ISF may perform a consistency check on the intended auxiliary information and the service information.

[0266] It is understandable that the equipment / device in the embodiment of the present application includes a hardware structure and / or software module that performs the corresponding functions in order to realize the above functions. In combination with the units and algorithm steps of each example described in the embodiment disclosed in this application, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solution of the embodiment of the present application.

[0267] The embodiment of the present application can divide the communication equipment / device into functional units according to the above method example. For example, each functional unit can be divided according to each function, or two or more functions can be integrated into one processing unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0268] Another embodiment of the present application provides a communications device, which may be the aforementioned first network element or billing network element, or other device or corresponding component. The device may include: a memory and one or more processors. The memory and processor are coupled. The memory is configured to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the device may perform the various functions or steps performed by the corresponding device in the aforementioned method embodiment. The structure of the device may refer to the structure of the communications device shown in FIG3 .

[0269] The core structure of the communication device can be represented as the structure shown in FIG12 . The communication device includes: a processing module 1301 and a storage module 1303 .

[0270] The processing module 1301 (also referred to as a processing unit) may include at least one of a central processing unit (CPU), an application processor (AP), a communication processor (CP), or an AI processor, and may be implemented as the processor shown in FIG3 . The processing module 1301 may perform operations or data processing related to the control and / or communication of at least one of the other components of the user communication device.

[0271] The storage module 1303 may include a volatile memory and / or a non-volatile memory. The storage module is used to store at least one related instruction or data in other modules of the device. For example, it can be implemented as the memory shown in Figure 3.

[0272] Optionally, a communication module 1305 (also referred to as a communication unit) is further included to support the device communicating with other devices (via a communication network). For example, the communication module can be connected to a network via wireless communication or wired communication to communicate with other devices. Wireless communication can adopt at least one of cellular communication protocols, such as Long Term Evolution (LTE), Advanced Long Term Evolution (LTE-A), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Universal Mobile Telecommunications System (UMTS), Wireless Broadband (WiBro) or Global System for Mobile Communications (GSM). Wireless communication may include, for example, short-range communication. Short-range communication may include at least one of Wireless Fidelity (Wi-Fi), Bluetooth, Near Field Communication (NFC), Magnetic Stripe Transmission (MST) or GNSS. For example, it can be implemented as the communication interface shown in Figure 3.

[0273] The embodiment of the present application also provides a chip, as shown in Figure 13, which includes at least one processor 1401 and at least one interface circuit 1402. The processor 1401 and the interface circuit 1402 can be interconnected via lines. For example, the interface circuit 1402 can be used to receive signals from other devices (such as the memory of a communication device). For another example, the interface circuit 1402 can be used to send signals to other devices (such as the processor 1401). Exemplarily, the interface circuit 1402 can read instructions stored in the memory and send the instructions to the processor 1401. When the instruction is executed by the processor 1401, the communication device can perform the various steps in the above embodiment. Of course, the chip can also include other discrete devices, which is not specifically limited in the embodiment of the present application.

[0274] An embodiment of the present application also provides a computer storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned communication device, the communication device executes each function or step executed by the mobile phone in the above-mentioned method embodiment.

[0275] The embodiment of the present application further provides a computer program product, which, when executed on a computer, enables the computer to execute the functions or steps executed by the mobile phone in the above method embodiment.

[0276] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0277] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0278] Units described as separate components may or may not be physically separate, and components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0279] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0280] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0281] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A communication method, characterized in that: Applied to a first communication device, the method includes: Obtaining an authorization identifier; the authorization identifier is used to identify the intention auxiliary information of the fourth communication device; A first message is sent to the fourth communication device, wherein the first message includes the intention auxiliary information, and the intention auxiliary information is carried in the authorization identifier or access token or one-time credential of the first message, and the intention auxiliary information is used to verify the authorization of the fourth communication device.

2. The method according to claim 1, characterized in that The obtaining of the authorization identifier includes: receiving first information, the first information including contract information of a terminal or second information; the contract information is used to indicate whether the terminal subscribes to an intended service and / or indicates a range of intended services subscribed by the terminal; the second information is determined based on the contract information; The authorization identifier is determined according to the first information.

3. The method according to claim 1, characterized in that The intention auxiliary information is carried in the authorization identifier and further includes: The intention auxiliary information is stored.

4. The method according to claim 1, wherein The obtaining of the authorization identifier includes: An authorization identifier is received from a third communication device.

5. The method according to claim 4, characterized in that The intention auxiliary information is stored in the third communication device, and before receiving the authorization identifier from the third communication device, the method further includes: The intention assistance information is sent to the third communication device.

6. The method according to any one of claims 1 to 5, characterized in that Also includes: receiving a verification request from a second communication device; The verification request is used to verify the consistency between the service information generated by the second communication device and the intention auxiliary information, and the verification request includes the authorization identifier and the service information; Return verification information, where the verification information is used to indicate a verification result of the consistency between the service information and the intention auxiliary information.

7. The method according to claim 6, characterized in that Before returning the verification information, it also includes: sending the authorization identifier and the service information to a third communication device; Receive verification information determined by the third communication device based on the authorization identifier and the service information.

8. The method according to claim 6, characterized in that Before returning the verification information, it also includes: The verification information is determined based on the authorization identifier and the service information.

9. The method according to claim 1, characterized in that Also includes: receiving a first request from the fourth communication device; The first request includes the intention auxiliary information and the authorization identifier; The first request is used to request consistency between the received intention auxiliary information and the locally stored intention auxiliary information corresponding to the authorization identifier; Verifying, according to the first request, the consistency of the received intention auxiliary information with the locally stored intention auxiliary information corresponding to the authorization identifier; Sending a first message to the fourth communication device includes: If the received intention auxiliary information is consistent with the locally stored intention auxiliary information corresponding to the authorization identifier, the first message is sent to the fourth communication device, and the first message includes the consistent intention auxiliary information; the consistent intention auxiliary information is carried in the access token of the first message or the one-time credential.

10. The method according to any one of claims 1 to 9, characterized in that Also includes: Obtain the access token or the one-time credential.

11. The method according to claim 10, characterized in that Obtaining the access token or the one-time credential includes: The access token or the one-time credential is generated.

12. The method according to claim 10, characterized in that Obtaining the access token or the one-time credential includes: The access token or the one-time credential is received from a fifth communication device.

13. The method according to any one of claims 1 to 12, characterized in that Also includes: Deleting the intention auxiliary information; Or send indication information to the third communication device, where the indication information is used to instruct the third communication device to delete the intention auxiliary information.

14. A communication method, characterized in that: Applied to a fourth communication device, the method includes: receiving a first message; authorization information of the first message, the authorization information including: intention auxiliary information and / or an authorization identifier corresponding to the intention auxiliary information; the authorization identifier is used to identify the intention auxiliary information; the intention auxiliary information is used to verify the authorization of the fourth communication device; A service request is sent to the second communication device, where the service request includes the authorization information.

15. The method according to claim 14, characterized in that The authorization information is intention auxiliary information and also includes: A first request is sent to a first communication device, where the first request includes the intention assistance information and the authorization identifier.

16. A communication method, characterized in that: Applied to a second communication device, the method includes: receiving a service request from a first communication device, the service request including authorization information; the authorization information including: intention auxiliary information or an authorization identifier corresponding to the intention auxiliary information; the authorization identifier being used to identify the intention auxiliary information; and the authorization information being used to verify authorization of a fourth communication device; generating service information based on the service request; When the service information is consistent with the intention auxiliary information, the service corresponding to the service information is executed.

17. The method according to claim 16, characterized in that Also includes: sending a verification request to the second communication device; The verification request is used to verify the consistency between the service information generated by the second communication device and the intention auxiliary information, and the verification request includes the authorization identifier and the service information; Verification information is received, where the verification information is used to indicate a verification result of consistency between the service information and the intended auxiliary information.

18. The method according to claim 16 or 17, characterized in that The service request includes the intention auxiliary information and further includes: Verify the consistency between the service information and the intention auxiliary information.

19. A computer-readable storage medium, characterized in that The method comprises a program or an instruction. When the program or the instruction is executed, the method according to any one of claims 1 to 13 is implemented, or the method according to any one of claims 14 to 15 is implemented, or the method according to any one of claims 16 to 18 is implemented.

20. A computer program product, characterized in that The computer program product comprises a program or an instruction, which, when executed on a communication device, causes the communication device to execute the method according to any one of claims 1 to 13, or the method according to any one of claims 14 to 15, or the method according to any one of claims 16 to 18.

21. A circuit system, characterized in that: The circuit system comprises a processing circuit configured to perform the method of any one of claims 1 to 13, or to perform the method of any one of claims 14 to 15, or to perform the method of any one of claims 16 to 18.

22. A communication device, characterized in that: The device includes a processor, configured to support the device in implementing the method according to any one of claims 1 to 13; or, configured to support the device in implementing the method according to claim 14 or 15, or configured to support the device in implementing the method according to any one of claims 16 to 18.

23. A communication system, characterized in that: The method comprises a first communication device for executing the method according to any one of claims 1 to 13, and a fourth communication device for executing the method according to claim 14 or 15.

24. The communication system according to claim 23, wherein: Also included is a second communication device for executing the method according to any one of claims 16-18.

25. A communication method, characterized in that: include: The method according to any one of claims 1 to 13; The method according to claim 14 or 15.

26. The communication method according to claim 25, characterized in that Also includes: The method according to any one of claims 16 to 18.

Images