Virtual card processing method and device for access site

Abstract

The embodiment of the present specification provides a virtual card processing method and device of a pass-through place, wherein the virtual card processing method of the pass-through place comprises: in the process of opening a virtual card of the pass-through place, starting from the permission application range submitted by a user to the pass-through place through a service subprogram, based on the application data sent by the first service end of the service subprogram according to the permission application range, sending the opening card data to the second service end of the access control device and receiving the returned pass-through card data, after jumping from the service subprogram to the card processing program through the application program, sending the pass-through card data to the third service end of the card processing program to generate the virtual card in the card processing program, so as to realize the permission application and the virtual card generation of the pass-through place through the cooperation of the application service end, the first service end, the second service end and the third service end.

Description

Technical Field

[0001] This document relates to the field of data processing technology, and in particular to a method and apparatus for processing virtual cards in access areas. Background Technology

[0002] With the continuous development and promotion of the Internet and smart hardware, the application scope of various online services provided by the Internet is becoming wider and wider. In this context, many online services are combined with offline scenarios. For example, online service platforms manage community access control, and users can apply for community access through the online service platform. Another example is that users can copy the community access card with their mobile phones to access the community. However, as the scope of service applications expands and services become more widespread, the requirements for access control security are also getting higher and higher. Summary of the Invention

[0003] This specification provides one or more embodiments of a virtual card processing method for access points, applied to an application server. The method includes: obtaining application data sent by a first server of a service subroutine after verifying user permissions. The application data is determined based on the permission application scope submitted by the user in the service subroutine for the access point. Based on the application data, card activation data is sent to a second server of the access control device deployed at the access point, and access card data generated by the second server is received. The application program performs a redirection process from the service subroutine to a card processing program installed on the user terminal. The access card data is sent to a third server of the card processing program to generate a virtual card corresponding to the access card data.

[0004] This specification provides one or more embodiments of another virtual card processing method for access points, applied to a user terminal. The method includes: submitting a user's permission request scope for the access point to a first server via a service subroutine, so that the first server verifies the user's permissions and sends the request data to an application server. Based on the card activation command submitted by the user in the service subroutine, the application is invoked to jump from the service subroutine to a card processing program. The card processing program generates a virtual card corresponding to the access card data. The access card data is obtained by the application server in cooperation with a second server of the access control equipment deployed at the access point, based on the request data, and is then sent to the card processing program via a third server.

[0005] This specification provides one or more embodiments of a virtual card processing device for access points, running on an application server. The device includes: an application data acquisition module configured to acquire application data sent by a first server of a service subroutine after user permission verification. The application data is determined based on the scope of permission requests submitted by the user for the access point within the service subroutine; a card activation data sending module configured to send card activation data to a second server of access control equipment deployed at the access point based on the application data, and to receive access card data generated by the second server; a redirection processing module configured to cooperate with the application to perform redirection processing from the service subroutine to a card processing program installed on the user terminal; and an access card data sending module configured to send the access card data to a third server of the card processing program, so that the card processing program generates a virtual card corresponding to the access card data.

[0006] This specification provides one or more embodiments of another virtual card processing device for access points, running on a user terminal. The device includes: a permission request scope submission module, configured to submit a user's permission request scope for the access point to a first server via a service subroutine, so that the first server verifies the user's permissions and sends the request data to an application server; a jump module, configured to jump from the service subroutine to a card processing program by calling an application program based on the card activation command submitted by the user in the service subroutine; and a virtual card generation module, configured to generate a virtual card corresponding to the access card data through the card processing program. The access card data is obtained by the application server in cooperation with a second server of the access control equipment deployed at the access point based on the request data, and is then sent to the card processing program through a third server.

[0007] This specification provides one or more embodiments of a virtual card processing device for access points, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: obtain application data sent by a first server of a service subroutine after user permission verification. The application data is determined based on the scope of permission requests submitted by the user for the access point in the service subroutine. Based on the application data, the processor sends card activation data to a second server of an access control device deployed at the access point and receives access card data generated by the second server. The processor, in conjunction with an application program, performs a redirection process from the service subroutine to a card processing program installed on a user terminal. Finally, the processor sends the access card data to a third server of the card processing program to generate a virtual card corresponding to the access card data.

[0008] This specification provides one or more embodiments of a virtual card processing device for access points, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: submit a user's permission request scope for the access point to a first server via a service subroutine, so as to verify the user's permissions through the first server and send the request data to an application server; based on the card activation instruction submitted by the user in the service subroutine, jump from the service subroutine to a card processing program by calling an application program; and generate a virtual card corresponding to the access card data through the card processing program. The access card data is obtained by the application server in cooperation with a second server of the access control equipment deployed at the access point based on the request data, and is then sent to the card processing program through a third server.

[0009] This specification provides one or more embodiments of a computer-readable storage medium for storing computer-executable instructions. When executed, these instructions implement the following process: Obtaining application data sent by a first server of a service subroutine after verifying user permissions. The application data is determined based on the scope of permission requests submitted by the user in the service subroutine for a specific access location. Sending card activation data to a second server of an access control device deployed at the access location based on the application data, and receiving access card data generated by the second server. Performing a redirection process between the service subroutine and a card processing program installed on the user terminal, in conjunction with an application program. Sending the access card data to a third server of the card processing program to generate a virtual card corresponding to the access card data through the card processing program.

[0010] This specification provides one or more embodiments of another computer-readable storage medium for storing computer-executable instructions that, when executed, implement the following process: A user submits a permission request for a designated access point to a first server via a service subroutine, so that the first server verifies the user's permissions and sends the request data to an application server. Based on the card activation instruction submitted by the user in the service subroutine, an application is invoked to jump from the service subroutine to a card processing program. The card processing program generates a virtual card corresponding to the access card data. The access card data is obtained by the application server in cooperation with a second server of the access control equipment deployed at the access point, based on the request data, and is then sent to the card processing program via a third server. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in one or more embodiments of this specification 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 recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram illustrating the implementation environment of a virtual card processing method for access points provided in one or more embodiments of this specification;

[0013] Figure 2 A flowchart illustrating a virtual card processing method for access points, provided for one or more embodiments of this specification;

[0014] Figure 3 A timing diagram illustrating a virtual card processing method for access points, applied to card issuance scenarios, provided in one or more embodiments of this specification.

[0015] Figure 4 A flowchart illustrating another virtual card processing method for access points provided in one or more embodiments of this specification;

[0016] Figure 5 A schematic diagram of an embodiment of a virtual card processing device for access points provided in one or more embodiments of this specification;

[0017] Figure 6 A schematic diagram of another embodiment of a virtual card processing device for a passage location provided by one or more embodiments of this specification;

[0018] Figure 7 A schematic diagram of the structure of a virtual card processing device for a passageway provided in one or more embodiments of this specification;

[0019] Figure 8 This is a schematic diagram of the structure of a virtual card processing device for another access location provided in one or more embodiments of this specification. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0021] The virtual card processing method for access points provided in one or more embodiments of this specification is applicable to the implementation environment of card issuance at access points. (Refer to...) Figure 1 The implementation environment includes at least:

[0022] User terminal 101, application server 102, first server 103, second server 104, third server 105 and access control device 106;

[0023] Among them, the user terminal 101 has an application installed, the application server 102 is the server of the application, the application runs a service subroutine, the first server 103 is the server of the service subroutine, the user can select and submit the scope of permission application through the service subroutine, the first server 103 processes the scope of permission application submitted by the service subroutine and sends the application data to the application server 102.

[0024] The second server 104 is the server for the access control equipment 106 deployed in the access area. The application server 102 cooperates with the second server 104 to process the card opening based on the application data sent by the first server 103 and obtain the access card data.

[0025] In addition, the user terminal 101 is also equipped with a card processing program. The third server 105 is the server of the card processing program. Through the cooperation of the application server 102 and the third server 105, the access card data is sent to the card processing program, and finally the virtual card corresponding to the access card data is generated in the card processing program.

[0026] User terminal 101 can specifically be a mobile phone, personal computer, tablet computer, e-book reader, device for information interaction based on VR (Virtual Reality) and AR (Augmented Reality), vehicle terminal, IoT device, wearable smart device, laptop computer and desktop computer, etc.; application server 102, first server 103, second server 104 and third server 105 can run on their respective servers, server clusters or cloud servers.

