HCE card AID conflict resolution methods, systems, devices, and media

Abstract

This invention discloses a solution, system, device, and medium for AID conflict resolution of HCE cards, applied to mobile terminals. The method includes: upon receiving an HCE service registration request submitted by any application, querying the AID registry and generating a pending AID corresponding to the HCE service registration request based on the query results; assigning the pending AID to the application and updating the AID registry; periodically traversing the assigned AIDs in the AID registry and determining whether each assigned AID is associated with at least two target HCE services; if at least two target HCE services belong to the same application, an intra-application AID conflict is determined to have occurred, and the intra-application AID conflict is optimized according to the service type of the target HCE service. Through targeted AID allocation and periodic conflict detection, AID conflicts within the same application are accurately resolved, ensuring stable interaction of HCE services and improving HCE card compatibility and user experience.

Description

Technical Field

[0001] This invention relates to the field of conflict resolution technology, and in particular to a method, system, device and medium for resolving AID conflicts in HCE cards. Background Technology

[0002] With the rapid development of mobile internet technology, convenient applications such as mobile payment, public transportation card swiping, and identity authentication are becoming increasingly popular. Users' demand for expanded functionality of mobile devices continues to rise, leading to the emergence of smart cards based on Host Card Emulation (HCE) technology. HCE cards do not rely on the security elements built into mobile devices and can directly simulate the functions of traditional smart cards through the software layer of mobile devices, realizing core applications such as contactless payment, transportation card swiping, and identity verification.

[0003] In practical applications of HCE cards, a single mobile device often needs to run multiple HCE applications, such as payment, transportation, and access control applications. Each HCE application requires a unique Application Identifier (AID) to identify and communicate with the card reader and terminal device. However, due to the lack of a unified AID allocation standard in current HCE application development, different developers may assign the same AID to their respective applications, leading to conflicts such as multiple AIDs per card or duplicate AIDs.

[0004] To address the AID conflict issue in HCE cards, existing technologies commonly employ a fixed AID allocation solution. This involves pre-assigning a fixed AID to each HCE application and verifying the uniqueness of the AID before application deployment. However, this approach struggles to adapt to new application requirements in dynamic environments, and the limited availability of AID resources makes it difficult to cover all application scenarios, resulting in decreased compatibility and flexibility of HCE cards. Summary of the Invention

[0005] This invention provides a solution, system, device, and medium for AID conflict in HCE cards, which solves the technical problems that existing AID conflict solutions are difficult to adapt to new application requirements in dynamic environments, and that the limited AID resources make it difficult to cover all application scenarios, resulting in a decrease in the compatibility and flexibility of HCE cards.

[0006] The first aspect of this invention provides a method for resolving AID conflicts in an HCE card, applied to a mobile terminal, the method comprising:

[0007] When an HCE service registration request is received from any application, the AID registry is queried, and an AID to be assigned corresponding to the HCE service registration request is generated according to the query result.

[0008] Assign the AID to be assigned to the application and update the AID registry;

[0009] Periodically traverse the assigned AIDs in the AID registry and determine whether each assigned AID is associated with at least two target HCE services;

[0010] If at least two of the target HCE services belong to the same application, an AID in-application conflict is determined to have occurred, and the AID in-application conflict is optimized according to the service type of the target HCE service.

[0011] Optionally, the method further includes:

[0012] In response to the initialization command, pre-register all available HCE services and initialize the AID registry.

[0013] Optionally, the method further includes:

[0014] Real-time collection of usage environment data;

[0015] Based on the usage environment data and preset matching rules, determine the services to be enabled and / or the services to be disabled;

[0016] Enable the service to be enabled;

[0017] Disable the service to be disabled.

[0018] Optionally, the step of querying the AID registry and generating a pending AID corresponding to the HCE service registration request based on the query result when receiving an HCE service registration request from any application includes:

[0019] When an HCE service registration request is received from any application, registration requirement information is extracted from the HCE service registration request, and the application is verified to be compliant; the registration requirement information includes service requirement type and application identifier;

[0020] If the verification passes, the AID registry is queried according to the service requirement type to determine if an AID has been assigned.

[0021] Generate a new AID that is different from the already assigned AID according to the service requirement type.

