An application authorization method, device, medium and electronic equipment

Abstract

The present specification provides an application authorization method, device, medium and electronic equipment, in which the client can provide a centralized credit investigation authorization entrance for the user by setting a batch authorization page component on the authorization management page, so as to avoid the operation fragmentation problem caused by single application independent authorization. When it is monitored that the user clicks the component, the client can quickly obtain and display an authorization gateway page containing a candidate application list and corresponding to-be-authorized credit investigation fields, so that the user can intuitively view all to-be-authorized applications and specific to-be-authorized credit investigation fields required by each to-be-authorized application on the same page, and can check and confirm the to-be-authorized credit investigation fields corresponding to the to-be-authorized application and other candidate applications at one time, thereby avoiding the "misauthorization" risk caused by operation fatigue, ensuring that each authorized application only obtains the minimum range of credit investigation data required by its business, and protecting the safety of user privacy data.

Description

An application licensing method, apparatus, medium, and electronic device Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to an application licensing method, apparatus, medium, and electronic device. Background Technology

[0002] With the rapid development of Internet technology, various applications (hereinafter referred to as "applications") have been deeply integrated into users' daily lives and work. From social communication and e-commerce transactions to content browsing and office collaboration, users often need to use various different applications at the same time to meet diverse needs.

[0003] Applications involving user privacy data or core functions often require authorization before use. Current application authorization schemes typically adopt a single-application-level authorization model, where each application initiates an authorization request independently, and users complete the authorization confirmation operation for each application separately. This repetitive and fragmented operation mode makes the user operation cumbersome. As the number of applications requiring authorization increases, users need to continuously invest attention to complete similar operations, which can easily lead to "authorization fatigue." Consequently, users no longer carefully check the scope of permissions requested by each application (such as whether it involves sensitive fields such as phone number, location, and consumption records), but habitually and quickly click the "confirm authorization" button, resulting in "incorrect authorization" and thus posing a risk of leakage of user privacy data. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, an application authorization method is provided, the method being applied to a client of an application to be authorized, the method comprising:

[0006] The preset authorization management page is displayed to the user; the authorization management page includes a batch authorization page component.

[0007] In response to a click operation performed by the user on the batch authorization page component, an authorization gateway page is displayed to the user; the authorization gateway page contains a list of candidate applications and each credit field to be authorized corresponding to each candidate application in the list of candidate applications.

[0008] Based on the interactive operations performed by the user on the authorization gateway page, at least one candidate application is determined from the candidate application list as an authorized application, and the authorization field corresponding to the authorized application is determined from each credit information field to be authorized.

[0009] The identification information of the authorized application and the authorization fields configured by the user for the authorized application are sent to the server of the target credit reporting platform for storage, so that the server can respond to any credit data query request sent by the application and return the user's personal credit data accordingly.

[0010] According to a second aspect of one or more embodiments of this specification, an application authorization method is proposed, the method being applied to the server of a target credit reporting platform, the method comprising:

[0011] Receive an authorization gateway page retrieval request; the authorization gateway page retrieval request is sent by the user in response to a click operation performed by the user on the batch authorization page component contained in the authorization management page after the client of the application to be authorized displays the preset authorization management page to the user;

[0012] In response to the request to obtain the authorization gateway page, the client sends the page resource information of the preset authorization gateway page to the client, so that the client displays the authorization gateway page to the user according to the page resource information, and determines at least one candidate application from the candidate application list included in the authorization gateway page as the authorization application according to the selection operation performed by the user in the authorization gateway page, and determines the authorization field corresponding to the authorization application from each credit information field to be authorized included in the authorization gateway page according to the configuration operation performed by the user for the authorization application in the authorization gateway page, and returns the identification information of the authorization application and the authorization field configured by the user for the authorization application.

[0013] The system receives and saves the identification information of the authorized application and the authorization fields configured by the user for the authorized application, so as to respond to a credit data query request sent by any application and return the user's personal credit data accordingly.

[0014] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor performs the executable instructions to implement the steps of the application licensing method described above.

[0015] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the application licensing method as described above.

[0016] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the application licensing method described above.

[0017] As can be seen from the above embodiments, the client of the application to be authorized can display a preset authorization management page to the user. The authorization management page includes a batch authorization page component. In response to the user's click operation on the batch authorization page component, the client sends an authorization gateway page retrieval request to the server of the target credit reporting platform and receives page resource information returned by the server. Based on the received page resource information, the client displays the authorization gateway page to the user. The authorization gateway page includes a candidate application list and each candidate application in the candidate application list corresponding to each credit reporting field to be authorized. Different credit reporting fields to be authorized are used to represent different types of personal credit assessment information. Then, based on the selection operation performed by the user on the authorization gateway page, at least one candidate application is determined from the candidate application list as the authorized application. Based on the configuration operation performed by the user on the authorization gateway page for the authorized application, the authorization field corresponding to the authorized application is determined from each credit reporting field to be authorized. The identification information of the authorized application and the authorization field configured by the user for the authorized application are sent to the server of the target credit reporting platform for storage, so that the server can respond to any credit data query request sent by the application and return the user's personal credit data.

[0018] This method provides users with a centralized credit authorization entry point by setting up a batch authorization page component on the authorization management page. This avoids the fragmentation problem caused by independent authorization of single applications. When the client detects that a user clicks on this component, it can quickly obtain and display the authorization gateway page containing a list of candidate applications and the corresponding credit fields to be authorized. This allows users to intuitively view all applications to be authorized and the specific credit fields required by each application on the same page. Users can also perform a one-time verification and confirmation of the credit fields to be authorized for the applications and other candidate applications. This avoids the risk of "misauthorization" due to operational fatigue and ensures that each authorized application only obtains the minimum range of credit data required for its business, thus protecting the security of user privacy data. Attached Figure Description