[0027] In this implementation environment, during the virtual card processing for access points, the service subroutine first uploads the user's permission request scope for the access point to the first server 103. The first server 103 verifies the user's permissions, determines the request data based on the permission request scope, and sends it to the application server 102. The application server 102 sends card activation data to the second server 104 based on the request data and receives the access card data generated by the second server 104. Subsequently, the application server 102, in conjunction with the application program, performs a jump from the service subroutine to the card processing program. After the jump, the application server 102 sends the access card data to the third server 105, and the card processing program, in cooperation with the third server 105, generates a virtual card corresponding to the access card data. Thus, through the collaboration of the application server 102, the first server 103, the second server 104, and the third server 105, permission requests and virtual card generation in access points are realized, enabling users to process access using the generated virtual card at the access control devices in the access points.

[0028] It should be noted that, considering that the user identifier, identity identifier, communication identifier, application account identifier, and other related data involved in this specification may, to some extent, constitute user privacy, authorization from the user must be obtained before collecting such data to ensure that the data collection operation complies with relevant data management regulations. For example, user authorization can be obtained during the process of a service subroutine or application obtaining user identifiers, identity identifiers, communication identifiers, and application account identifiers. Specific methods of data authorization include sending an authorization reminder to the user, who then confirms the reminder to obtain data collection authorization, or obtaining data collection authorization by signing a data authorization agreement.

[0029] This specification provides one or more embodiments of a virtual card processing method for access points, as follows:

[0030] Reference Figure 2 The virtual card processing method for access points provided in this embodiment can be applied to the application server. The method specifically includes steps S202 to S208.

[0031] Step S202: Obtain the application data sent by the first server of the service subroutine after verifying user permissions.

[0032] The service subroutine described in this embodiment refers to a subroutine providing access processing and other related services to users through a access point or its service provider. Specifically, this service subroutine can be a subroutine running within an application, such as a property management subroutine provided by the property management company of the access point and running within the application. An access point refers to a physical location or facility that users can enter and exit; the act of entering and exiting these locations or facilities constitutes access. For example, an access point can be a residential community, school, office space, study room, or entertainment venue. Correspondingly, the first server of the service subroutine refers to the server that cooperates with the service subroutine to perform access processing and other related service processing.

[0033] In practice, during the activation of virtual cards for access points, users can select and apply for access ranges or permission ranges within the service subroutine. The access range or permission range selected by the user in the service subroutine is called the permission application range. After the user completes the selection of the permission application range in the service subroutine, the service subroutine uploads the permission application range to the first server of the service subroutine. Correspondingly, after receiving the permission application range, the first server verifies the user's permissions and determines the application data based on the permission application range. Furthermore, it sends the application data to the application server of the application. Here, the application server obtains the application data sent by the first server after verifying the user's permissions.

[0034] The application data refers to the data sent by the first server of the service subroutine to apply for access permission to the access point; optionally, the application data is determined based on the scope of permission application submitted by the user for the access point in the service subroutine.

[0035] Specifically, the application data includes the equipment manufacturer's identifier and the access control device identifier of at least one access control device corresponding to the scope of the permission application. The equipment manufacturer's identifier is used to determine the equipment manufacturer of the access control device deployed in the current access area, thereby determining the second server of the access control device, and enabling the application server to communicate with the second server of the access control device. The access control device identifier is used to determine which access control devices are deployed in the access area corresponding to the access range or permission range applied for by the user. The access control device to which the access control device identifier belongs is the access control device corresponding to the access range or permission range applied for by the user, which is the access control device that the user will need to pass through in the access area.

[0036] In addition, the application data may also include card identifier, card type, access location identifier and / or user identifier, wherein the card identifier may be a card number and / or card name assigned by the first server, the card type may be a card type assigned by the first server, and the user identifier may be the user's identity identifier, communication identifier or the user's application account identifier in the application.

[0037] In the specific execution process, the first server can verify user permissions from two perspectives: user identity and scope of permission application. This can improve the security of passage in the access area. Specifically, user permission verification can be carried out by verifying the user's identity and the scope of permission application. Application data can also be generated if the verification is successful.

[0038] In one optional implementation of this embodiment, user permission verification includes: authenticating the user's identity, and after successful authentication, verifying the user's permission request scope to obtain a verification result. The request data is generated if the verification result is successful. Alternatively, user permission verification can also involve verifying the user's permission request scope to obtain a verification result; this verification process includes matching the user's access permissions with the requested scope, specifically verifying whether the user's access permissions match the requested scope. If they match, the verification is considered successful; otherwise, the verification is considered unsuccessful.

[0039] Step S204: Based on the application data, send card opening data to the second server of the access control equipment deployed at the access location, and receive access card data generated by the second server.

[0040] In specific implementation, based on the application data received from the first server of the service subroutine, the application server can generate card activation data and send it to the second server of the access control equipment deployed in the access area. The purpose of sending the card activation data to the second server of the access control equipment is to synchronize the scope of permissions applied for by the user through the service subroutine to the corresponding access control equipment deployed in the access area, so that the user can pass through the corresponding access control equipment deployed in the access area after the virtual card activation process is completed. Specifically, after sending the card activation data to the second server, the second server can distribute the card identifier to the access control equipment corresponding to the access control equipment identifier according to the card identifier and access control equipment identifier carried in the card activation data, thereby synchronizing the current user's permission application to the corresponding access control equipment. At the same time, the second server also generates access card data and returns the generated access card data to the application server. Here, the access card data returned by the second server is received.

[0041] Here, access card data refers to card data used for passage, specifically card-making data used by access control equipment in the passage area. Therefore, access card data can also be replaced by card data or card-making data. The second server does not actually create cards; instead, it generates card data or card-making data for card creation. This card data or card-making data is ultimately sent to the card processing program, which then generates a virtual card based on it. Specifically, access card data includes: access card identifier, key, card data storage sector number, and / or the block data corresponding to the card data storage sector number.

[0042] During the process of generating access card data in cooperation with the second server, the application server can assemble data based on the application data to obtain card activation data and send it to the second server, and receive access card data generated and returned by the second server based on the card activation data.

[0043] In addition, during the process of generating access card data in cooperation between the application server and the second server, a task interaction method can also be used to generate access card data. Specifically, in one optional implementation of this embodiment, card activation data is sent to the second server of the access control equipment deployed at the access location based on the application data, including:

[0044] Data is assembled based on the application data to obtain card activation data, and card activation tasks containing card activation data are created, or card activation tasks containing card activation data are created.

[0045] Based on the device manufacturer identifier contained in the application data, an activation task is sent to the second server corresponding to the device manufacturer identifier.

[0046] In the specific execution process, after the application data is sent to the second server, the second server can parse the application data and synchronize data or permissions with the corresponding access control devices based on the parsing results. For example, based on the access control device identifier contained in the application data, the server can synchronize data or permissions with the access control devices corresponding to the access device identifier in the access area, so as to enable the user to obtain access permissions through data synchronization or permission synchronization. At the same time, the second server generates access card data based on the card type contained in the application data and returns the generated access card data to the application server.

[0047] It should be noted that, in addition to the above-mentioned implementation method of generating access card data through a second server, access card data can also be generated through a first server. In this case, the application data includes access card data generated by the first server. This access card data can be replaced with card data or card production data. The application data is determined based on the scope of permission requests submitted by the user in the service subroutine for the access location. The application data includes card data or card production data generated by the first server. The access card data can be generated after the user's permission verification is passed. Correspondingly, the second server sends card opening data to the access control equipment deployed at the access location based on the application data and receives the access card data generated by the second server. This data can be replaced with... The process can be modified as follows: 1) Send permission synchronization data to the second server of the access control equipment deployed in the access area based on the application data; or 2) Send permission synchronization data to the second server of the access control equipment deployed in the access area based on the application data, and receive the permission synchronization result returned by the second server. The permission synchronization result can be a synchronization success result or a synchronization completion result. The permission synchronization data is used to synchronize the permission application scope to the corresponding access control equipment. Specifically, the permission synchronization data includes the card identifier and the access control equipment identifier. After receiving the card identifier and the access control equipment identifier, the second server can send the card identifier to the access control equipment corresponding to the access control equipment identifier, thereby synchronizing the current user's permission application scope to the corresponding access control equipment.

[0048] Step S206: In conjunction with the application, perform the jump process from the service subroutine to the card processing program installed on the user terminal.