[0022] Optionally, the step of optimizing the AID in-application conflict according to the service type of the target HCE service includes:

[0023] If the target HCE service is a payment service, then the target HCE service with the highest priority is retained to optimize the intra-application conflict of the AID.

[0024] If the service type of the target HCE service is a non-payment service, then a new AID will be reassigned to any of the target HCE services.

[0025] Optionally, the method further includes:

[0026] If it is determined that the assigned AID is associated with at least two target HCE services, and the target HCE services belong to different applications, then an AID cross-application conflict is determined to have occurred, and a selection page is displayed.

[0027] In response to the triggered action on the selection page, select the target HCE service within the corresponding target application and execute it;

[0028] Reassign a new AID to the target HCE service within the target application that has not been triggered.

[0029] Optionally, the method further includes:

[0030] When an intra-application conflict is determined to occur, the conflict information corresponding to the intra-application conflict is recorded.

[0031] A second aspect of the present invention provides an AID conflict resolution system for HCE cards, applied to a mobile terminal, the system comprising:

[0032] The service registration module is used to query the AID registry when it receives an HCE service registration request submitted by any application, and generate an AID to be assigned corresponding to the HCE service registration request according to the query results;

[0033] The AID allocation module is used to allocate the AID to be assigned to the application and update the AID registry;

[0034] The conflict detection module is used to periodically traverse the assigned AIDs in the AID registry and determine whether the assigned AID is associated with at least two target HCE services.

[0035] The conflict resolution module is used to determine that an AID in-application conflict has occurred if at least two of the target HCE services belong to the same application, and to optimize the AID in-application conflict according to the service type of the target HCE service.

[0036] A third aspect of the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of resolving AID conflicts of an HCE card as described in any of the first aspects of the present invention.

[0037] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements an AID conflict resolution method for an HCE card as described in any of the first aspects of the present invention.

[0038] As can be seen from the above technical solutions, the present invention has the following advantages:

[0039] Upon receiving an HCE service registration request from any application, the system queries the AID registry and generates a pending AID corresponding to the HCE service registration request based on the query results. The pending AID is then assigned to the application, and the AID registry is updated. The system periodically iterates through the assigned AIDs in the AID registry to determine if each assigned AID is associated with at least two target HCE services. If at least two target HCE services belong to the same application, an intra-application AID conflict is identified, and the conflict is optimized according to the service type of the target HCE service. Through targeted AID allocation and periodic conflict detection, AID conflicts within the same application are accurately resolved, ensuring stable HCE service interaction and improving HCE card compatibility and user experience. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 A flowchart illustrating the steps for resolving AID conflicts in an HCE card according to an embodiment of the present invention;

[0042] Figure 2 This is a structural block diagram of an AID conflict resolution system for an HCE card provided in an embodiment of the present invention. Detailed Implementation

[0043] This invention provides a solution, system, device, and medium for AID conflict in HCE cards, addressing the technical problem that existing AID conflict solutions are ill-suited to adapting to new application requirements in dynamic environments, and that the limited availability of AID resources makes it difficult to cover all application scenarios, leading to a decline in the compatibility and flexibility of HCE cards.

[0044] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0045] Please see Figure 1 , Figure 1 A flowchart illustrating the steps for resolving AID conflicts in an HCE card, as provided in an embodiment of the present invention.

[0046] This invention provides a solution to AID conflicts in HCE cards, applicable to mobile terminals. The method includes:

[0047] Step 101: When an HCE service registration request is received from any application, query the AID registry and generate the AID to be assigned corresponding to the HCE service registration request according to the query results;

[0048] HCE service registration request refers to the request submitted by an application to the mobile terminal system to which the HCE card belongs, requesting access to the Host Card Emulation (HCE) function. It must include core information such as application identifier (e.g., package name, developer signature), target service type (e.g., payment service, transportation card service, access control service), and compatible terminal type (e.g., POS machine, subway gate).

[0049] The AID registry refers to the system-level storage medium within a mobile terminal, which records key information about all allocated / pending AIDs, including AID value (RID+PIX structure conforming to ISO / IEC 7816-5 standard), associated application identifier, bound service type, allocation time, validity period, and occupancy status (occupied / unoccupied / released).