[0019] Figure 1 is a schematic diagram of the architecture of an application authorization system provided in an exemplary embodiment.

[0020] Figure 2 is a flowchart illustrating an application authorization method provided in an exemplary embodiment.

[0021] Figure 3 is a schematic diagram of the authorization gateway page display process provided in an exemplary embodiment.

[0022] Figure 4 is a schematic diagram of an authentication process provided in an exemplary embodiment.

[0023] Figure 5 is a schematic diagram of an authorization process provided in an exemplary embodiment.

[0024] Figure 6 is a flowchart illustrating an application authorization method provided in an exemplary embodiment.

[0025] Figure 7 is a schematic structural diagram of a device provided in an exemplary embodiment.

[0026] Figure 8 is a block diagram of an application licensing device provided in an exemplary embodiment.

[0027] Figure 9 is a block diagram of an application licensing device provided in an exemplary embodiment. Detailed Implementation

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

[0029] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0030] Currently, with the rapid development of Internet technology, credit reporting platforms, as the core carriers for centralized management of users' personal credit data, provide sensitive information such as users' credit performance records, debt status, and credit scores, which have become key bases for business applications to conduct credit assessments.

[0031] For example, when users apply for credit cards, installment payments, or undergo credit checks for housing rentals, they need to initiate data access requests to the credit reporting platform through the corresponding business applications. The business applications must obtain explicit authorization from the users before they can obtain and use the users' credit data from the credit reporting platform to perform business operations.

[0032] Currently, the authorization method for credit data between credit reporting platforms and business applications generally adopts a single-application-level authorization model. This means that each business application, when needing to access credit data, must independently initiate an authorization request to the credit reporting platform and trigger a dedicated user authorization confirmation process. Specifically, if a user applies for a small loan through application A, they need to be redirected to the corresponding authorization management interface within application A to verify the scope of permissions requested by application A (e.g., whether to authorize access to personal credit score, online ID number, driving score, loan repayment records for the past 5 years, and credit card delinquency details), and complete the authorization operation. If the user subsequently applies for a car rental credit review through application B, they will need to re-enter the corresponding authorization management interface in application B and repeat the above verification and confirmation steps.

[0033] Therefore, the single-application authorization model has significant inconveniences. On the one hand, the operation process is repetitive and fragmented. When users use multiple authorized business applications in a short period of time, they need to repeatedly perform similar authorization operations, which not only prolongs the business processing time but also easily disrupts the user's operational continuity and reduces the overall user experience. On the other hand, a large number of repetitive authorization operations can easily lead to user "authorization fatigue." That is, credit data permissions are professional and complex. As the number of applications requiring authorization increases, users need to continuously pay attention to identify the permission requirements of each application. Long-term repetitive operations will cause users to gradually relax their awareness of verification, no longer carefully confirm the scope of permissions, and instead habitually click the "confirm authorization" button quickly, thus causing "misauthorization" problems. This may allow some business applications to obtain credit data beyond their actual business needs, thereby posing a risk of leakage to user privacy data security.

[0034] Based on this, this specification provides an application authorization method that offers users a centralized credit authorization entry point by setting up a batch authorization page component on the authorization management page. This avoids the fragmented operation problem caused by independent authorization of single applications. When the client detects that a user clicks on this component, it can quickly obtain and display an authorization gateway page containing a list of candidate applications and their corresponding credit fields to be authorized. This allows users to intuitively view all applications to be authorized and the specific credit fields required for each application on a single page. Users can also perform a one-time verification and confirmation of the credit fields for applications to be authorized and other candidate applications, avoiding the risk of "incorrect authorization" due to operational fatigue. This ensures that each authorized application only obtains the minimum range of credit data required for its business, protecting user privacy and data security.

[0035] Figure 1 is a schematic diagram of the architecture of an application authorization system provided in an exemplary embodiment. As shown in Figure 1, the system may include a client 11, a business server 12, a server 13 of a target credit scoring platform, a network 14, etc.

[0036] The client 11 can be an application carrier that the user can directly operate. Specifically, it can run on various electronic devices used by the user, including but not limited to mobile phones, PCs, tablets, laptops, PDAs (Personal Digital Assistants), and wearable devices (such as smart glasses and smartwatches). This specification does not limit the specific type of electronic device in one or more embodiments. During operation, the aforementioned electronic device can run a client-side program of a certain application to realize the relevant functions of that application. For example, when the electronic device runs an application requiring credit authorization, such as a rental service, it can become a client for the corresponding rental service. The client-side program can be a native application installed on the electronic device, a lightweight application such as a mini-program or quick app, or it can refer to implementing relevant functions in a page format using web technologies such as HTML5 through a browser (including standalone browser applications or browser modules embedded in applications).

[0037] Client 11 can be used to guide users to complete credit authorization operations, specifically including: displaying a preset authorization management page (which contains a batch authorization page component), receiving user clicks on the batch authorization page component, sending an authorization gateway page retrieval request to the server 13 of the target credit reporting platform, receiving page resource information, and displaying the authorization gateway page (including a list of candidate applications and the credit reporting fields to be authorized for each candidate application) based on the page resource information. At the same time, it collects the selection and configuration operations performed by the user on the authorization gateway page to determine the authorized application selected by the user and the authorization fields configured for the authorized application. Finally, it sends the authorized application identification information and the corresponding authorization fields to the server 13 of the target credit reporting platform.