[0049] In practice, after receiving the access card data returned by the second server, the application server, based on the user's operation in the service subroutine within the application, coordinates with the application to perform a jump from the service subroutine to the card processing program installed on the user terminal. Alternatively, after the application server sends permission synchronization data to the second server of the access control equipment deployed at the access location based on the application data, it coordinates with the application to perform a jump from the service subroutine to the card processing program installed on the user terminal. The purpose of jumping to the card processing program is to generate a corresponding virtual card through the card processing program, which is a virtual card that can pass through the access control equipment at the access location.

[0050] During the specific execution process, after the application server receives the access card data or permission synchronization result returned by the second server, it can also synchronize the card opening processing status to the first server. The first server can then send the card opening processing status to the service subroutine, so that the user can be aware of the card opening processing status and perform corresponding operations based on the current card opening processing status.

[0051] Specifically, in one optional implementation of this embodiment, after the application server receives the access card data or permission synchronization result returned by the second server, it synchronizes the card opening processing status to the first server based on the access card data or permission synchronization result, so as to issue the card opening processing status to the service subroutine through the first server; wherein, the jump processing can be performed after detecting the card opening instruction submitted by the user through the service subroutine.

[0052] Optionally, the service subroutine initiates a jump call to the application based on the card activation instruction; the application responds to the jump call and jumps to the card processing program; specifically, the application may respond to the jump call, perform jump execution processing, and cooperate with the application server to perform jump verification, and jump to the card processing program after the verification is passed.

[0053] In the specific execution process, after the application server receives the access card data or permission synchronization result returned by the second server, it sends the card opening processing status to the service subroutine through the first server. The service subroutine receives and displays the card opening processing status. The user can submit a card opening command based on the displayed card opening processing status. After detecting the user's card opening command, the service subroutine can initiate a jump call to the application.

[0054] Correspondingly, the application responds to the jump call, performs jump execution processing, and submits a jump verification request to the application server. After performing the jump verification, the application server returns the verification result to the application. If the verification result is successful, the application executes the jump action to jump to the card processing program. It can also pass parameters to the card processing program. Specifically, the card activation parameters passed to the card processing program include the access card identifier and / or user identifier; the card activation parameters can also include the jump address or application identifier of the card application, so as to perform jump processing to the card application according to the jump address or application identifier.

[0055] Here, the card activation parameters can be sent from the application server to the application after the redirect verification is successful, or they can be sent from the first server to the service subroutine and then passed to the application by the service subroutine; alternatively, some card activation parameters can be sent from the application server to the application after the redirect verification is successful, while other card activation parameters can be sent from the first server to the service subroutine and then passed to the application by the service subroutine. For example, the redirect address or application identifier can be sent from the application server to the application after the redirect verification is successful, while the card identifier and / or user identifier can be sent from the first server to the service subroutine and then passed to the application by the service subroutine; another example is that the card identifier can be sent from the application server to the application after the redirect verification is successful, while the user identifier can be sent from the first server to the service subroutine and then passed to the application by the service subroutine.

[0056] It should be noted that the process of the service subroutine jumping to the card processing program installed on the user terminal can also be executed by the application. In this case, after the application server receives the access card data returned by the second server, it can send the access card data to the third server of the card processing program. That is, after steps S202 and S204 are executed, step S206 can be skipped and step S208 can be executed directly. In this case, the access card data is sent to the third server after the application performs the service subroutine to card processing program jump process.

[0057] Step S208: Send the access card data to the third server of the card processing program so as to generate a virtual card corresponding to the access card data through the card processing program.

[0058] After the aforementioned jump from the service subroutine to the card processing program, the card processing program can request access card data from the application server via a third server. Here, the application server sends the access card data to the third server of the card processing program so that the card processing program can generate a virtual card corresponding to the access card data, or generate a virtual card corresponding to the access card data through cooperation between the card processing program and the third server. A virtual card refers to an electronic card generated by the card application program; this electronic card can specifically be a simulated card or electronic credential used for access control.

[0059] In the specific execution process, when the card processing program requests access card data from the application server through the third server, it can submit a data acquisition request to the third server according to the input card opening parameters, so as to obtain the access card data corresponding to the card opening parameters from the application server through the third server.

[0060] In this process, the card processing program submits a data acquisition request to the third server, which carries card activation parameters. After receiving the data acquisition request, the third server sends a card data request to the application server based on the card activation parameters carried in the data acquisition request. The application server then sends the access card data to the third server based on the card data request. Subsequently, after receiving the access card data, the application server can send the access card data to the card processing program, which then generates the corresponding virtual card based on the access card data. Alternatively, the application server can generate the corresponding virtual card in cooperation with the card processing program after receiving the access card data.

[0061] The aforementioned application server, through the cooperation of the first server, the second server, and the third server, enables the activation of virtual cards for access points. Based on the virtual card obtained after activation, users can use the virtual card to access access points. Specifically, users obtain access permissions for access control devices deployed in the access points that correspond to the user's permission request scope. On this basis, users can use the virtual card to access access control devices deployed in the access points.

[0062] In practical applications, during the access control process of a virtual card in a passage location, the user terminal can establish a near-field communication connection with the access control device through the configured near-field communication component, and then process the access based on the cooperation between the virtual card and the access control device after the near-field communication connection is established.

[0063] In the specific execution process, during the access control process based on the cooperation between the virtual card and the access control device, the user terminal can send the card data of the virtual card to the access control device for access verification. Specifically, in an optional implementation method provided in this embodiment, the access control is implemented in the following way:

[0064] The user terminal sends the virtual card data to the access control device via a near-field communication connection;

[0065] The access control device verifies the card data based on the card opening record and determines the access processing result based on the verification result; the access processing result includes successful access or access failure.

[0066] Furthermore, during the access control process based on the cooperation between the virtual card and the access control device, the access control device can also read the card data of the virtual card from the user terminal and perform access verification based on the near-field communication connection established between the user terminal and the access control device. Specifically, in another optional implementation method provided in this embodiment, the access control is implemented in the following way:

[0067] The access control device reads the card data of the virtual card from the user terminal and sends a card data access verification request to the second server;

[0068] The access control result is determined based on the verification result returned by the second server; data communication between the access control device and the second server is established through the gateway component configured on the access control device. The verification result includes either verification passed or verification failed. Correspondingly, the access result includes either a successful access result (corresponding to successful verification) or a failed access result (corresponding to failed verification).

[0069] It should be noted that the two access control methods provided above can be combined according to actual execution needs, or the combined implementation can be adapted to form a new access control method. For example, access control may include: the user terminal sends the virtual card data to the access control device via a near-field communication connection; the access control device sends an access verification request for the card data to a second server; and the access result is determined based on the verification result returned by the second server. Alternatively, access control may include: the access control device reads the virtual card data from the user terminal; verifies the card data based on the card opening record; and determines the access control result based on the verification result.

[0070] In practical applications, the application server, through the cooperation of a first, second, and third server, processes the activation of virtual cards for access points. Furthermore, it manages these virtual cards, such as deleting them or changing their permissions. Permission changes include modifying the scope of the virtual card's access rights, i.e., changing the range of access control devices the virtual card can pass through. Specifically, the deletion or permission change of virtual cards can be performed through various access channels, such as through service subroutines, card applications, or even card management subroutines within the application.

[0071] In the specific execution process, when the virtual card is deleted through the application as the access point, the deletion of the virtual card can be implemented in the following way: according to the deletion instruction of the virtual card submitted by the application, a deletion request is sent to the third server to delete the virtual card; a deletion notification is sent to the first server and the second server to perform the deletion synchronization process.

[0072] In addition, during the process of deleting a virtual card using the card processing program as the access point, the virtual card deletion process includes: receiving a card deletion notification sent by the third server after performing the virtual card deletion process; performing the deletion process after receiving the virtual card deletion instruction submitted by the user through the card processing program; and sending card deletion notifications to the first server and the second server for synchronized card deletion processing.

[0073] Alternatively, in the process of deleting a virtual card by using a service subroutine as the access point, the virtual card deletion process includes: receiving a virtual card deletion request sent by the first server and forwarding it to the third server to perform the virtual card deletion process; receiving a card deletion notification returned by the third server and sending it to the first server and the second server to perform card deletion synchronization processing.

[0074] In the process of handling virtual card permission changes using a service subroutine as the access entry point, the virtual card deletion process includes: obtaining permission change data sent by the first server; generating permission change data after the permission change verification is passed; and sending permission change data to the second server based on the permission change data to update the permissions of the access control device corresponding to the permission change data.