[0050] A pending AID refers to a unique AID that is not occupied and matches the service requirement type, generated after the system retrieves the AID registry based on the service requirement type in response to the HCE service registration request.

[0051] In this embodiment, when the system on the mobile terminal receives an HCE service registration request submitted by any application, it performs a legality verification. After the verification is successful, the system calls the AID registry query interface to filter preset AID segments that match the target service type in the request, such as the "UnionPay RID A000000003+PIX" segment for payment services and the "Transportation Industry RID D276000085+PIX" segment for transportation card services. The system marks the AID ranges within the AID segment that are in an unoccupied state, selects AIDs that meet the format and uniqueness, and generates the AID to be assigned corresponding to the HCE service registration request.

[0052] In one example of the present invention, step 101 may include the following sub-steps:

[0053] When an HCE service registration request is received from any application, the registration requirement information is extracted from the HCE service registration request, and the application is verified to be compliant. The registration requirement information includes the service requirement type and application identifier.

[0054] If the verification passes, query the AID registry according to the service requirement type to determine if an AID has been assigned.

[0055] Generate a new AID that is different from the already assigned AID based on the service requirement type.

[0056] Registration requirement information refers to the key data used to determine the direction of AID allocation, which includes, but is not limited to, service requirement type and application identifier. The application identifier is used to uniquely identify the application and includes at least the application package name, developer digital signature, and application version number.

[0057] Application requirement type refers to the classification identifier that defines the HCE function in the registration requirement information, following the general classification standard of HCE services, such as payment services (subdivided into UnionPay payment, Visa payment, etc.), transportation card services (subdivided into local subway cards, intercity bus cards, etc.), and identity authentication services (subdivided into access control authentication, campus identity authentication, etc.).

[0058] In this embodiment, after receiving an HCE service registration request submitted by any application, the registration requirement information, namely the service requirement type and application identifier, is extracted from it through the corresponding request parsing interface. Then, compliance verification begins to determine whether the application to which the application identifier belongs is compliant.

[0059] The compliance verification process can be as follows: First, verify the legality of the application identifier. Query the system's "List of Registered Developers," verify that the developer's signature matches the registration information, check for duplicate application package names (to avoid application forgery), and verify that the application version number supports the minimum version requirement of the current system's HCE service (e.g., if the system's HCE service supports application version 1.2, application requests for version 1.1 must be rejected). Second, verify the compliance of the service requirement type. Check if the service requirement type is within the system's list of supported HCE service types (e.g., if the system does not currently support "medical identity authentication" service, then requests for this type of requirement must be rejected). If the service requirement type is a special industry type (e.g., financial payment), it is also necessary to additionally verify whether the application possesses a qualification certificate issued by the industry's competent authority (e.g., a payment business license). If all verification items pass, the application is deemed compliant and proceeds to the subsequent AID query and generation process. If any verification item fails, the system returns a verification failure response to the application, specifying the reason for the failure (e.g., "developer signature not registered" or "service type not supported"), and indicating the direction for rectification.

[0060] After the application passes compliance verification, the AID registry is retrieved according to the service requirement type. AIDs whose associated fields exactly match the service requirement type are selected, and then AIDs with an occupied status are filtered out to determine the assigned AIDs for the current service requirement type. If the query result is empty (i.e., there are no assigned AIDs for the service requirement type), an "empty list" is generated as the assigned AID result. Referring to the ISO / IEC 7816-5 standard and industry specifications, a unique RID (Registered Application Provider Identifier) ​​is matched for each service requirement type. This RID, combined with the value type of the service requirement type, determines the preset range of PIX (Proprietary Application Identifier Extension) to obtain a baseline AID segment. AID values ​​that do not belong to the assigned AIDs are then filtered from this baseline AID segment as AIDs to be assigned.