[0038] The business server 12 can be a physical server containing an independent host, or it can be a virtual server hosted by a host cluster. During operation, the business server 12 can run server-side programs of a certain application to implement the relevant functions of that application. For example, when the business server 12 runs a rental service program, it can be implemented as a corresponding rental service platform. As the backend server of the business platform to which client 11 belongs, business server 12 can securely communicate with server 13 of the target credit reporting platform. Specifically, this includes: receiving user business execution requests (such as car rental, installment payments, and other businesses that require credit data support) transmitted by client 11; generating authorization request parameters (such as client_id, redirect_uri, scope=credit_report, state, timestamp, etc.) that conform to the specifications of the target credit reporting platform; generating a credit data query request based on the authorization request parameters and sending it to server 13 of the target credit reporting platform to obtain the user's personal credit data; and finally performing business logic processing (such as risk scoring and credit decision-making) based on the obtained personal credit data to obtain business execution results (such as business execution results that indicate that the user meets the conditions for rental services and can rent without a deposit). The business execution results are then returned to client 11 to be displayed to the user.

[0039] The server 13 of the target credit reporting platform can be a server corresponding to the credit reporting platform that provides users' personal credit data query and authorization management. It can be deployed using a high-security independent physical host or cluster virtual server to ensure the security of data storage and transmission.

[0040] The server 13 of the target credit reporting platform can receive and respond to the authorization gateway page acquisition request from the client 11 (or the client 11 sends a business execution request to the business server, which is then responded to by the business server 12). It can also store the identification information of the authorized application configured by the user and the corresponding authorization fields, perform user identity verification (such as name and ID number matching, face recognition, SMS verification code verification), generate authorization agreements (clarifying the data purpose, scope, and duration), issue authorization codes and access tokens, verify the risk of credit data query requests (such as access token validity, permission scope, and call frequency), and return encrypted personal credit data (such as JSON format credit performance records, credit scores, etc.) based on the user's authorization configuration, ensuring the security of the user's personal credit data.

[0041] As for the network 14 that facilitates interaction between the client 11, the business server 12, and the target credit reporting platform's server 13, communication can be achieved using either wired or wireless networks, based on the communication methods supported by the corresponding electronic devices. This manual does not impose any restrictions on this. For example, when the client 11 runs on a PC, it supports wired / wireless networks; when the client 11 runs on mobile terminals such as mobile phones or wearable devices, it primarily uses wireless networks such as 4G / 5G / Wi-Fi. To ensure data security, encrypted wired networks or dedicated wireless networks can be used for data transmission between the business server 12 and the target credit reporting platform's server 13.

[0042] Figure 2 is a flowchart illustrating an application authorization method provided in an exemplary embodiment, including:

[0043] S200: Display the preset authorization management page to the user; the authorization management page includes a batch authorization page component.

[0044] In this manual, the client of the application to be authorized can display a preset authorization management page containing a batch authorization page component to the user, so that the user can perform authorization operations for the application to be authorized on the authorization management page according to actual needs, or perform click operations on the batch authorization page component to perform batch authorization operations for multiple applications.

[0045] The aforementioned client for the application to be authorized can refer to the client of the business application that the user is currently operating and that requires the user's personal credit data to complete the corresponding business function. It can also refer to an independent authorization management client that integrates authorization management functions for multiple business applications (e.g., the client provided by the target credit reporting platform for managing authorization management functions for multiple business applications, third-party authorization management tools, etc.).

[0046] The aforementioned applications awaiting authorization can refer to business applications currently being used by the user (e.g., credit application applications, car rental applications, credit card application applications, etc.), or business applications that the user has previously used but still require supplementary credit authorization.

[0047] The scenarios in which the client of the application to be authorized will display the preset authorization management page to the user include, but are not limited to, the following:

[0048] The first type: When the client of the application to be authorized hears the user performing a business operation that requires the user's personal credit data in the application to be authorized (such as a car rental business application), such as clicking the "rent a car without deposit" button, clicking the "get credit assessment results" button, etc., the client of the application to be authorized can determine whether it has obtained the user's personal credit data authorization for the current application.

[0049] If the client of the application to be authorized determines that the current application has not authorized the user's personal credit data, or determines that the authorization of the user's personal credit data has expired, the client can pop up a floating window on the current business interface or jump to a separate page to display the preset authorization management page to the user.

[0050] For example, if a user clicks the "Rent a Car Without Deposit" button in the client application of Car Rental Business A to apply for car rental without deposit, and the client application of Car Rental Business A detects that the user's personal credit data authorization has not yet been obtained, it can redirect the user to the authorization management page containing the batch authorization page component to guide the user to complete the authorization operation.

[0051] The second method involves the client of the application to be authorized displaying an authorization expiration notification message (such as an application push notification message or SMS notification message) to the user when it detects that the user's authorization for the application is about to expire. After the user clicks on the authorization expiration notification message, the user is redirected to the authorization management page, which displays the preset authorization management page to the user.

[0052] For example, when the client of CreditB's business application detects that the user's authorization for CreditB's business application is about to expire, it can push a notification message to the user that "the current personal credit data authorization is about to expire, click to manage". After the user clicks the authorization expiration notification message, the preset authorization management page will be displayed to the user.

[0053] It should be noted that the aforementioned bulk authorization page component is used to guide users to actively trigger bulk authorization operations, and it can be a button component, a card-style interactive component, etc.