[0075] Similarly, during the process of changing the permissions of a virtual card, the application program or card processing program can be used as the access point to change the permissions of the virtual card. The specific implementation process can be referred to the above-described process of deleting a virtual card using an application program or card processing program as the access point. This embodiment will not be described in detail here.

[0076] In summary, the virtual card processing method for access points provided in this embodiment, during the activation process of virtual cards for access points, involves the following steps: First, the user submits an access point permission request scope through a service subroutine. The first server verifies the user's permissions, determines the request data based on the permission request scope, and sends it to the application server. The application server, based on the request data sent by the first server, sends card activation data to the second server of the access control device deployed at the access point and receives the access card data generated by the second server. Based on the user's operation within the service subroutine of the application, the application coordinates with the application to redirect the service subroutine to the card processing program installed on the user's terminal. Finally, the application server sends the access card data to the third server of the card processing program, generating a virtual card corresponding to the access card data. By leveraging the interface between the application server and the first server of the service subroutine, the second server of the access control device, and the third server of the card processing program, the online activation of virtual cards for access points is achieved through the cooperation of the application server with the first, second, and third servers, thereby improving the access security of access points.

[0077] Furthermore, based on the virtual card obtained after activation, users can use the virtual card to pass through the access control equipment deployed in the access area, which improves the convenience of users passing through the access area. The virtual card can also be deleted or its permissions changed through multiple access points such as service subroutines, application programs and card processing programs, which improves the flexibility of virtual card management and thus improves the flexibility of access permission management in the access area.

[0078] Steps S202 to S208 provided in this embodiment can be executed by the application server. It should be noted that steps S202 to S208 executed by the application server and steps S402 to S406 executed by the user terminal in the following embodiment can cooperate with each other during execution. Therefore, when reading this embodiment, please refer to the corresponding content of steps S402 to S406 provided in the following method embodiment, and when reading the following method embodiment, please refer to the corresponding content of steps S202 to S208 provided in this embodiment.

[0079] The following example uses the virtual card processing method for access points provided in this embodiment in the card issuance scenario of access points as an example, combined with... Figure 3 The virtual card processing method for access points provided in this embodiment will be further explained below. See [link to relevant documentation]. Figure 3 The virtual card processing method for access points, applied to card issuance scenarios at access points, specifically includes the following steps.

[0080] Step S306: Receive the application data sent by the first server of the service subroutine after verifying user permissions.

[0081] Step S308: Based on the application data, data assembly is performed to obtain card activation data, and a card activation task containing the card activation data is created.

[0082] Step S310: Based on the device manufacturer identifier contained in the application data, send the card activation task to the second server corresponding to the device manufacturer identifier.

[0083] After the card activation task is sent to the second server, the second server processes the card activation to generate access card data and returns the generated access card data to the application server.

[0084] Step S312: Receive the access card data returned by the second server.

[0085] Step S314: Synchronize the card opening processing status with the first server based on the card data, so that the first server can send the card opening processing status to the service subroutine.

[0086] Step S322: In conjunction with the application, the service subroutine performs a jump to the card processing program installed on the user terminal.

[0087] Step S326: Send the access card data to the third server so that it can be sent to the card processing program through the third server.

[0088] Steps S308 to S314 above can be replaced as follows: Based on the device manufacturer identifier contained in the application data, send permission synchronization data to the second server corresponding to the device manufacturer identifier to synchronize the access control device corresponding to the permission synchronization data; the application data contains access card data, and based on the synchronization completion result or synchronization success result returned by the second server, generate a card opening processing status and send it to the first server to issue the card opening processing status to the service subroutine through the first server; correspondingly, step S326 can be replaced as sending the application data containing access card data to the third server to issue it to the card processing program through the third server;

[0089] Alternatively, steps S308 to S314 above can be replaced by: sending permission synchronization data to the second server corresponding to the device manufacturer identifier based on the device manufacturer identifier contained in the application data, so as to synchronize the access control device corresponding to the permission synchronization data; correspondingly, step S326 can be replaced by sending application data containing access card data to the third server, so as to issue it to the card processing program through the third server.

[0090] It should be noted that any one or more of steps S306 to S314, S322, and S328 can be combined with any one or more of steps S202 to S208 to form a new implementation method according to the needs of implementation and deployment. In addition, any one or more technical features in steps S306 to S314, S322, and S328 can be selected according to the actual deployment needs and combined with any one or more technical features provided in steps S202 to S208 to form a new implementation method. Alternatively, any one or more technical features in steps S306 to S314, S322, and S328 can also be replaced with any one or more technical features provided in steps S202 to S208 to form a new implementation method according to the actual deployment needs. These will not be elaborated on here.

[0091] Furthermore, it should be noted that steps S306 to S314, S322, and S328 provided in this embodiment can be executed by the application server. It should also be noted that the steps S306 to S314, S322, and S328 executed by the application server can cooperate with steps S302 to S304, S316 to S320, and S324 and S328 executed by the user terminal in the following embodiments. Therefore, when reading this embodiment, please refer to the corresponding content of steps S302 to S304, S316 to S320, and S324 and S328 provided in the following method embodiments. When reading the following method embodiments, please refer to the corresponding content of steps S306 to S314, S322, and S328 provided in this embodiment.

[0092] One or more embodiments of another virtual card processing method for access points provided in this specification are as follows:

[0093] Reference Figure 4 The virtual card processing method for access points provided in this embodiment can be applied to user terminals. The method specifically includes steps S402 to S406.

[0094] Step S402: The user submits the scope of permission requests for the access location to the first server through the service subroutine, so that the first server can verify the user's permissions and send the request data to the application server.

[0095] The service subroutine described in this embodiment refers to a subroutine providing access processing and other related services to users through a access point or its service provider. Specifically, this service subroutine can be a subroutine running within an application, such as a property management subroutine provided by the property management company of the access point. An access point refers to a physical location or facility that users can actually enter and exit; the act of entering and exiting these locations constitutes access. For example, an access point can be a residential community, school, office space, study room, or entertainment venue. Correspondingly, the first server of the service subroutine refers to the server that cooperates with the service subroutine to perform access processing and other related service processing.

[0096] In practice, during the activation process of virtual cards for access points, the user submits the scope of permission requests for access points to the first server through a service subroutine, so that the first server can verify the user's permissions and send the request data to the application server.

[0097] In the specific execution process, the user can first select and apply for the access range or permission range for the access location in the service subprogram. The access range or permission range selected by the user in the service subprogram is called the permission application range. After the user completes the selection of the permission application range in the service subprogram, the service subprogram uploads the permission application range to the first server of the service subprogram.

[0098] Accordingly, after receiving the scope of the permission request, the first server verifies the user's permissions and determines the request data based on the scope of the permission request. Furthermore, it sends the request data to the application server of the application. The application server obtains the request data sent by the first server after verifying the user's permissions, and sends the card opening data to the second server of the access control equipment deployed in the access area based on the request data, and receives the access card data generated by the second server.

[0099] The application data refers to the data sent by the first server of the service subroutine to apply for access permission to the access point; optionally, the application data is determined based on the scope of permission application submitted by the user for the access point in the service subroutine.

[0100] Specifically, the application data includes the equipment manufacturer's identifier and the access control device identifier of at least one access control device corresponding to the scope of the permission application. The equipment manufacturer's identifier is used to determine the equipment manufacturer of the access control device deployed in the current access area, thereby determining the second server of the access control device, and enabling the application server to communicate with the second server of the access control device. The access control device identifier is used to determine which access control devices are deployed in the access area corresponding to the access range or permission range applied for by the user. The access control device to which the access control device identifier belongs is the access control device corresponding to the access range or permission range applied for by the user, which is the access control device that the user will need to pass through in the access area.

[0101] In addition, the application data may also include card identifier, card type, access location identifier and / or user identifier, wherein the card identifier may be a card number and / or card name assigned by the first server, the card type may be a card type assigned by the first server, and the user identifier may be a user's identity identifier, communication identifier or user's application account identifier in the application.

[0102] In the specific execution process, the first server can verify user permissions from two perspectives: user identity and scope of permission application. This can improve the security of passage in the access area. Specifically, user permission verification can be carried out by verifying the user's identity and the scope of permission application. Application data can also be generated if the verification is successful.