[0061] For example, AID values ​​not appearing in the "List of Assigned AIDs of the Same Type" are filtered from the baseline AID segment to form a "candidate AID pool". If the candidate AID pool is not empty, the smallest AID is selected as the AID to be assigned according to the "incrementing number" rule (e.g., if the assigned AIDs are "D2760000850101" and "D2760000850103", then "D2760000850102" is selected). If the candidate AID pool is empty (all AIDs in the baseline AID segment have been assigned), the system triggers the AID segment expansion process: based on the original baseline AID segment... The system generates an "Extended AID Segment" by adding a new PIX range (e.g., extending the PIX range of the local metro card service to "0200-0299"), verifying the industry compliance of the Extended AID Segment (e.g., confirming that the Extended PIX range is not occupied by industry standards), and then selecting the smallest unoccupied AID from the Extended AID Segment as the AID to be assigned. After generating the AID to be assigned, the system performs a second uniqueness check on it (querying the AID registry again to confirm that the AID is not occupied by other service types) to ensure that the AID to be assigned is globally unique, and finally outputs the AID to be assigned that meets the requirements.

[0062] Step 102: Assign the AID to be assigned to the application and update the AID registry;

[0063] In this embodiment, after generating an AID to be assigned, the mobile terminal assigns it to the application and finds the corresponding entry for the AID in the AID registry. The entry's occupancy status is updated from unoccupied to occupied, and the associated application identifier (e.g., application package name), bound service type (consistent with the target service type in the registration request), allocation time (system time accurate to milliseconds), and validity period (set for temporary services, marked as indefinite for permanent services) are added. If the AID belongs to a newly added AID segment, a complete record of that AID segment needs to be added to the registry, including the RID, PIX range, and associated service type range. After the update, the system generates an AID allocation log, recording key information of the allocation process (e.g., application identifier, AID value, registry status before and after the update), and simultaneously returns an AID allocation success response to the application, including auxiliary information such as the AID activation time and troubleshooting interface.

[0064] Step 103: Periodically traverse the assigned AIDs in the AID registry and determine whether each assigned AID is associated with at least two target HCE services.

[0065] An assigned AID refers to an AID in the AID registry that is in a occupied state, indicating that it has been bound to a specific application to implement the HCE service required by that application.

[0066] In this embodiment, the periodic verification time interval can be set as a preset value, for example, the default is 200 ms per time. If the current number of HCE services in the system exceeds 10, it is adjusted to 100 ms per time; if it is less than 3, it is adjusted to 500 ms per time, so as to balance the real-time detection and the consumption of system resources. It can also be real-time detection, where the system traverses all the allocated AIDs with the occupied status in the AID registry. For each allocated AID, the associated HCE service list corresponding to the bound service type field is queried, and the number of target HCE services associated with the AID is counted.

[0067] At the same time, the system will verify the validity of each target HCE service, including checking whether the service is in a normal running state (not disabled by the application program and not triggering system exception interception), and whether the binding relationship between the service and the AID is within the validity period (if the AID has a validity period, the service validity period needs to be matched); if the number of target HCE services associated with a certain allocated AID is ≥ 2, and all target HCE services pass the validity verification and are in the active state, then mark the allocated AID as the status to be determined for conflict and enter the conflict resolution process in step 104; if the number of associated target HCE services is < 2, or there are invalid services (such as disabled services), then update the bound service type field of the AID and remove the associated records of the invalid services to ensure the accuracy of the registry data.

[0068] Step 104, if at least two target HCE services belong to the same application program, it is determined that there is an in-application conflict of AID, and the in-application conflict of AID is optimized according to the service types of the target HCE services.

[0069] In this embodiment, after locating all the target HCE services associated with the allocated AID, through the application identifiers corresponding to the target HCE services recorded in the AID registry, if at least two application identifiers are the same, it is determined that the associated target HCE services belong to the same application program, and there is an in-application conflict of AID. At this time, the corresponding conflict resolution measures are matched according to the service types of the target HCE services to resolve the in-application conflict of the AID.

[0070] Among them, the conflict resolution measures include but are not limited to reallocating a new AID, disabling the conflicting HCE services, or prompting the user for manual processing.

[0071] In an example of the present invention, step 104 may include the following sub-steps:

[0072] If the service type of the target HCE service is a payment service, retain the target HCE service with the highest priority to optimize the in-application conflict of AID;

[0073] If the service type of the target HCE service is a non-payment service, then a new AID will be reassigned to any target HCE service.

[0074] Payment services refer to service types used to realize contactless payment functions, which comply with financial industry payment protocols (such as EMVCo specifications and UnionPay PBOC specifications) and must support transaction instruction interaction of devices such as POS machines and payment terminals.