[0054] In addition to the batch authorization page component, the aforementioned authorization management page may also include the following page components: a component displaying authorization information for pending applications, a component querying historical authorization information, and a component for modifying authorization. The component displaying authorization information for pending applications can be included in the authorization management page in the form of cards, forms, etc., and can be used to display key information about the pending applications, such as the name of the pending applications and the corresponding credit fields for authorization. The component querying historical authorization information can be included in the authorization management page in the form of buttons, forms, etc., and can be used to display information such as the authorization fields that the user has already authorized for the pending applications and the authorization validity period.

[0055] S202: In response to the user's click operation on the batch authorization page component, the authorization gateway page is displayed to the user; the authorization gateway page contains a list of candidate applications and each credit field to be authorized corresponding to each candidate application in the list of candidate applications.

[0056] Furthermore, after the client of the application to be authorized displays the preset authorization management page to the user, the user can perform authorization operations for the application to be authorized on the authorization management page, or perform click operations on the batch authorization component contained in the authorization management page to perform batch authorization for the application to be authorized and other candidate applications, as shown in Figure 3.

[0057] Figure 3 is a schematic diagram of the authorization gateway page display process provided in an exemplary embodiment.

[0058] As shown in Figure 3, when the client of the application to be authorized detects a user's click operation on the batch authorization component contained in the authorization management page, it can generate an authorization gateway page retrieval request. Then, it can send the generated authorization gateway page retrieval request to the server of the target credit reporting platform and receive the page resource information corresponding to the authorization gateway page returned by the server of the target credit reporting platform.

[0059] The authorization gateway page acquisition request mentioned above may include, but is not limited to, the client's identification information, the user's identification information, the identification information of the application to be authorized, the request timestamp, and other information.

[0060] The page resource information corresponding to the aforementioned authorization gateway page can refer to the page's Uniform Resource Locator (URL). In this case, the client of the application to be authorized can be redirected based on the received page resource information to jump to the authorization gateway page. Alternatively, the page resource information can also refer to a page resource package consisting of the authorization gateway page's page structure, style, and data. In this case, the client of the application to be authorized can render the authorization gateway page based on the received page resource information and display it to the user.

[0061] It should be noted that the authorization gateway page mentioned above may contain a list of candidate applications, as well as each candidate application in the list of candidate applications and each credit information field to be authorized. Different credit information fields to be authorized are used to represent different types of personal credit information contained in the user's personal credit data.

[0062] For example, the credit information fields to be authorized mentioned above can be: personal credit score, online ID number, driving score, whether credit repayment records have been authorized, credit card overdue records, etc.

[0063] In this specification, the credit information fields to be authorized for each application in the candidate application list can all be the same, or different credit information fields to be authorized for different applications in the candidate application list can be set according to actual needs. This specification does not impose any restrictions on this.

[0064] For example: When the pending credit reporting fields for all applications in the candidate application list are the same, for a travel service application in the candidate application list, the pending credit reporting fields can be personal credit score, online ID number, and driving score; and for a consumer finance application in the candidate application list, the pending credit reporting fields can also be personal credit score, online ID number, and driving score. Conversely, when the pending credit reporting fields for all applications in the candidate application list are different, for a travel service application in the candidate application list, the pending credit reporting fields can be personal credit score, online ID number, and driving score; and for a consumer finance application in the candidate application list, the pending credit reporting fields can also be personal credit score, online ID number, and loan repayment records.

[0065] In addition, in practical application scenarios, in order to reduce the risk of leakage of users' personal credit data, the client of the application to be authorized can verify the user's identity after listening to the user's click operation on the batch authorization page component, as shown in Figure 4.

[0066] Figure 4 is a schematic diagram of an authentication process provided in an exemplary embodiment.

[0067] As shown in Figure 4, the client of the application to be authorized can respond to the user's click operation on the batch authorization page component, display an identity verification page to the user, and collect the user's identity information through the identity verification page. Then, it can send an authorization gateway page retrieval request carrying the user's identity information to the server. After receiving the authorization gateway page retrieval request, the server of the target credit reporting platform can parse the authorization gateway page retrieval request to obtain the user's identity information, verify the user's identity information, and return the page resource information of the authorization gateway page to the client of the application to be authorized after successful verification.

[0068] The aforementioned identity information may include, for example, the user's name and ID number, the user's facial image data, and the verification code information sent by the user.

[0069] In practical application scenarios, since users may authorize multiple applications with different business attributes and data usage purposes, in order to achieve refined permission management and risk control, the target credit scoring platform's server can also deploy multiple authorization management systems. These different authorization management systems are used to manage user authorization for applications in different application clusters. The applications in different application clusters are divided according to the business relationships between the different applications.

[0070] The aforementioned business relationships can refer to the collaborative relationships between applications in terms of service scenarios, data usage purposes, target user groups, functional logic, or underlying data models.

[0071] For example, applications in the same consumer finance scenario (such as credit loans, installment shopping, and pay-later services) focus their demand for users' personal credit data on authorized fields such as credit history, repayment behavior, and debt level. On the other hand, applications in the same travel service scenario (such as ride-hailing, bike-sharing, and car rental platforms) are more concerned with whether users have a history of skipping fares or defaulting on payments. Therefore, based on this kind of relationship, applications with similar functions and consistent data usage can be grouped into the same application cluster.