[0103] In one optional implementation of this embodiment, user permission verification includes: authenticating the user's identity, and after successful authentication, verifying the user's permission request scope to obtain a verification result. The request data is generated if the verification result is successful. Alternatively, user permission verification can also involve verifying the user's permission request scope to obtain a verification result; this verification process includes matching the user's access permissions with the requested scope, specifically verifying whether the user's access permissions match the requested scope. If they match, the verification is considered successful; otherwise, the verification is considered unsuccessful.

[0104] Based on the application data received from the first server of the service subroutine, the aforementioned application server can generate card activation data and send it to the second server of the access control equipment deployed in the access area. The purpose of sending the card activation data to the second server of the access control equipment is to synchronize the scope of permissions requested by the user through the service subroutine to the corresponding access control equipment deployed in the access area, so that the user can pass through the corresponding access control equipment deployed in the access area after the virtual card activation process is completed. Specifically, after sending the card activation data to the second server, the second server can distribute the card identifier to the access control equipment corresponding to the access control equipment identifier according to the card identifier and access control equipment identifier carried in the card activation data, thereby synchronizing the current user's permission request to the corresponding access control equipment. At the same time, the second server also generates access card data and returns the generated access card data to the application server. Here, the access card data returned by the second server is received.

[0105] Here, access card data refers to card data used for passage, specifically card-making data used by access control equipment at the passage location. Therefore, access card data can also be replaced by card data or card-making data. The second server does not actually create cards; instead, it generates card data or card-making data for card creation. Finally, after the card data or card-making data is sent to the card processing program, the program generates a virtual card based on the card data or card-making data. Specifically, access card data includes: access card identifier, key, card data storage sector number, and / or block data corresponding to the card data storage sector number.

[0106] During the process of generating access card data in cooperation between the application server and the second server, data assembly can be performed based on the application data to obtain card activation data, which is then sent to the second server. The application server can also receive access card data generated and returned by processing the access card based on the card activation data. Alternatively, during the process of generating access card data in cooperation between the application server and the second server, a task interaction method can also be used. Specifically, in one optional implementation of this embodiment, sending card activation data to the second server of the access control equipment deployed at the access point based on the application data includes: assembling data based on the application data to obtain card activation data and creating a card activation task containing the card activation data; and sending the card activation task to the second server corresponding to the equipment manufacturer identifier based on the equipment manufacturer identifier contained in the application data.

[0107] In the specific execution process, after the application data is sent to the second server, the second server can parse the application data and synchronize data or permissions with the corresponding access control devices based on the parsing results. For example, based on the access control device identifier contained in the application data, the server can synchronize data or permissions with the access control devices corresponding to the access device identifier in the access area, so as to enable the user to obtain access permissions through data synchronization or permission synchronization. At the same time, the second server generates access card data based on the card type contained in the application data and returns the generated access card data to the application server.

[0108] It should be noted that, in addition to the above-mentioned implementation method of generating access card data through a second server, access card data can also be generated through a first server. In this case, the application data includes access card data generated by the first server. This access card data can be replaced with card data or card production data. The application data is determined based on the scope of permission requests submitted by the user in the service subroutine for the access location. The application data includes card data or card production data generated by the first server. The access card data can be generated after the user's permission verification is passed. Correspondingly, the second server sends card opening data to the access control equipment deployed at the access location based on the application data and receives the access card data generated by the second server. This data can be replaced with... The process can be modified as follows: 1) Send permission synchronization data to the second server of the access control equipment deployed in the access area based on the application data; or 2) Send permission synchronization data to the second server of the access control equipment deployed in the access area based on the application data, and receive the permission synchronization result returned by the second server. The permission synchronization result can be a synchronization success result or a synchronization completion result. The permission synchronization data is used to synchronize the permission application scope to the corresponding access control equipment. Specifically, the permission synchronization data includes the card identifier and the access control equipment identifier. After receiving the card identifier and the access control equipment identifier, the second server can send the card identifier to the access control equipment corresponding to the access control equipment identifier, thereby synchronizing the current user's permission application scope to the corresponding access control equipment.

[0109] Step S404: Based on the card opening instruction submitted by the user in the service subroutine, the application is invoked to jump from the service subroutine to the card processing program.

[0110] After the user submits the permission request scope for the access location to the first server through the service subroutine, the application is called to jump from the service subroutine to the card processing program based on the card activation instruction submitted by the user in the service subroutine. Specifically, in the process of jumping from the service subroutine to the card processing program, the application can handle the jump from the service subroutine to the card processing program, or the application can cooperate with the application server to handle the jump from the service subroutine to the card processing program.

[0111] During execution, the application responds to the jump call, performs jump execution processing, and submits a jump verification request to the application server. After performing the jump verification, the application server returns the verification result to the application. If the verification result is successful, the application executes the jump action to jump to the card processing program. Parameters can also be passed to the card processing program. Specifically, the card activation parameters passed to the card processing program include the access card identifier and / or user identifier. The card activation parameters may also include the jump address or application identifier of the card application, thereby performing jump processing to the card application based on the jump address or application identifier.

[0112] Here, the card activation parameters can be sent from the application server to the application after the redirect verification is successful, or they can be sent from the first server to the service subroutine and then passed to the application by the service subroutine; alternatively, some card activation parameters can be sent from the application server to the application after the redirect verification is successful, while other card activation parameters can be sent from the first server to the service subroutine and then passed to the application by the service subroutine. For example, the redirect address or application identifier can be sent from the application server to the application after the redirect verification is successful, while the card identifier and / or user identifier can be sent from the first server to the service subroutine and then passed to the application by the service subroutine; another example is that the card identifier can be sent from the application server to the application after the redirect verification is successful, while the user identifier can be sent from the first server to the service subroutine and then passed to the application by the service subroutine.

[0113] After receiving the access card data returned by the second server, the application server can synchronize the card activation processing status with the first server. The first server then sends the card activation processing status to the service subroutine, allowing the user to perceive the card activation processing status and perform corresponding operations based on it. Correspondingly, before the application jumps from the service subroutine to the card processing program based on the card activation command submitted by the user in the service subroutine, the service subroutine can also receive and display the card activation processing status sent by the first server. The card activation processing status is synchronized from the application server to the first server based on the access card data.

[0114] Step S406: Generate a virtual card corresponding to the access card data through the card processing program.

[0115] Optionally, the access card data is obtained by the application server in cooperation with the second server of the access control equipment deployed at the access location based on the application data, and then sent to the card processing program through the third server; or, the access card data is generated by the second server of the access control equipment deployed at the access location and sent to the card processing program through the third server; in addition, the access card data can also be sent to the card processing program through the third server after the access control equipment deployed at the access location synchronizes access control device permissions based on the permission synchronization data sent by the application server; or, the access card data is generated by the first server and sent to the card processing program through the third server after the access control device permissions are synchronized by the second server of the access control equipment deployed at the access location.

[0116] In the specific execution process, the application server, based on the application data, cooperates with the second server of the access control equipment deployed at the access point to obtain access card data through card opening processing. After the application performs a service subroutine jump to the card processing program, or after the application and the application server cooperate to perform a service subroutine jump to the card processing program, the application server sends the access card data to the third server. The third server then distributes the access card data to the card processing program. Based on this, the card processing program generates a virtual card corresponding to the access card data, or the card processing program cooperates with the third server to generate a virtual card corresponding to the access card data.

[0117] In addition, the card processing program can request access card data from the application server through a third server. Here, the application server sends access card data to the third server of the card processing program so that the card processing program can generate a virtual card corresponding to the access card data, or generate a virtual card corresponding to the access card data through cooperation between the card processing program and the third server. In the specific execution process, when the card processing program requests access card data from the application server through the third server, it can submit a data acquisition request to the third server according to the input card activation parameters so that the third server can obtain the access card data corresponding to the card activation parameters from the application server.

[0118] In this process, the card processing program submits a data acquisition request to the third server, which carries card activation parameters. After receiving the data acquisition request, the third server sends a card data request to the application server based on the card activation parameters carried in the data acquisition request. The application server then sends the access card data to the third server based on the card data request. Subsequently, after receiving the access card data, the application server can send the access card data to the card processing program, which then generates the corresponding virtual card based on the access card data. Alternatively, the application server can generate the corresponding virtual card in cooperation with the card processing program after receiving the access card data.