[0075] Non-payment services refer to HCE service types other than payment functions, which do not need to comply with financial payment agreements. Typical examples include transportation card services (subway / bus card swiping), identity authentication services (access control / attendance), and campus card services (cafeteria payments / library borrowing).

[0076] Priority is used to classify the importance of services. It can be set based on dimensions such as the core program of the service, the frequency of user use, and the degree of system compatibility, or it can be set by the user. This ensures that HCE services that are more critical to users and the system are given priority when resolving conflicts.

[0077] In this embodiment, when it is determined that all conflicting target HCE services within the same application are payment services, the system first obtains the priority of each conflicting target HCE service, selects the target HCE service with the highest priority for retention, and sends a message to inform the system of the retained service name and priority basis. Simultaneously, the remaining conflicting target HCE services are disabled. For these conflicting target HCE services, the association between other conflicting services and the AID can be removed, marking these services as awaiting AID reassignment, and updating the bound service type field of the AID in the AID registry, retaining only the retained service information. Finally, the system triggers the subsequent AID reassignment process, assigning new AIDs that conform to the payment service standards to the payment services awaiting AID reassignment, ensuring that all payment services have a unique AID available and that core payment functions are unaffected.

[0078] It should be noted that the priority of the target HCE service can be calculated in the following way: Extract the system's preset basic priority of payment services, such as system default payment services > third-party payment services, credit card payment services > debit card payment services; query the application's user behavior logs and count the usage frequency of each conflicting service in the past 30 days (the more times it is used, the higher the priority weight); verify the transaction compliance of each service (such as whether it has completed financial regulatory filing, whether it supports real-time risk control verification, compliant services have higher priority than services that need to be compliant); then, the system calculates the priority of each conflicting service according to the calculation formula of basic priority × 40% + usage frequency weight × 40% + compliance weight × 20%.

[0079] If all target HCE services in the same application that are experiencing AID conflicts are non-payment services, the frequency of terminal interactions for each conflicting target HCE service can be analyzed. This can be done by analyzing application background logs, such as access control services interacting 10 times daily and campus card services interacting 5 times daily. The service with the lower interaction frequency is selected as the HCE service to be reassigned to minimize the impact on users' daily use. If there is no significant difference in the interaction frequency among the services, any service is randomly selected as the HCE service to be reassigned. Based on this HCE service, an AID segment with the same service type is selected in the AID registry. The association between the HCE service to be reassigned and the original conflicting AID is broken, and a binding relationship is established between the service and the new AID. Simultaneously, the AID registry is updated.

[0080] In one example of the present invention, the method further includes:

[0081] In response to the initialization command, pre-register all available HCE services and initialize the AID registry.

[0082] Initialization commands refer to startup configuration commands that are automatically triggered when the system to which the HCE card belongs starts up, or are manually sent by the system administrator. They are used to trigger the construction of basic resources and the initialization of core data structures for HCE services, and are the prerequisite operations for subsequent HCE service registration and AID allocation.

[0083] HCE available services refer to the set of service types corresponding to all HCE functions supported by the system, covering payment (UnionPay / Visa payment), transportation (local / intercity transportation cards), identity authentication (access control / attendance), industry-specific (campus card / medical card), etc., and must comply with the corresponding industry protocol specifications (such as EMVCo, JT / T1059.2).

[0084] In this embodiment, upon receiving the initialization command, the system traverses the preset service resource library to extract the core information of all available HCE services, including but not limited to service name, service type identifier, compatible industry protocol, standard RID, preset PIX range, and service startup dependencies. This information is stored in the service registry according to the mapping relationship between the new service class identifier and core configuration, and all services are marked as initially disabled.

[0085] At the same time, a field structure containing "AID value (5-16 bytes, conforming to ISO / IEC7816-5), associated application identifier (default empty), bound service type (default empty), occupancy status (unoccupied / occupied / released), allocation time (default empty), validity period (default permanent)" is created. The reserved AID segment of the pre-registered service is entered into the registry, and the reserved AID status is marked as "unoccupied - system reserved". The initial status of the non-reserved AID segment is "unoccupied".

[0086] In one example of the present invention, the method further includes:

[0087] Real-time collection of usage environment data;

[0088] Based on usage environment data and preset matching rules, determine the services to be enabled and / or disabled;

[0089] Enable services that are yet to be enabled;

[0090] Disable the service to be disabled.

[0091] Environmental data refers to contextualized data collected in real time through device sensors, user behavior logs, and terminal interaction information. It can detect the physical environment through geolocation and timestamps; the device environment through device root status; and user behavior through operation frequency and input habits. A dynamic trust assessment model is established through environmental detection. Payment / transportation / authentication services are upper-layer application scenarios, while environmental detection is the underlying security support mechanism.

[0092] In this embodiment, the aforementioned usage environment data can be collected at a frequency of 500ms / time. Specifically, the current geographical location (such as "XX subway station" or "XX shopping mall") is obtained through a location sensor, the type of surrounding terminal is identified through an NFC module (such as reading the "TRANSPORT_TERMINAL" identifier broadcast by the turnstile or the "PAY_TERMINAL" identifier broadcast by the POS machine), and the frequently used services in the past hour (such as "Used UnionPay payment service 3 times") are extracted through user behavior logs.

[0093] The collected usage environment data is then matched against preset matching rules. These rules use a preset key-value pair mapping structure, which can be dynamically matched by the system at runtime or manually selected by the user. For example: 1. Key: Card type identifier; 2. Registration information JSON structure (including HCE service name, AID list, whether it is the default card, enabled status, etc.). For instance, in a payment scenario, if the user only needs to make credit card payments, this module can disable other non-payment-related services. The service status of the HCE card is updated to ensure that enabled services do not cause AID conflicts.

[0094] In addition, when matching using environmental data, it can compare with a preset matching rule base. If the geographical location is a subway station and a transportation terminal is identified, the transportation scenario rule is triggered to filter out services to be enabled (local transportation card service) and services to be disabled (access control service, campus card service). If the NFC signal strength is detected to be <-70dBm, the resource protection rule is triggered, and non-core payment services (such as Visa payment) are added to the list of services to be disabled. After determining the services to be enabled / disabled, the system sends a start command to the services to be enabled, loads the resources that the service depends on (such as loading the balance query interface for the transportation card service and loading the risk control module for the payment service), updates the service status to enabled, and synchronizes it to the system service registry. It sends a stop command to the services to be disabled, releases the AID resources occupied by the service (marks the corresponding AID in the AID registry as unoccupied), closes the service background process, and updates the service status to not disabled. After the operation is completed, a service status adjustment notification is pushed to the user (such as the transportation card service has been enabled and the access control service has been disabled) to ensure that the user is aware of the currently available services.

[0095] In one example of the present invention, the method further includes:

[0096] If it is determined that an assigned AID is associated with at least two target HCE services, and the target HCE services belong to different applications, then an AID cross-application conflict is determined, and a selection page is displayed.

[0097] In response to the triggered action on the selection page, select the target HCE service within the corresponding target application and execute it;

[0098] Reassign a new AID to the target HCE service within the target application that has not been triggered.

[0099] In this embodiment, when periodically searching the AID registry, if it is found that a target HCE service associated with a certain assigned AID corresponds to multiple different application identifiers, it is determined that an AID cross-application conflict has occurred. Subsequently, the system collects the core conflict information, such as the conflicting AID value, the list of applications involved (including application name, icon, and package name), the type of target HCE service associated with each application (such as application A "UnionPay Payment" and application B "Third-Party Payment"), and the usage frequency of each service in the past 7 days.

[0100] Based on the aforementioned core conflict information, a selection page is generated. This selection page lists each conflicting application-service combination in card format (e.g., "Application A - UnionPay Payment (used 20 times in the last 7 days)"). A "Confirm Selection" button is set at the bottom. The selection page is pushed to the user's device foreground. If the user does not take any action within 5 minutes, the recommended service is highlighted by default according to the "highest usage frequency" rule. After the user performs a trigger action (e.g., clicks the Application A service card), the system responds by retaining the binding relationship between the target HCE service of the application and the conflicting AID, and updating the "Associated Application Identifier" of the AID in the AID registry to the selected application identifier.