[0072] In addition, due to the distinct closed-loop ecosystem characteristics of internet applications, different large digital platforms have built comprehensive closed-loop service systems covering multiple fields such as payment, social networking, e-commerce, entertainment, and local services, based on their core products. Within these systems, various applications within the same ecosystem typically share a unified user identity system, account system, and data infrastructure. Furthermore, their business logic and usage scenarios for users' personal credit data exhibit strong consistency and interconnectivity. Therefore, based on these relationships, applications belonging to the same ecosystem can be categorized into the same application cluster.

[0073] For example, an ecosystem centered around an e-commerce platform includes various applications covering areas such as online shopping, digital payments, and consumer credit. The authorization requirements of these applications for users' personal credit data are often closely related to indicators such as users' transaction frequency, payment ability, and performance stability.

[0074] For example, an ecosystem centered on a social platform includes various applications covering multiple aspects such as instant messaging, social finance, and office collaboration. The authorization requirements of these applications for users' personal credit data are often closely related to indicators such as users' personal credit assessment and social relationship chain verification.

[0075] For example, an ecosystem centered around a content service platform includes various applications that revolve around short videos, live streaming, news reading, and related consumer finance. The authorization requirements of these applications for users' personal credit data are often closely related to indicators such as users' content interaction behavior, activity cycle, and virtual consumption habits.

[0076] Based on this, the client of the application to be authorized can respond to the user's click operation on the batch authorization page component by sending an authorization gateway page retrieval request carrying the identification information of the application to be authorized to the server of the target credit reporting platform. After receiving the authorization gateway page retrieval request, the server of the target credit reporting platform can determine the application cluster to which the application to be authorized belongs based on the identification information of the application to be authorized, and determine the authorization management system corresponding to the target application cluster to which the application to be authorized belongs from the various authorization management systems. This system will then be designated as the target authorization management system. The server can then send the page resource information of the authorization gateway page corresponding to the target management system to the client, so that the client can display the authorization gateway page corresponding to the target management system to the user.

[0077] S204: Based on the interactive operation performed by the user on the authorization gateway page, determine at least one candidate application from the candidate application list as an authorized application, and determine the authorization field corresponding to the authorized application from each credit information field to be authorized.

[0078] S206: The identification information of the authorized application and the authorization fields configured by the user for the authorized application are sent to the server of the target credit reporting platform for storage, so that the server can respond to any credit data query request sent by the application and return the user's personal credit data accordingly.

[0079] Furthermore, after the client of the application to be authorized displays the authorization gateway page to the user, it can determine at least one candidate application selected by the user from the candidate application list based on the selection operation performed by the user on each candidate application in the candidate application list on the authorization gateway page, and use it as the authorized application in this authorization operation. In addition, it can determine the credit information field to be authorized by the user from each credit information field to be authorized based on the configuration operation performed by the user on each credit information field to be authorized, and use it as the authorization field corresponding to the authorized application, as shown in Figure 5.

[0080] Figure 5 is a schematic diagram of an authorization process provided in an exemplary embodiment.

[0081] As shown in Figure 5, users can select at least one application from the candidate application list as the authorized application in this authorization operation. Then, they can perform a unified configuration operation for the authorized application on the authorization gateway page. This allows the client to determine the authorization field corresponding to the authorized application from each of the pending credit reporting fields based on the unified configuration operation performed by the user. This authorization field is then used as the unified configuration field for each selected authorized application by the user. The authorized application list, authorization fields, and user identification information can be sent to the server of the target credit reporting platform for storage.

[0082] In addition, users can configure the corresponding authorization fields for different authorized applications on the authorization gateway page. At this time, the client can determine the authorization field corresponding to the authorized application from each authorized application based on the independent configuration operation performed by the user on the authorization gateway page. The client can then send the authorized application, the authorization field corresponding to the authorized application, and the user's identification information to the server of the target credit reporting platform for storage.

[0083] Furthermore, after completing the authorization operation, the client of the application to be authorized can send a credit data query request carrying the user's identification information and the identification information of the application to be authorized to the server. This allows the server of the target credit reporting platform to determine the authorization field configured by the user for the application to be authorized based on the pre-stored correspondences after receiving the credit data query request. This field serves as the target authorization field, and the server returns the user's personal credit data to the client based on the target authorization field.

[0084] The aforementioned correspondence can refer to the correspondence between the authorized application, the corresponding authorization field of the authorized application, and the user's identification information, or it can refer to the correspondence between the list of authorized applications, the corresponding authorization field of the list of authorized applications, and the user's identification information.

[0085] The aforementioned personal credit data can be obtained by the server from historically stored personal credit data of each user, identifying the user's identification information carried in the credit data query request, and then returning the personal credit data. Alternatively, the aforementioned personal credit data can be calculated by the server after receiving a credit data query request, based on the user's identification information carried in the request, by collecting user data in real time, and then calculating the data based on the collected user data.

[0086] In the above context, user data can include user identity data, user behavior data, user performance records, etc.

[0087] The aforementioned user identity data may include, for example: name, type and number of identification document, gender, date of birth, mobile phone number, registered address, place of residence, etc.

[0088] The aforementioned user behavior data can include, for example, bank account opening status, fund flows, transaction frequency on digital payment platforms, loan records, etc.

[0089] The aforementioned performance records may include, for example, whether there are overdue payments, defaults, bad debts, compensation payments, or write-offs.

[0090] Based on this, the client can execute business operations based on the received user's personal credit data. For example, if the application to be authorized is a shared mobility service application (such as car sharing or electric bicycles), the client can combine the authorization fields such as "driving score," "historical vehicle usage compliance record," and "credit repayment behavior" contained in the user's personal credit data to conduct a comprehensive risk assessment. Based on the assessment results, the client can grant privileges such as deposit-free riding, long-term rental, and cross-city return to users with high credit scores, while prompting users with low credit scores to pay an appropriate deposit or restricting their usage scope.