[0119] The aforementioned application server, through the cooperation of the first server, the second server, and the third server, enables the activation of virtual cards for access points. Based on the virtual card obtained after activation, users can use the virtual card to access access points. Specifically, users obtain access permissions for access control devices deployed in the access points that correspond to the user's permission request scope. On this basis, users can use the virtual card to access access control devices deployed in the access points.

[0120] In practical applications, during the access control process of a virtual card in a passage location, the user terminal can establish a near-field communication connection with the access control device through the configured near-field communication component, and then process the access based on the cooperation between the virtual card and the access control device after the near-field communication connection is established.

[0121] In the specific execution process, during the access control process based on the cooperation between the virtual card and the access control device, the user terminal can send the card data of the virtual card to the access control device for access verification. Specifically, in an optional implementation method provided in this embodiment, the access control is implemented in the following way:

[0122] The user terminal sends the virtual card data to the access control device via a near-field communication connection;

[0123] The access control device verifies the card data based on the card opening record and determines the access processing result based on the verification result; the access processing result includes successful access or access failure.

[0124] Furthermore, during the access control process based on the cooperation between the virtual card and the access control device, the access control device can also read the card data of the virtual card from the user terminal and perform access verification based on the near-field communication connection established between the user terminal and the access control device. Specifically, in another optional implementation method provided in this embodiment, the access control is implemented in the following way:

[0125] The access control device reads the card data of the virtual card from the user terminal and sends a card data access verification request to the second server;

[0126] The access control result is determined based on the verification result returned by the second server; data communication between the access control device and the second server is established through the gateway component configured on the access control device. The verification result includes either verification passed or verification failed. Correspondingly, the access result includes either a successful access result (corresponding to successful verification) or a failed access result (corresponding to failed verification).

[0127] It should be noted that the two access control methods provided above can be combined according to actual execution needs, or the combined implementation can be adapted to form a new access control method. For example, access control may include: the user terminal sends the virtual card data to the access control device via a near-field communication connection; the access control device sends an access verification request for the card data to a second server; and the access result is determined based on the verification result returned by the second server. Alternatively, access control may include: the access control device reads the virtual card data from the user terminal; verifies the card data based on the card opening record; and determines the access control result based on the verification result.

[0128] In practical applications, the application server, through the cooperation of a first, second, and third server, processes the activation of virtual cards for access points. Furthermore, it manages these virtual cards, such as deleting them or changing their permissions. Permission changes include modifying the scope of the virtual card's access rights, i.e., changing the range of access control devices the virtual card can pass through. Specifically, the deletion or permission change of virtual cards can be performed through various access channels, such as through service subroutines, card applications, or even card management subroutines within the application.

[0129] In the specific execution process, when the virtual card is deleted through the application as the access point, the deletion of the virtual card can be implemented in the following way: according to the deletion instruction of the virtual card submitted by the application, a deletion request is sent to the third server to delete the virtual card; a deletion notification is sent to the first server and the second server to perform the deletion synchronization process.

[0130] In addition, during the process of deleting a virtual card using the card processing program as the access point, the virtual card deletion process includes: receiving a card deletion notification sent by the third server after performing the virtual card deletion process; performing the deletion process after receiving the virtual card deletion instruction submitted by the user through the card processing program; and sending card deletion notifications to the first server and the second server for synchronized card deletion processing.

[0131] Alternatively, in the process of deleting a virtual card by using a service subroutine as the access point, the virtual card deletion process includes: receiving a virtual card deletion request sent by the first server and forwarding it to the third server to perform the virtual card deletion process; receiving a card deletion notification returned by the third server and sending it to the first server and the second server to perform card deletion synchronization processing.

[0132] In the process of handling virtual card permission changes using a service subroutine as the access entry point, the virtual card deletion process includes: obtaining permission change data sent by the first server; generating permission change data after the permission change verification is passed; and sending permission change data to the second server based on the permission change data to update the permissions of the access control device corresponding to the permission change data.

[0133] Similarly, during the process of changing the permissions of a virtual card, the application program or card processing program can be used as the access point to change the permissions of the virtual card. The specific implementation process can be referred to the above-described process of deleting a virtual card using an application program or card processing program as the access point. This embodiment will not be described in detail here.

[0134] Steps S402 to S406 provided in this embodiment can be executed by the user terminal. It should be noted that the steps S402 to S406 executed by the user terminal and steps S202 to S208 executed by the application server in the above embodiment can cooperate with each other during execution. Therefore, when reading this embodiment, please refer to the corresponding content of steps S202 to S208 provided in the above method embodiment, and when reading the above method embodiment, please refer to the corresponding content of steps S402 to S406 provided in this embodiment.

[0135] The following example uses the virtual card processing method for access points provided in this embodiment in the card issuance scenario of access points as an example, combined with... Figure 3 The virtual card processing method for access points provided in this embodiment will be further explained below. See [link to relevant documentation]. Figure 3 The virtual card processing method for access points, applied to card issuance scenarios at access points, specifically includes the following steps.

[0136] Step S302: Obtain the scope of permission requests selected by the user for the access location through the service subroutine.

[0137] Step S304: Submit the user's permission request scope for the access location to the first server through the service subroutine.

[0138] After the permission request scope is submitted to the first server, the first server verifies the user's permissions. After the verification is passed, the first server determines the request data according to the permission request scope and then sends the request data to the application server of the application.

[0139] Step S316: Receive and display the card opening processing status sent by the first server through the service subroutine.

[0140] Step S318: Obtain the card activation instruction submitted by the user in the service subroutine.

[0141] Step S320: The application is called to jump from the service subroutine to the card processing program and pass parameters.

[0142] In step S324, the card processing program submits a data retrieval request to the third server based on the input card activation parameters.

[0143] After the data retrieval request is submitted to the third-party server, the third-party server forwards the data retrieval request to the application server.

[0144] Step S328: Receive the access card data sent by the third server through the card processing program, and generate a virtual card corresponding to the access card data.

[0145] It should be noted that any one or more steps in steps S302 to S304, steps S316 to S320, and steps S324 and S328 can be combined with any one or more steps in steps S402 to S406 to form a new implementation method according to the needs of implementation and deployment. Furthermore, any step in steps S302 to S304, steps S316 to S320, and steps S324 and S328 can be selected according to the actual deployment needs. One or more technical features can be combined with one or more technical features provided in steps S402 to S406 to form a new implementation method; or, any one or more technical features in steps S302 to S304, steps S316 to S320, and steps S324 and S328 can be replaced with any one or more technical features provided in steps S402 to S406 to form a new implementation method according to the actual deployment needs, which will not be elaborated here.

[0146] The following is an embodiment of a virtual card processing device for access points provided in this specification:

[0147] In the above embodiments, a virtual card processing method for access points is provided, and correspondingly, a virtual card processing device for access points is also provided, which will be described below with reference to the accompanying drawings.

[0148] Reference Figure 5 This illustration shows a schematic diagram of an embodiment of a virtual card processing device for access points provided in this embodiment.

[0149] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0150] This embodiment provides a virtual card processing device for access points, which runs on an application server. The device includes:

[0151] The application data acquisition module 502 is configured to acquire application data sent by the first server of the service subroutine after verifying user permissions; the application data is determined based on the scope of permission application submitted by the user for the access location in the service subroutine.

[0152] The card opening data sending module 504 is configured to send card opening data to the second server of the access control equipment deployed at the access location based on the application data, and to receive access card data generated by the second server;

[0153] The jump processing module 506 is configured to cooperate with the application to perform jump processing from the service subroutine to the card processing program installed on the user terminal;

[0154] The access card data sending module 508 is configured to send the access card data to a third server of the card processing program so as to generate a virtual card corresponding to the access card data through the card processing program.

[0155] Another embodiment of the virtual card processing device for access points provided in this specification is as follows:

[0156] In the above embodiments, another method for processing virtual cards in access areas is provided, and correspondingly, another device for processing virtual cards in access areas is also provided, which will be described below with reference to the accompanying drawings.

[0157] Reference Figure 6 This illustration shows a schematic diagram of another embodiment of a virtual card processing device for access points provided in this embodiment.

[0158] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0159] This embodiment provides a virtual card processing device for access points, which operates on a user terminal. The device includes:

[0160] The permission request scope submission module 602 is configured to submit the permission request scope submitted by the user for the access location to the first server through a service subroutine, so that the first server can verify the user's permissions and send the application data to the application server;