[0101] For the target HCE service of other applications (such as application B) that have not been triggered, the system initiates the AID reassignment process: query the corresponding preset AID segment according to the service type (such as "UnionPay RID + New PIX" for the payment service of application B), generate a new unused AID, send an "AID reassignment notification" (including the new AID and effective time) to application B, and after application B confirms, establish the binding relationship between the service and the new AID, update the AID registry and release the original conflicting AID.

[0102] In one example of the present invention, the method further includes:

[0103] When an AID in-application conflict is detected, the conflict information corresponding to the AID in-application conflict is recorded.

[0104] In this embodiment of the invention, when an AID in-application conflict is determined to occur, the following core information is extracted and recorded: conflict occurrence time (system time accurate to milliseconds), conflict AID value (e.g., "A0000000030001"), application information involved (package name, developer name, application version number), list of target HCE services in the conflict (service name, service type identifier, service start time), conflict determination basis (e.g., the AID is associated with two services in the AID registry and the application identifiers are consistent), and current usage environment data (geographical location, connection terminal type). Subsequently, the conflict information is encapsulated into a conflict log in "JSON format". The log fields include "conflictId" (a randomly generated unique conflict ID), "conflict Type" (marked as "IN_APP" to indicate an in-application conflict), "conflict Details" (the above core information set), and "processing Status" (initially marked as "unprocessed", subsequently updated to "processed"). The conflict log is stored in the system "conflict log library" and simultaneously backed up to the cloud server (if the cloud log function is enabled).

[0105] It should be noted that for actions such as AID update, traversal of the AID registry, retrieval, and compliance verification of application programs in any embodiment of the present invention, the authorization agreement can be displayed on a page, and after the user confirms and agrees, compliant privacy authorization can be obtained before proceeding.

[0106] It should be understood that although the steps in the flowcharts involved in the above embodiments are sequentially shown according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or steps or stages in other steps.

[0107] Please refer to Figure 2 , a system for resolving AID conflicts of an HCE card provided by an embodiment of the present invention will be described below. The system for resolving AID conflicts of an HCE card described below can be mutually corresponding and referred to the method for resolving AID conflicts of an HCE card described above.

[0108] An embodiment of the present invention provides a system for resolving AID conflicts of an HCE card, which is applied to a mobile terminal. The system includes:

[0109] A service registration module 201, configured to query the AID registry when receiving an HCE service registration request submitted by any application program, and generate a to-be-allocated AID corresponding to the HCE service registration request according to the query result;

[0110] An AID allocation module 202, configured to allocate the to-be-allocated AID to the application program and update the AID registry;

[0111] A conflict detection module 203, configured to periodically traverse the allocated AIDs in the AID registry, and determine whether at least two target HCE services are associated with the allocated AID;

[0112] A conflict resolution module 204, configured to, if at least two target HCE services belong to the same application program, determine that an in-application AID conflict occurs, and optimize the in-application AID conflict according to the service types of the target HCE services.

[0113] Optionally, the system further includes an initialization module, configured to:

[0114] Respond to an initialization instruction, pre-register all available HCE services and initialize the AID registry.

[0115] Optionally, the system also includes a service dynamic enablement module for:

[0116] Real-time collection of usage environment data;

[0117] Based on usage environment data and preset matching rules, determine the services to be enabled and / or disabled;

[0118] Enable services that are yet to be enabled;

[0119] Disable the service to be disabled.

[0120] Optionally, the service registration module 201 is specifically used for:

[0121] When an HCE service registration request is received from any application, the registration requirement information is extracted from the HCE service registration request, and the application is verified to be compliant. The registration requirement information includes the service requirement type and application identifier.

[0122] If the verification passes, query the AID registry according to the service requirement type to determine if an AID has been assigned.

[0123] Generate a new AID that is different from the already assigned AID based on the service requirement type.

[0124] Optionally, the conflict resolution module 204 is specifically used for:

[0125] If the target HCE service is a payment service, then the target HCE service with the highest priority will be retained to optimize AID in-application conflicts.

[0126] If the service type of the target HCE service is a non-payment service, then a new AID will be reassigned to any target HCE service.

[0127] Optionally, the system also includes a cross-application conflict resolution module for:

[0128] If it is determined that an assigned AID is associated with at least two target HCE services, and the target HCE services belong to different applications, then an AID cross-application conflict is determined, and a selection page is displayed.

[0129] In response to the triggered action on the selection page, select the target HCE service within the corresponding target application and execute it;

[0130] Reassign a new AID to the target HCE service within the target application that has not been triggered.

[0131] Optionally, the system also includes a conflict information recording module for:

[0132] When an AID in-application conflict is detected, the conflict information corresponding to the AID in-application conflict is recorded.

[0133] This invention provides an electronic device, including a memory and a processor. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of resolving AID conflicts of an HCE card as described in any embodiment of this invention.

[0134] This invention provides a computer-readable storage medium storing a computer program thereon, which, when executed, implements the AID conflict resolution method for HCE cards as described in any embodiment of this invention.

[0135] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system and modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

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

[0138] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

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

[0140] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for resolving AID conflicts in an HCE card, characterized in that, Applied to a mobile terminal, the method includes: When an HCE service registration request is received from any application, the AID registry is queried, and an AID to be assigned corresponding to the HCE service registration request is generated according to the query result. Assign the AID to be assigned to the application and update the AID registry; Periodically traverse the assigned AIDs in the AID registry and determine whether each assigned AID is associated with at least two target HCE services; If at least two of the target HCE services belong to the same application, an AID in-application conflict is determined to have occurred, and the AID in-application conflict is optimized according to the service type of the target HCE service.

2. The AID conflict resolution method for HCE cards according to claim 1, characterized in that, The method further includes: In response to the initialization command, pre-register all available HCE services and initialize the AID registry.

3. The AID conflict resolution method for HCE cards according to claim 1, characterized in that, The method further includes: Real-time collection of usage environment data; Based on the usage environment data and preset matching rules, determine the services to be enabled and / or the services to be disabled; Enable the service to be enabled; Disable the service to be disabled.

4. The AID conflict resolution method for HCE cards according to claim 1, characterized in that, The step of querying the AID registry and generating a pending AID corresponding to the HCE service registration request based on the query results when an HCE service registration request is received from any application includes: When an HCE service registration request is received from any application, registration requirement information is extracted from the HCE service registration request, and the application is verified to be compliant; the registration requirement information includes service requirement type and application identifier; If the verification passes, the AID registry is queried according to the service requirement type to determine if an AID has been assigned. Generate a new AID that is different from the already assigned AID according to the service requirement type.

5. The AID conflict resolution method for HCE cards according to claim 1, characterized in that, The step of optimizing the AID application-internal conflict according to the service type of the target HCE service includes: If the target HCE service is a payment service, then the target HCE service with the highest priority is retained to optimize the intra-application conflict of the AID. If the service type of the target HCE service is a non-payment service, then a new AID will be reassigned to any of the target HCE services.

6. The AID conflict resolution method for HCE cards according to claim 1, characterized in that, The method further includes: If it is determined that the assigned AID is associated with at least two target HCE services, and the target HCE services belong to different applications, then an AID cross-application conflict is determined to have occurred, and a selection page is displayed. In response to the triggered action on the selection page, select the target HCE service within the corresponding target application and execute it; Reassign a new AID to the target HCE service within the target application that has not been triggered.

7. The AID conflict resolution method for HCE cards according to claim 1, characterized in that, The method further includes: When an intra-application conflict is determined to occur, the conflict information corresponding to the intra-application conflict is recorded.

8. An AID conflict resolution system for an HCE card, characterized in that, The system, applied to a mobile terminal, includes: The service registration module is used to query the AID registry when it receives an HCE service registration request submitted by any application, and generate an AID to be assigned corresponding to the HCE service registration request according to the query results; The AID allocation module is used to allocate the AID to be assigned to the application and update the AID registry; The conflict detection module is used to periodically traverse the assigned AIDs in the AID registry and determine whether the assigned AID is associated with at least two target HCE services. The conflict resolution module is used to determine that an AID in-application conflict has occurred if at least two of the target HCE services belong to the same application, and to optimize the AID in-application conflict according to the service type of the target HCE service.

9. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the HCE card AID conflict resolution method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed, it implements the AID conflict resolution method for the HCE card as described in any one of claims 1-7.

Images