[0091] For ease of understanding, the following provides a detailed explanation of the application authorization method executed by the target credit reporting platform's server during the application authorization process, as shown in Figure 6.

[0092] Figure 6 is a flowchart illustrating an application authorization method provided in an exemplary embodiment, including the following steps:

[0093] S600: Receive authorization gateway page acquisition request; the authorization gateway page acquisition request is sent by the user in response to the click operation performed by the user on the batch authorization page component contained in the authorization management page after the client of the application to be authorized displays the preset authorization management page to the user.

[0094] S602: In response to the authorization gateway page acquisition request, the preset page resource information of the authorization gateway page is sent to the client, so that the client displays the authorization gateway page to the user according to the page resource information, and determines at least one candidate application from the candidate application list included in the authorization gateway page as an authorized application according to the selection operation performed by the user in the authorization gateway page, and determines the authorization field corresponding to the authorized application from each unauthorized credit information field included in the authorization gateway page according to the configuration operation performed by the user for the authorized application in the authorization gateway page, and returns the identification information of the authorized application and the authorization field configured by the user for the authorized application.

[0095] S604: Receive and save the identification information of the authorized application and the authorization fields configured by the user for the authorized application, so as to respond to a credit data query request sent by any application and return the user's personal credit data accordingly.

[0096] In practical application scenarios, the server of the target credit scoring platform can respond to the request to obtain the authorization gateway page, obtain the user's identity information to be verified, and verify the user's identity based on the user's identity information. After successful verification, the server can send the page resource information of the preset authorization gateway page to the client.

[0097] It should be noted that the authorization fields configured by the user for each authorized application can be the same. Of course, the authorization fields configured by the user for at least some of the authorized applications can also be different from the authorization fields configured by the user for other authorized applications.

[0098] Multiple authorization management systems can be deployed on the server side of the target credit scoring platform. Different authorization management systems are used to manage user authorization for applications in different application clusters. The applications in different application clusters are divided according to the business relationship between different applications.

[0099] Based on this, the server of the target credit scoring platform can parse the request to obtain the authorization gateway page to obtain the identification information of the application to be authorized. Then, based on the identification information of the application to be authorized, it can determine the application cluster to which the application to be authorized belongs, which is the target application cluster. It can also determine the authorization management system corresponding to the target application cluster from each authorization management system, which is the target authorization management system, and send the page resource information of the authorization gateway page corresponding to the target authorization management system to the client.

[0100] Figure 7 is a schematic structural diagram of a device provided in an exemplary embodiment. As shown in Figure 7, the device 700 mainly consists of a communication interface 702, a user interface 704, a processor 706, and a data storage 708. These components are interconnected and communicate with each other through a system bus, network, or other connection mechanism 710. The communication interface 702 enables the device 700 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 702 may include a chipset and an antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 702 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 702 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 702 may also include multiple physical communication interfaces, such as a Wi-Fi interface, a Bluetooth interface, and a wide area wireless interface.

[0101] User interface 704 includes receiving user input and providing output to the user. Therefore, user interface 704 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 704 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 704 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 700 may support remote access from other devices via communication interface 702 or another physical interface (not shown). User interface 704 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 704 may also be configured as a display device for rendering or displaying text fragments.

[0102] Processor 706 may contain one or more general-purpose processors and / or special-purpose processors.

[0103] Data storage 708 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 706. Data storage 708 may include removable and non-removable components.

[0104] Processor 706 is capable of executing program instructions 718 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 708 to perform the various functions described herein. Data storage 708 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 700, enable device 700 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 706 executing program instructions 718 may result in processor 706 using data 712.

[0105] For example, program instructions 718 may include an operating system 722 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 700 and one or more applications 720 (e.g., a browser, social application, or game application). Similarly, data 712 may include operating system data 716 and application data 714. Operating system data 716 is primarily accessible to the operating system 722, while application data 714 is primarily accessible to one or more applications 720. Application data 714 may reside in a file system visible or hidden from the user of device 700.

[0106] Application 720 can communicate with operating system 722 through one or more application programming interfaces (APIs). These APIs help application 720 read and / or write application data 714, transmit or receive information via communication interface 702, receive or display information on user interface 704, etc.

[0107] In some terminology, application 720 may be simply referred to as "app". Furthermore, application 720 can be downloaded to device 700 through one or more online app stores or app markets. However, applications can also be installed on device 700 in other ways, such as through a web browser or a physical interface on device 700 (e.g., a USB port).

[0108] Please refer to Figure 8. An application authorization device can be applied to the device shown in Figure 7 to implement the technical solution of this specification.

[0109] The display module 801 is used to display a preset authorization management page to the user; the authorization management page includes a batch authorization page component;

[0110] The sending module 802 is used to respond to the user's click operation on the batch authorization page component and display the authorization gateway page to the user; the authorization gateway page includes a list of candidate applications and each credit field to be authorized corresponding to each candidate application in the list of candidate applications;

[0111] The determining module 803 is configured to determine at least one candidate application from the candidate application list as an authorized application based on the interactive operation performed by the user on the authorization gateway page, and to determine the authorization field corresponding to the authorized application from each credit information field to be authorized;

[0112] The authorization module 804 is used to send the identification information of the authorized application and the authorization fields configured by the user for the authorized application to the server of the target credit reporting platform for storage, so that the server can respond to any credit data query request sent by the application and return the user's personal credit data accordingly.