[0161] The jump module 604 is configured to jump from the service subroutine to the card processing program by calling the application program according to the card opening instruction submitted by the user in the service subroutine.

[0162] The virtual card generation module 606 is configured to generate a virtual card corresponding to the access card data through the card processing program; the access card data is obtained by the application server in cooperation with the second server of the access control equipment deployed in the access location based on the application data, and is sent to the card processing program through the third server.

[0163] The following is an example of a virtual card processing device for access points provided in this specification:

[0164] Corresponding to the virtual card processing method for access control locations described above, based on the same technical concept, one or more embodiments of this specification also provide a virtual card processing device for access control locations, which is used to execute the virtual card processing method for access control locations provided above. Figure 7 This is a schematic diagram of a virtual card processing system for a passageway provided in one or more embodiments of this specification.

[0165] This embodiment provides a virtual card processing method for access points, including:

[0166] like Figure 7 As shown, the virtual card processing in a access point can vary significantly due to different configurations or performance. It may include one or more processors 701 and memory 702, with memory 702 storing one or more application programs or data. Memory 702 can be temporary or persistent storage. The application programs stored in memory 702 may include one or more modules (not shown), each module including a series of computer-executable instructions for the virtual card processing in the access point. Furthermore, processor 701 may be configured to communicate with memory 702 and execute the series of computer-executable instructions in memory 702 on the virtual card processing in the access point. The virtual card processing in the access point may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input / output interfaces 705, one or more keyboards 706, etc.

[0167] In one specific embodiment, the virtual card processing for access points includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the virtual card processing of access points, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0168] The application data is sent by the first server of the service subroutine after verifying the user's permissions; the application data is determined based on the scope of permission application submitted by the user for the access location in the service subroutine.

[0169] Based on the application data, the card activation data is sent to the second server of the access control equipment deployed at the access point, and the access card data generated by the second server is received.

[0170] The application performs the jump process from the service subroutine to the card processing program installed on the user terminal.

[0171] The access card data is sent to a third server of the card processing program so that the card processing program can generate a virtual card corresponding to the access card data.

[0172] Another embodiment of a virtual card processing device for access points provided in this specification is as follows:

[0173] Corresponding to the other virtual card processing method for access points described above, based on the same technical concept, one or more embodiments of this specification also provide another virtual card processing device for access points, which is used to execute the other virtual card processing method for access points provided above. Figure 8 This is a schematic diagram of the structure of a virtual card processing device for another access location provided in one or more embodiments of this specification.

[0174] This embodiment provides a virtual card processing device for access points, comprising:

[0175] like Figure 8 As shown, the virtual card processing device for access control locations can vary significantly due to differences in configuration or performance. It may include one or more processors 801 and a memory 802, where one or more application programs or data may be stored. The memory 802 can be temporary or persistent storage. The application programs stored in the memory 802 may include one or more modules (not shown), each module including a series of computer-executable instructions from the virtual card processing device. Furthermore, the processor 801 may be configured to communicate with the memory 802, executing the series of computer-executable instructions in the memory 802 on the virtual card processing device. The virtual card processing device may also include one or more power supplies 803, one or more wired or wireless network interfaces 804, one or more input / output interfaces 805, one or more keyboards 806, etc.

[0176] In one specific embodiment, the virtual card processing device for the access point includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the virtual card processing device for the access point, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0177] The service subroutine submits the user's permission request scope for the access location to the first server, so that the first server can verify the user's permissions and send the request data to the application server;

[0178] Based on the card activation instruction submitted by the user in the service subroutine, the application is invoked to jump from the service subroutine to the card processing program;

[0179] The card processing program generates a virtual card corresponding to the access card data; the access card data is obtained by the application server in cooperation with the second server of the access control equipment deployed at the access location based on the application data, and is then sent to the card processing program through the third server.

[0180] This specification provides an embodiment of a computer-readable storage medium as follows:

[0181] Corresponding to the virtual card processing method for access points described above, based on the same technical concept, one or more embodiments of this specification also provide a computer-readable storage medium.

[0182] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed, implement the following process:

[0183] The application data is sent by the first server of the service subroutine after verifying the user's permissions; the application data is determined based on the scope of permission application submitted by the user for the access location in the service subroutine.

[0184] Based on the application data, the card activation data is sent to the second server of the access control equipment deployed at the access point, and the access card data generated by the second server is received.

[0185] The application performs the jump process from the service subroutine to the card processing program installed on the user terminal.

[0186] The access card data is sent to a third server of the card processing program so that the card processing program can generate a virtual card corresponding to the access card data.

[0187] It should be noted that the embodiments of a computer-readable storage medium described in this specification and the embodiments of a virtual card processing method for access points described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0188] Another embodiment of a computer-readable storage medium provided in this specification is as follows:

[0189] Corresponding to the virtual card processing method for another access location described above, based on the same technical concept, one or more embodiments of this specification also provide another computer-readable storage medium.

[0190] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed, implement the following process:

[0191] The service subroutine submits the user's permission request scope for the access location to the first server, so that the first server can verify the user's permissions and send the request data to the application server;

[0192] Based on the card activation instruction submitted by the user in the service subroutine, the application is invoked to jump from the service subroutine to the card processing program;

[0193] The card processing program generates a virtual card corresponding to the access card data; the access card data is obtained by the application server in cooperation with the second server of the access control equipment deployed at the access location based on the application data, and is then sent to the card processing program through the third server.

[0194] It should be noted that the embodiments of another computer-readable storage medium described in this specification and the embodiments of another virtual card processing method for access locations described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0195] This specification provides an example of a computer program product as follows:

[0196] Corresponding to the virtual card processing method for access points described above, based on the same technical concept, one or more embodiments of this specification also provide a computer program product.

[0197] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps:

[0198] The application data is sent by the first server of the service subroutine after verifying the user's permissions; the application data is determined based on the scope of permission application submitted by the user for the access location in the service subroutine.

[0199] Based on the application data, the card activation data is sent to the second server of the access control equipment deployed at the access point, and the access card data generated by the second server is received.

[0200] The application performs the jump process from the service subroutine to the card processing program installed on the user terminal.

[0201] The access card data is sent to a third server of the card processing program so that the card processing program can generate a virtual card corresponding to the access card data.

[0202] It should be noted that the embodiments of a computer program product described in this specification and the embodiments of a virtual card processing method for access points described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0203] Another example of a computer program product provided in this specification is as follows:

[0204] Corresponding to the virtual card processing method for another access location described above, based on the same technical concept, one or more embodiments of this specification also provide another computer program product.

[0205] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps:

[0206] The service subroutine submits the user's permission request scope for the access location to the first server, so that the first server can verify the user's permissions and send the request data to the application server;

[0207] Based on the card activation instruction submitted by the user in the service subroutine, the application is invoked to jump from the service subroutine to the card processing program;

[0208] The card processing program generates a virtual card corresponding to the access card data; the access card data is obtained by the application server in cooperation with the second server of the access control equipment deployed at the access location based on the application data, and is then sent to the card processing program through the third server.

[0209] It should be noted that the embodiments of another computer program product described in this specification and the embodiments of another virtual card processing method for access locations described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0210] The various embodiments in this specification are described in a progressive manner. For the same or similar parts between the various embodiments, please refer to each other. Each embodiment focuses on describing the differences from other embodiments. For example, the device embodiments, equipment embodiments, computer-readable storage medium embodiments, and computer program product embodiments are all similar to the method embodiments, so the descriptions are relatively simple. For reading the relevant content of the device embodiments, equipment embodiments, computer-readable storage medium embodiments, and computer program product embodiments, please refer to the description of the method embodiments.