[0113] Optionally, the sending module 802 is specifically configured to, in response to the user's click operation on the batch authorization page component, send an authorization gateway page acquisition request to the server of the target credit reporting platform, and receive page resource information returned by the server; and display the authorization gateway page to the user based on the page resource information.

[0114] Optionally, the sending module 802 is specifically configured to, in response to the user's click operation on the batch authorization page component, display an identity verification page to the user and collect the user's identity information through the identity verification page; send an authorization gateway page acquisition request carrying the identity information to the server, and receive page resource information returned by the server after successful verification of the identity information.

[0115] Optionally, the determining module 803 is specifically configured to: determine at least one candidate application from the candidate application list as an authorized application based on the selection operation performed by the user on the authorization gateway page; and determine the authorization field corresponding to the authorized application from each unauthorized credit information field based on the configuration operation performed by the user on the authorization gateway page for the authorized application.

[0116] Optionally, the determining module 803 is specifically used to: determine the authorization field corresponding to the authorized application from the unified configuration operation performed by the user on the authorization gateway page for the authorized application; or, for each authorized application, determine the authorization field corresponding to the authorized application from the unauthorized credit fields based on the independent configuration operation performed by the user on the authorization gateway page for that authorized application.

[0117] Optionally, the server may deploy multiple authorization management systems. Different authorization management systems are used to manage the authorization of the user for applications in different application clusters. The applications in different application clusters are divided according to the business relationship between different applications.

[0118] Optionally, the sending module 802 is specifically configured to, in response to the user's click operation on the batch authorization page component, send an authorization gateway page acquisition request carrying the identification information of the application to be authorized to the server of the target credit reporting platform, and receive page resource information of the authorization gateway page corresponding to the target authorization management system returned by the server; the target authorization management system is the authorization management system corresponding to the target application cluster to which the application to be authorized belongs among the various authorization management systems; the target application cluster is the application cluster to which the application to be authorized belongs determined according to the identification information.

[0119] Optionally, the authorization module 804 is further configured to: send a credit data query request to the server, the credit data query request carrying the user's identification information and the identification information of the application to be authorized; receive the user's personal credit data returned by the server in response to the credit data query request, the personal credit data being determined by the server based on a target authorization field, the target authorization field being queried from pre-stored authorization fields configured by the user for each authorized application based on the user's identification information and the identification information of the application to be authorized.

[0120] Please refer to Figure 9. An application authorization device can be applied to the device shown in Figure 7 to implement the technical solution of this specification.

[0121] The receiving module 901 is used to receive an authorization gateway page acquisition request; the authorization gateway page acquisition request is sent by the user in response to the click operation performed by the user on the batch authorization page component contained in the authorization management page after the client of the application to be authorized displays the preset authorization management page to the user;

[0122] The determining module 902 is configured to respond to the authorization gateway page acquisition request by sending the preset page resource information of the authorization gateway page to the client, so that the client displays the authorization gateway page to the user based on the page resource information, and determines at least one candidate application from the candidate application list included in the authorization gateway page as an authorized application based on the selection operation performed by the user in the authorization gateway page, and determines the authorization field corresponding to the authorized application from each unauthorized credit field included in the authorization gateway page based on the configuration operation performed by the user for the authorized application in the authorization gateway page, and returns the identification information of the authorized application and the authorization field configured by the user for the authorized application.

[0123] The storage module 903 is used to receive and save the identification information of the authorized application and the authorization fields configured by the user for the authorized application, so as to respond to the credit data query request sent by any application and return the user's personal credit data accordingly.

[0124] Optionally, the determining module 902 is specifically configured to: in response to the authorization gateway page acquisition request, acquire the user's identity information to be verified; based on the identity information to be verified, verify the user's identity, and after successful verification, send the preset page resource information of the authorization gateway page to the client.

[0125] Optionally, the authorization fields configured by the user for each authorized application are the same, or the authorization fields configured by the user for at least some of the authorized applications are different from the authorization fields configured by the user for other authorized applications.

[0126] Optionally, the server may deploy multiple authorization management systems. Different authorization management systems are used to manage the authorization of the user for applications in different application clusters. The applications in different application clusters are divided according to the business relationship between different applications.

[0127] Optionally, the determining module 902 is specifically configured to: parse the authorization gateway page acquisition request to obtain the identification information of the application to be authorized; determine the application cluster to which the application to be authorized belongs based on the identification information of the application to be authorized, as the target application cluster; determine the authorization management system corresponding to the target application cluster from each authorization management system, as the target authorization management system, and send the page resource information of the authorization gateway page corresponding to the target authorization management system to the client.

[0128] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0129] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0130] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0131] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0132] What those skilled in the art will understand is:

[0133] In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0134] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0135] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0136] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0137] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0138] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0139] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. An application authorization method, the method being applied to a client of an application to be authorized, the method comprising: Display the preset authorization management page to the user; The authorization management page includes a batch authorization page component; In response to the user's click operation on the bulk authorization page component, the authorization gateway page is displayed to the user; The authorization gateway page contains a list of candidate applications, as well as each credit field to be authorized corresponding to each candidate application in the list; Based on the interactive operations performed by the user on the authorization gateway page, at least one candidate application is determined from the candidate application list as an authorized application, and the authorization field corresponding to the authorized application is determined from each credit information field to be authorized. The identification information of the authorized application and the authorization fields configured by the user for the authorized application are sent to the server of the target credit reporting platform for storage, so that the server can respond to any credit data query request sent by the application and return the user's personal credit data accordingly; wherein, the server deploys multiple authorization management systems, and different authorization management systems are used to manage the user's authorization for applications in different application clusters, and the applications contained in different application clusters are divided according to the business relationship between different applications.

2. The method as described in claim 1, wherein in response to a click operation performed by the user on the bulk authorization page component, an authorization gateway page is displayed to the user, specifically including: In response to the user's click operation on the batch authorization page component, a request to obtain the authorization gateway page is sent to the server of the target credit reporting platform, and the page resource information returned by the server is received; based on the page resource information, the authorization gateway page is displayed to the user.

3. The method as described in claim 2, in response to the user's click operation on the batch authorization page component, sending an authorization gateway page retrieval request to the server of the target credit reporting platform, and receiving page resource information returned by the server, specifically includes: In response to the user's click operation on the batch authorization page component, an identity verification page is displayed to the user, and the user's identity information is collected through the identity verification page; Send an authorization gateway page retrieval request carrying the identity information to the server, and receive page resource information returned by the server after successfully verifying the identity information.

4. The method as described in claim 1, wherein at least one candidate application is determined from the candidate application list as an authorized application based on the interactive operation performed by the user on the authorization gateway page, and the authorization field corresponding to the authorized application is determined from each pending authorization credit field, specifically including: Based on the selection operation performed by the user on the authorization gateway page, at least one candidate application is determined from the candidate application list as an authorized application; and based on the configuration operation performed by the user on the authorization gateway page for the authorized application, the authorization field corresponding to the authorized application is determined from each unauthorized credit information field.

5. The method as described in claim 4, wherein the authorization field corresponding to the authorized application is determined from the unauthorized credit information fields based on the configuration operation performed by the user on the authorization gateway page for the authorized application, specifically includes: Based on the unified configuration operation performed by the user on the authorization gateway page for the authorized application, the authorization field corresponding to the authorized application is determined from each credit information field to be authorized; Alternatively, for each authorized application, the authorization field corresponding to the authorized application can be determined from each of the pending credit information fields based on the independent configuration operation performed by the user on the authorization gateway page for that authorized application.

6. The method as described in claim 2, in response to the user's click operation on the batch authorization page component, sending an authorization gateway page retrieval request to the server of the target credit reporting platform, and receiving page resource information returned by the server, specifically includes: In response to the user's click operation on the batch authorization page component, a request to obtain the authorization gateway page carrying the identification information of the application to be authorized is sent to the server of the target credit reporting platform, and the page resource information of the authorization gateway page corresponding to the target authorization management system is returned by the server. The target authorization management system is the authorization management system that corresponds to the target application cluster to which the application to be authorized belongs among the various authorization management systems; The target application cluster is the application cluster to which the application to be authorized belongs, determined based on the identification information.

7. The method of claim 1, further comprising: Send a credit data query request to the server, the credit data query request carrying the user's identification information and the identification information of the application to be authorized; The server receives the user's personal credit data returned in response to the credit data query request. The personal credit data is determined by the server based on a target authorization field. The target authorization field is retrieved from the authorization fields configured by the user for each authorized application in a pre-stored manner, based on the user's identification information and the identification information of the application to be authorized.

8. An application authorization method, the method being applied to a server of a target credit scoring platform, wherein the server deploys multiple authorization management systems, different authorization management systems being used to manage user authorization for applications within different application clusters, the applications within different application clusters being categorized based on business relationships between different applications, the method comprising: Receive the request to obtain the authorization gateway page; The authorization gateway page acquisition request is sent by the user in response to a click operation performed by the user on the batch authorization page component contained in the authorization management page after the client of the application to be authorized displays the preset authorization management page to the user; In response to the request to obtain the authorization gateway page, the client sends the preset page resource information of the authorization gateway page to the client, so that the client displays the authorization gateway page to the user based on the page resource information, and determines at least one candidate application from the candidate application list included in the authorization gateway page as the authorization application based on the selection operation performed by the user in the authorization gateway page, and determines the authorization field corresponding to the authorization application from each credit information field to be authorized included in the authorization gateway page based on the configuration operation performed by the user for the authorization application in the authorization gateway page, and returns the identification information of the authorization application and the authorization field configured by the user for the authorization application. The system receives and saves the identification information of the authorized application and the authorization fields configured by the user for the authorized application, so as to respond to a credit data query request sent by any application and return the user's personal credit data accordingly.

9. The method as described in claim 8, wherein in response to the authorization gateway page acquisition request, page resource information of a preset authorization gateway page is sent to the client, specifically including: In response to the authorization gateway page request, obtain the user's identity information to be verified; Based on the identity information to be verified, the user's identity is verified, and upon successful verification, the page resource information of the preset authorization gateway page is sent to the client.

10. The method of claim 8, wherein the authorization fields configured by the user for each authorized application are the same, or the authorization fields configured by the user for at least some of the authorized applications are different from the authorization fields configured by the user for other authorized applications.

11. The method as described in claim 8, wherein in response to the authorization gateway page acquisition request, page resource information of a preset authorization gateway page is sent to the client, specifically including: The authorization gateway page retrieval request is parsed to obtain the identification information of the application to be authorized; Based on the identification information of the application to be authorized, the application cluster to which the application to be authorized belongs is determined, and it is used as the target application cluster; From the various authorization management systems, the authorization management system corresponding to the target application cluster is determined as the target authorization management system, and the page resource information of the authorization gateway page corresponding to the target authorization management system is sent to the client.

12. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-11 by executing the executable instructions.

13. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-11.

14. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-11.

Images