[0211] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0212] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0213] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0214] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0215] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0216] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0217] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0218] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0219] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0220] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0221] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0222] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0223] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising at least one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0224] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0225] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A virtual card processing method for a pass site, applied to an application server, the method comprising: obtaining application data sent by a first server of a service subprogram after user permission verification; the application data is determined based on a permission application range submitted by a user to the service subprogram for a pass site; the application data includes a device manufacturer identifier and a door access device identifier of at least one door access device corresponding to the permission application range; sending card opening data to a second server corresponding to the device manufacturer identifier based on the application data, and receiving pass card data generated by the second server; cooperating with an application program to perform jump processing of a card processing program installed by the service subprogram on a user terminal; sending the pass card data to a third server of the card processing program to generate a virtual card corresponding to the pass card data through the card processing program. 2.The virtual card processing method for a pass site according to claim 1, wherein the user permission verification is achieved in the following manner: performing identity verification on the user, and performing verification processing on the user in the permission application range to obtain a verification result after the identity verification passes, and the application data is generated under the condition that the verification result is verification passed. 3.The virtual card processing method for a pass site according to claim 1, wherein the step of sending card opening data to a second server corresponding to the device manufacturer identifier based on the application data comprises: performing data assembly based on the application data to obtain the card opening data, and creating a card opening task containing the card opening data; based on the device manufacturer identifier contained in the application data, sending the card opening task to the second server corresponding to the device manufacturer identifier. 4.The virtual card processing method for a pass site according to claim 1, further comprising, after the step of sending card opening data to a second server corresponding to the device manufacturer identifier based on the application data, and receiving pass card data generated by the second server, and before the step of cooperating with an application program to perform jump processing of a card processing program installed by the service subprogram on a user terminal: synchronizing card opening processing status to the first server based on the pass card data, to issue the card opening processing status to the service subprogram through the first server; wherein the jump processing is performed after detecting a card opening instruction submitted by the user through the service subprogram. 5.The virtual card processing method for a pass site according to claim 4, wherein the service subprogram initiates a jump call to the application program based on the card opening instruction; the application program responds to the jump call to perform jump execution processing and cooperates with the application server to perform jump verification, and jumps to the card processing program after verification. 6.The virtual card processing method for a pass site according to claim 1, wherein the card processing program submits a data acquisition request to the third server according to an incoming card opening parameter, to acquire the pass card data corresponding to the card opening parameter from the application server through the third server; wherein the card opening parameter includes a user identifier and a pass card identifier. 7.The virtual card processing method of a pass-through site according to claim 1, wherein the user terminal establishes a near field communication connection with the access control device through a configured near field communication component, and performs pass-through processing with the access control device according to the virtual card after the near field communication connection is established. 8.The virtual card processing method of a pass-through site according to claim 7, wherein the pass-through processing is implemented in the following manner: the user terminal sends card data of the virtual card to the access control device through the near field communication connection; and the access control device verifies the card data based on card opening records, and determines a pass-through processing result according to a verification result. 9.The virtual card processing method of a pass-through site according to claim 7, wherein the pass-through processing is implemented in the following manner: the access control device reads card data of the virtual card from the user terminal, and sends a pass-through verification request of the card data to the second server; and a pass-through result is determined according to a verification result returned by the second server; and data communication between the access control device and the second server is established through a gateway component configured in the access control device. 10.The virtual card processing method of a pass-through site according to claim 1, further comprising: sending a card deletion request to the third server to delete the virtual card according to a deletion instruction of the virtual card submitted by the application program; and sending a card deletion notification to the first server and the second server to perform card deletion synchronization processing. 11.The virtual card processing method of a pass-through site according to claim 1, further comprising: obtaining permission change data sent by the first server; wherein the permission change data is generated after permission change verification is passed; and sending the permission change data to the second server based on the permission change data to perform permission update processing on an access control device corresponding to the permission change data. 12.The virtual card processing method of a pass-through site according to claim 1, further comprising: receiving a card deletion notification sent by the third server after deletion processing of the virtual card is performed; wherein the deletion processing is performed after a deletion instruction of the virtual card submitted by the user through the card processing program is received; and sending the card deletion notification to the first server and the second server to perform card deletion synchronization processing. 13.A virtual card processing method of a pass-through site, applied to a user terminal, the method comprising: submitting, by a service subprogram, a permission application range submitted by a user for a pass-through site to a first server to perform user permission verification by the first server and send application data to an application server; the application data comprising a device manufacturer identifier and an access control device identifier of at least one access control device corresponding to the permission application range; jumping, according to a card opening instruction submitted by the user in the service subprogram, from the service subprogram to a card processing program by calling an application program. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ A virtual card corresponding to the access card data is generated by the card processing program; the access card data is obtained by the application server based on the application data and the second server corresponding to the device manufacturer identifier, and is delivered to the card processing program through the third server.

14. The virtual card processing method of the access site according to claim 13, wherein the user permission verification is implemented in the following manner: The user is authenticated, and after the authentication, the user is verified in the permission application range to obtain a verification result, and the application data is generated in the case that the verification result is verified.

15. The virtual card processing method of the access site according to claim 13, wherein after the step of submitting the permission application range submitted by the user to the access site to the first server for user permission verification by the first server and sending the application data to the application server, and before the step of jumping from the service subprogram to the card processing program by calling the application according to the card opening instruction submitted by the user in the service subprogram, the method further comprises: The card opening processing state issued by the first server is received and displayed by the service subprogram. The card opening processing state is synchronized by the application server to the first server based on the access card data.

16. The virtual card processing method of the access site according to claim 13, wherein the user terminal establishes a near field communication connection with the access control device through the configured near field communication component, and performs access processing with the access control device according to the virtual card after the near field communication connection is established.

17. The virtual card processing method of the access site according to claim 16, wherein the access processing is implemented in the following manner: The user terminal sends the card data of the virtual card to the access control device through the near field communication connection, the access control device verifies the card data based on the card opening record, and determines the access processing result according to the verification result; Or, The access control device reads the card data of the virtual card from the user terminal, and sends an access verification request of the card data to the second server, and determines the access result according to the verification result returned by the second server; the data communication between the access control device and the second server is established through the gateway component configured by the access control device.

18. A virtual card processing device for an access site, running on an application server, the device comprising: An application data acquisition module configured to acquire application data sent by a first server of a service subprogram after user permission verification; The application data is determined based on the permission application range submitted by the user in the service subprogram for the access site; the application data includes a device manufacturer identifier and a door control device identifier of at least one door control device corresponding to the permission application range; An opening card data sending module configured to send opening card data to a second server corresponding to the device manufacturer identifier based on the application data, and receive access card data generated by the second server. a jump processing module configured to cooperate with an application program to perform jump processing of a card processing program installed by the service subprogram to the user terminal; a pass card data sending module configured to send the pass card data to a third server of the card processing program, so as to generate a virtual card corresponding to the pass card data through the card processing program. 19.A virtual card processing apparatus of a pass site, running on a user terminal, the apparatus comprising: an authority application range submission module configured to submit, through a service subprogram, an authority application range submitted by a user for a pass site to a first server, so as to perform user authority verification through the first server and send application data to an application server; the application data comprising a device manufacturer identifier and a door access device identifier of at least one door access device corresponding to the authority application range; a jump module configured to jump, according to a card opening instruction submitted by the user in the service subprogram, from the service subprogram to a card processing program through calling an application program; a virtual card generation module configured to generate a virtual card corresponding to pass card data through the card processing program; the pass card data being obtained through card opening processing performed by the application server based on the application data and a second server corresponding to the device manufacturer identifier, and being sent to the card processing program through a third server. 20.A virtual card processing apparatus of a pass site, comprising: a processor; and a memory configured to store computer executable instructions, which, when executed, cause the processor to: obtain application data sent by a first server of a service subprogram after performing user authority verification; the application data being determined based on an authority application range submitted by a user in the service subprogram for a pass site; the application data comprising a device manufacturer identifier and a door access device identifier of at least one door access device corresponding to the authority application range; send card opening data to a second server corresponding to the device manufacturer identifier based on the application data, and receive pass card data generated by the second server; cooperate with an application program to perform jump processing of a card processing program installed by the service subprogram to the user terminal; send the pass card data to a third server of the card processing program, so as to generate a virtual card corresponding to the pass card data through the card processing program. 21.A virtual card processing apparatus of a pass site, comprising: a processor; and a memory configured to store computer executable instructions, which, when executed, cause the processor to: submit, through a service subprogram, an authority application range submitted by a user for a pass site to a first server, so as to perform user authority verification through the first server and send application data to an application server; the application data comprising a device manufacturer identifier and a door access device identifier of at least one door access device corresponding to the authority application range; jump, according to a card opening instruction submitted by the user in the service subprogram, from the service subprogram to a card processing program through calling an application program; The virtual card corresponding to the access card data is generated by the card processing program; the access card data is obtained by the application service end based on the application data and the second service end corresponding to the equipment manufacturer identifier, and is issued to the card processing program through the third service end. 22.A computer readable storage medium storing computer executable instructions which, when executed, implement the steps of the method of claim 1 or 13.

Images