巴西专利BR112013009278B1 USER TERMINAL AND METHOD FOR IMPOSING A SERVER GENERATED APPLICATION USE POLICY

专利PDF首页>>巴西专利

专利附录

专利说明

权利要求

类似技术

同族专利

引用文献

法律状态

优先权

专利摘要:
ELECTRONIC DEVICE AND APPLICATION METHOD OF A COMPUTER GENERATED APPLICATION USE POLICY. The present invention relates to non-transitory, computer-readable systems, methods and means for enforcing application usage policies. As part of an application purchase transaction, the application distributor creates a unique proof of purchase receipt (1002). This receipt can be attached to the application and sent to the buyer. Each machine can maintain an authorization file (1004) that lists the users authorized to use applications on that machine. A system configured to implement the method confirms that a user is authorized to use an application on a machine based on a proof of purchase receipt (1002) and authorization file (1004) are both valid, the system checks whether the user's quota identifier on the receipt is contained in the authorization file. If so, the user can be considered authorized to use the application on the machine.
公开号:BR112013009278B1
申请号:R112013009278-5
申请日:2011-10-10
公开日:2020-11-24
发明作者:Jean-Pierre Ciudad；Augustin J Farrugia；David M'Raihi；Bertrand Mollinier Toublet；Gianpaolo Fasoli；Nicholas T Sullivan
申请人:Apple Inc；
IPC主号:

专利说明:

[0001] [001] This application claims as priority the US patent application Serial Number 12 / 907,915, entitled “APPLICATION USAGE POLICY ENFORCEMENT”, filed on October 19, 2010, which is incorporated here as a reference in its entirety. BACKGROUND 1. Technical Field
[0002] [002] The present invention refers to the application policies of application use and, more specifically, to prevent the unauthorized execution of the application's execution on a computer. 2. Introduction
[0003] [003] An important feature of computer software is that a single item of software can be installed on multiple computers without the need to change the software. This is advantageous for those who develop the software because you can develop the software once and then distribute it to many different users without any additional work. It is also advantageous for the user because he or she can move their software from one machine to another, for example, when the user purchases a new computer. The portability of the software also makes it possible for a user to purchase a single copy of the software and install it simultaneously on multiple computers, which in some situations may not be desirable. For example, software can be very expensive to produce and have a very small target market. In that case, an unauthorized copy may prevent the developer from recovering his expenses.
[0004] [004] To avoid unauthorized copying, software developers often employ an installation process that requires a unique product key for each installation of the software. This procedure prevents unauthorized copying, but it also makes it difficult for a user to migrate from one machine to another. In addition, this solution is not practical when a software developer has a policy that allows a user to install the software on a specific number of machines. SUMMARY
[0005] [005] Additional features and advantages of the description will be shown in the description below, and in part will be obvious from the description, or can be learned by practicing the principles described here. The characteristics and advantages of the description can be understood and obtained through the instruments and combinations particularly pointed out in the attached embodiments. These and other features of the description will become more apparent as a whole from the accompanying description and embodiments below, or can be learned by practicing the principles shown here.
[0006] [006] Non-transitory computer-readable systems, methods, and storage media for applying application usage policies are described here.
[0007] [007] In an application server mode, a system configured to practice the method is configured to receive a purchase request. In response to the request, the system can create a proof of purchase receipt for that purchase. The receipt may include various items of information about the purchase transaction, such as the user's account identifier, the application identifier, the version number of the application, the date of purchase, and ratings for parental control for the application. The system can sign the receipt, attach it to the application, and send the set to the customer's device making the request.
[0008] [008] In a device to client mode, when a user wants to use an application on a machine, the system can confirm that the use is in compliance with the usage policies. When a user purchases an app, a proof of purchase receipt for the app is included with the app. To operate the application purchased on a particular customer device, the account identifier associated with the purchased application must be authorized on the customer's device. Each customer device can maintain an authorization file that can specify a customer identifier for that customer machine and all user identifiers authorized to use applications on that customer's device. When a user tries to use an application, the system can confirm that the proof of purchase receipt and authorization file are valid. In addition, the system can confirm that the user specified on the proof of purchase receipt is in the authorization file. In some modalities, if the user is not in the authorization file, the system can make a request to authorize the user.
[0009] [009] As an example of an application mechanism, the system may include a disallowance counter to try to prevent a user from circumventing the application's usage policy. A deauthorization count field can be included on the application's proof of purchase receipt and authorization file. A deauthorization count can also be maintained by the system. When a user makes a purchase request for an application, the system can set up a proof of purchase receipt for that purchase that includes the current disallowance count for the user. When a user tries to use an application, the system can confirm that the proof of purchase receipt and authorization file are valid. In addition, the system can confirm that the user specified on the proof of purchase receipt is in the authorization file. Finally, the system can confirm that the deauthorization count on the receipt is below or is equal to the deauthorization count in the authorization file. This application mechanism can provide a simple way for a user to download the application a programmed number of times, according to the terms of the application usage policy. BRIEF DESCRIPTION OF THE DRAWINGS
[0010] [0010] In order to describe the manner in which the advantage described above and other advantages and characteristics of the description can be obtained, a more specific description of the principles briefly described above will be provided with reference to specific modalities thereof which are illustrated in the attached drawings . Understanding that these drawings illustrate only exemplary modalities of the description and are not, therefore, considered as limiting its scope, the principles here are described and explained with specificity and additional details through the use of the attached drawings, in which:
[0011] [0011] Figure 1 illustrates an exemplary system configuration for distribution and use of the application;
[0012] [0012] Figure 2 illustrates an example application purchase;
[0013] [0013] Figure 3 illustrates an exemplary application purchase receipt;
[0014] [0014] Figure 4 illustrates an exemplary method for purchasing the application;
[0015] [0015] Figure 5 illustrates an exemplary authorization file;
[0016] [0016] Figure 6 illustrates an example authorization request;
[0017] [0017] Figure 7 illustrates an example situation for purchase authorization;
[0018] [0018] Figure 8 illustrates an example method for application launch authorization;
[0019] [0019] Figure 9 illustrates an exemplary method for confirming an application;
[0020] [0020] Figure 10 illustrates an exemplary purchase receipt and authorization file with deauthorization counters;
[0021] [0021] Figure 11 illustrates an exemplary method modality for application verification using deauthorization counters;
[0022] [0022] Figure 12 illustrates a situation of using an exemplary deauthorization counter; and
[0023] [0023] Figure 13 illustrates an exemplary system modality. DETAILED DESCRIPTION
[0024] [0024] Several types of description are discussed in detail below. Although specific implementations are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the relevant technique will recognize that other components and configurations can be used without departing from the spirit and scope of the invention. This description addresses the need in the technique for improved methods of selecting targeted content presented to a user based on descriptive characteristics of user interaction and / or user interaction with one or more items of targeted content.
[0025] [0025] The system and method described here are particularly useful for applying application usage policies on a computer. An exemplary system configuration 100 for application distribution and use is illustrated in Figure 1, in which electronic devices 102, 104 communicate over a network 110 with an electronic application distributor 112. The system can be configured for use in a wide area network, such as the one illustrated in figure 1. However, the present principles are applicable in a wide variety of network configurations that facilitate the intercommunication of electronic devices. For example, each of the system components 100 in Figure 1 can be implemented in a localized manner or distributed over a network.
[0026] [0026] In system 100, user terminals 102 and 104 interact with the application distributor 112, by direct and / or indirect communication, to obtain computer programs, also known as applications. Any number or type of user terminals can interact with the application distributor 112. For example, a user terminal 102 can be a desktop computer; a laptop; a communication device that fits in the hand, for example, a cell phone, a smartphone, a tablet, or any other type of device using multiple or non-persistent network sessions; etc. User terminal 102 makes a request, such as a purchase request, to application distributor 112. The application distributor 112 responds either by sending the requested content to the requesting user terminal 102 or by denying the request. A request may be denied, for example, due to a failure on the part of the user terminal 102 to provide an appropriate payment method.
[0027] [0027] To facilitate the application of the application usage policies, the application distributor can provide the requesting user's terminal with a receipt of proof of purchase of the application together with the purchased application. Figure 2 illustrates an example application purchase 200. On the purchase of an exemplary application 200, the user terminal 102 makes a purchase request to the application distributor 112. As part of the purchase request, user terminal 102 can provide account information to the requesting user. In some configurations, the account information can be a username and password. In other configurations, account authorization can occur as a separate interaction with the application distributor 112, and thus the account information can be a unique account identifier, such as DSid. After receiving the purchase request, the application distributor 112 can create an application set 206 consisting of the application 208 and the application receipt of proof of purchase 210. The application distributor 112 can then send the application set 206 to user terminal 102. As will be discussed in more detail below, the proof of purchase receipt for the app can be used later to help enforce a usage policy for the app.
[0028] [0028] A purchase transaction includes any type of transaction for a recipient to obtain an application and does not necessarily have to require a cash or other exchange. The purchase transaction may include a third party giving the application as a gift to the recipient, or the recipient may redeem a coupon, promotional code, or similar instrument in exchange for the application. In some cases, a purchase request can be made for a free application. Regardless of whether a monetary exchange is required to obtain the app, the app distributor can provide a proof of purchase receipt of the app with the app.
[0029] [0029] An application proof of purchase receipt may include a variety of information, as illustrated in the example proof of purchase receipt 300 in figure 3. The application proof of purchase receipt may include more or less information regarding what is shown in figure 3. Body 302 of the proof of purchase receipt can include various account information associated with the user who purchased the application. The user can be an individual, a group of individuals, or an organization. Account information can include the user's identity, such as a username. Account information can also include a unique account identifier for the user, such as DSid. In some configurations, instead of including the plain text DSid, the body 302 of the proof of purchase receipt may include a unique representation of the DSid. For example, the exclusive representation can be a representation of a DSid path, for example f (DSid). In some cases, exclusive representation can be used to increase the security of the receipt and / or the user's privacy. Body 302 of the proof of purchase receipt may also include several items of information about the purchased application. For example, body 302 of the proof of purchase receipt may include the identity, version number, and parental control rating of the purchased application. In some cases, additional information about the application may be included on the receipt, such as an application signature. In addition, body 302 of the proof of purchase receipt may include the date of purchase.
[0030] [0030] In some configurations, a body 302 of the proof of purchase receipt may include additional and / or alternative information. In addition, the organization of the information within the 300 proof of purchase receipt may vary with the system configuration. In one variation, a server retains a full or partial copy of the application proof of purchase receipt 300.
[0031] [0031] In some configurations, receipt 300 of proof of purchase may be in plain text, which would make it readable to any user who can understand the file layout. To prevent and / or detect unauthorized modification of proof of purchase receipt 300, proof of purchase receipt 300 may include a receipt signature 304. The receipt signature 304 can be any digital signature that can be used to detect unauthorized modification of the proof of purchase receipt. For example, application distributor 112 can use a cryptographic hash function to generate a digital signature of body 302 of the proof of purchase receipt. In some configurations, the application distributor 112 may use a public key system to generate the digital signature. In this case, the application distributor 112 uses its private key to generate the receipt signature 304. A user terminal, the application distributor, and / or any other device with access to the public key of the application distributor can then confirm receipt 300. Alternatively, the application distributor 112 can use a key system to generate the signature 304 receipt. In this case, unless the application distributor 112 shares your private key, only the application distributor can verify receipt 300.
[0032] [0032] Figure 4 is a flow chart illustrating steps in an example method 400 for an application purchase that includes a proof of purchase receipt. For the sake of clarity, this method is discussed in terms of an exemplary system such as the one shown in figure 1. Although specific steps are shown in figure 4, in other modalities, a method may have more or less steps than shown . The method steps and other figures can be implemented in the order or combination shown, or in any other order or combination.
[0033] [0033] At several points, the application distributor 112 receives a request from a user to purchase an application (402). The purchase request can come from any user terminal with access to the application distributor 112. As described above, the purchase requisition may include account information for the user making the request that can be used to facilitate the transaction, such as the user's account identifier.
[0034] [0034] In response to the purchase request, the application distributor 112 assembles an application proof of purchase receipt (404), such as receipt 300 in figure 3. The application proof of purchase receipt may be unique to the transaction. For example, even if the user previously purchased the app, the proof of purchase receipt associated with that purchase request will be different. However, in some configurations, the proof of purchase receipt may be exclusive to the user, application pair, rather than the transaction. After assembling the application proof of purchase receipt, the application distributor 112 creates an application set, based on the application proof of purchase receipt and the application (406), and sends the application set to the user who is making the request (408).
[0035] [0035] After purchasing an application, it may be possible to use that application on multiple user terminals. To prevent a user from abusing this capability, an application developer can institute a usage policy that limits the number of user endpoints on which the application can be used at any one time. For example, suppose an application costs ten dollars. A user could buy the app and then sell a copy of the app to nine friends for a dollar. Each of the ten users could then obtain a copy of the ten-dollar application for one dollar. In some cases, an application developer may agree with this situation; however, in other cases, this activity could prevent the developer from recovering its development costs. To restrict such activity, a policy can be established to limit the number of copies to, for example, five machines. One way to ensure that a user operates an application on only a specific number of machines is to have the user authorize each machine on which he or she wants to use the application.
[0036] [0036] An authorization file, which can be found on the user's machine, can be used to facilitate user authorization. Figure 5 illustrates an exemplary authorization file 500. The authorization file 500 can include an authorization file body 502. The authorization file body 502 can include a unique machine identifier for the machine associated with authentication file 500. The unique machine identifier can be an identifier that can be linked to a user terminal. For example, the various hardware components in a computer can be associated with a unique identifier, such as a serial number. One or more of these serial numbers can be used to create a unique machine identifier.
[0037] [0037] Body 502 of authorization file may also contain one or more unique account identifiers, for example, DSid. The account identifiers contained in the authorization file 500 indicate users who are authorized to use applications purchased on the machine. In some configurations, instead of including the plain text DSid, the authorization file body 502 may include a unique representation of the DSid. For example, the exclusive representation can be a representation of DSid, for example f (DSid). In some cases, exclusive impersonation can be used to increase the security of the receipt and / or user privacy.
[0038] [0038] In some configurations, an authorization file body 502 may include additional and / or alternative information. In addition, the organization of information within the authorization file 500 may vary with system configuration.
[0039] [0039] In some configurations, the authorization file 500 may be in plain text, which would make it readable to any user who can understand the layout of the file. To prevent and / or detect unauthorized modification of authorization file 500, authorization file 500 may include a signature 504 of the authorization file. The 504 signature on the authorization file could be any digital signature that can be used to detect unauthorized modification of the authorization file. For example, the application distributor 112 can use a cryptographic hash function to generate a digital signature of the 502 body of the authorization file. In some configurations, the application distributor 112 may use a public key system to generate the digital signature. In this case, the application distributor 112 uses its private key to generate the signature 504 of the authorization file. A user terminal, the application distributor, and / or any other device with access to the application distributor's public key can then confirm the authorization file 500. Alternatively, the application distributor 112 can use a private key system to generate the 504 signature of the authorization file. In this case, unless the application distributor 112 shares its private key, only the application distributor can confirm the authorization file 500.
[0040] [0040] An authorization request can be made to the application distributor or to any other device responsible for authorization for users in the system. The authorization file can be used to keep track of which authorized users are allowed to operate applications on a given user terminal, while the server can keep records of authorization to keep track of how many machines and / or exactly for which machines each user is authorized. Authorization records on the server can be used to ensure that a user is not authorized on more machines than those permitted by the usage policy.
[0041] [0041] Figure 6 illustrates an example 600 user authorization situation. To authorize a user on a machine, server 606 receives the authorization file 602 and the unique account identifier 604 from the client. The server 606 then checks the authorization records 608 to confirm that the user is no longer authorized for their maximum allowed number of machines according to the usage policy. In this example, the DSid8 user is authorized for only one machine, which is less than the limit, so that the 606 server can authorize the user. To authorize the user, the server 606 updates the entries in the authorization records for the user to include the machine identifier in the authorization file 602, that is, M1. This produces 610 authorization records. The server also updates the authorization file by adding the user's account number, that is, f (DSid8), and renouncing the file. The server 606 then returns the updated authorization file 612 to the user's machine. In some configurations, the 606 server can keep other information in authorization records. Other authorization methods are also possible using all or part of these steps.
[0042] [0042] In some configurations, the usage policy can be static across all users and all applications, or the usage policy can be user specific and / or application specific. For example, a usage policy can be designed so that any user can be authorized to use any of the applications they have purchased on up to five machines at any one time. However, the system can also be configured so that a usage policy can be specified for an individual application. For example, one application could allow users to use the application on 10 machines, while another application could only allow the user to use the application on 4 machines. To support a variable usage policy scheme, the 606 server may need to store additional information in authorization records.
[0043] [0043] In some configurations, user authorization can occur at the moment the user purchases the application. Figure 7 illustrates an exemplary situation 700 for authorization at the time of purchase. In method 700, the user's terminal 102 makes a purchase request to the application distributor 112. In addition to account information, such as DSid, the purchase request may include an authorization file 706 which is located at user terminal 102. The application distributor 112 can create the application set 708 using method 400 in figure 4 and can run authorization method 600 in figure 6 to update authorization records and produce authorization file 710. The application distributor 112 can send authorization set 710. The application distributor 112 can then send the application set and the updated authorization file 710 to terminal 102 of the user making the request. In some configurations, the application distributor 112 acts as an intermediary for the authorization request and simply passes the authorization request to another device or server that will return the authorization file to the application distributor 112. In some cases, the user is authorized at the user's 102 terminal before making the purchase request. In that case, the application distributor 112 may either return the authorization file unchanged or not return the file. In some configurations, the user terminal can determine that the user is authorized for the machine without making an authorization request to the server.
[0044] [0044] In some cases, authorization at the time of purchase may be unnecessary because the user has no intention of using the application on the machine from which he or she purchased the application. For example, a user may have a slow internet connection at home, but a very fast connection at work. In some cases, internet connection speeds may not matter, but for large applications a slow network connection can prevent a user from purchasing a particular application. For a better shopping experience for the user, the user can decide to buy the app at work and then transfer the app to the user's home computer. For example, the user can transfer the application to a disc, for example, a CD-ROM, DVD, USB drive, etc., and then transfer the application to the home computer, or the user can establish a direct high-speed connection between the user's work computer and the home computer, for example, via an Ethernet connection. In addition, to allow the user to copy the application to more than one machine, authorization can occur when the user tries to use the application.
[0045] [0045] Figure 8 illustrates an example situation 800 for authorization when launching an application. In this situation, the user makes a purchase request via user terminal 102. The purchase request is sent to application distributor 112 where application set 806 is prepared using method 400 in figure 4. Application set 806 is sent to user terminal 102. At some point, application set 806 is copied to user terminal 104 where the user attempts to use the application. Upon application launch, the user terminal sends an authorization request to server 606. In some configurations, server 606 and application distributor 112 may be the same. However, in other cases, server 606 and application dispatcher 112 may be different. As part of the authorization request, server 606 receives authorization file 812 and identifier 814 from the user's account. Server 606 executes authorization method 600 in figure 6 and returns the updated authorization file 816 to the user's terminal 104. Now that the user is authorized on the machine, the user can use the application. In some configurations, a user may already be authorized to use applications on the machine. In that case, updates to the authorization file are not required. In addition, in some cases, the user's terminal determines that the user is authorized without making an authorization request to the server.
[0046] [0046] The 600 authorization situation for the user in figure 6 only prevents a user from being authorized to operate applications on a number greater than a specified number of machines. By incorporating the application proof of purchase receipt created at the time of purchase, application confirmation can apply an application usage policy that limits the use of a particular application to a specific number of machines or instances at any given time. For example, the application can be five separate instances on five different guest virtual machines that are all on one physical host machine. When a user purchases an app, a proof of purchase receipt for the app is included with the app. To use an application purchased on a particular machine, the account identifier on the proof of purchase receipt must be authorized on the machine. As described above, each machine can maintain a single authorization file that can specify the machine identifier for the machine and all user account identifiers authorized to operate applications on the machine. If the account identifier on the proof of purchase receipt is in the authorization file, the application can be used on the machine. However, if the user associated with the application is not authorized on the machine, the user can be authorized using an authorization method such as method 600 in figure 6. Both the proof of purchase receipt and the authorization file can be confirmed to avoid unauthorized modification of the proof of purchase receipt and / or authorization file and to ensure that the receipt belongs to the application and the authorization file belongs to the machine.
[0047] [0047] The exemplary application confirmation method 900 in figure 9 can be used to apply an application usage policy that is addressed to a limitation of the user making the purchase to a specific number of machines. Confirmation method 900 can use receipt 300 of proof of purchase of the application in figure 3 and authorization file 500 in figure 5. For the sake of clarity, method 900 is discussed in terms of an example system 100 as shown in figure 1. Although specific steps are shown in figure 8, in other modalities a method may have more or less steps than those illustrated.
[0048] [0048] The application verification method 900 can be used each time a user starts an application and can be executed locally by the machine on which the application is located. However, the system can also be configured so that this confirmation of the application is performed less frequently, for example, at the first launch of the application. In addition, application confirmation can be performed by making a confirmation request to a server, or it can be a combination of local and remote actions.
[0049] [0049] Upon application launch, user terminal 102 receives a request to confirm an application based on a proof of purchase receipt 300 and an authorization file 500 (902). As part of the application confirmation, the user terminal 102 can confirm the proof of purchase receipt 300, first checking that the receipt signature is valid (904). If the signature is not valid, then it is likely that the receipt has been changed, then the confirmation process is aborted and confirmation fails. If the signature is valid, user terminal 102 verifies that the application identifier on the receipt is the same as the identifier of the application being confirmed (906). If it is not the same, the verification fails. If the application identifier is the same, user terminal 102 checks whether the application version number on the receipt is the same as the version number of the application being confirmed (908). If the version number does not match, the confirmation method fails, otherwise the confirmation continues.
[0050] [0050] Confirmation method 900 may also include confirmation of authorization file 500. To confirm authorization file 500, user terminal 102 checks whether the signature on the file is valid (910). If the signature is not valid, then it is likely that the authorization file has been changed, so the confirmation process is aborted and confirmation fails. If the signature is valid, the user's terminal 102 verifies that the machine identifier in the authorization file is the same identifier for the user's terminal 102 (912). If not, the verification fails. If the machine identifier does not match, confirmation continues.
[0051] [0051] Depending on the configuration, steps 904, 906 and 908 can be performed before, after, or in parallel with steps 910 and 912. In addition, steps 904-912. In addition, steps 904-912 do not have to be performed, but by performing the steps you can obtain a level of certainty that the files are unchanged and correspond to the application and the machine. Then confirm receipt 300 and authorization file 500. User terminal 102 checks whether the account number on the receipt, for example, f (DSid) is in the authorization file (914). If so, the user who purchased the application is authorized on the machine, so that the application can be launched (916). If the user who purchased the application is no longer authorized, user terminal 102 can make an authorization request to application distributor 112 (918). If the authorization request is successful (920), the application can start (916), otherwise confirmation fails.
[0052] [0052] In some configurations, the confirmation method 900 can occur within the application. In this case, the action taken upon confirmation of a failure depends on the developer of the application. For example, if the confirmation fails, the application could be stopped. Alternatively, upon confirmation failure, the application could continue its execution, but only limited functionality would be available. In addition, depending on the configuration, the application may not be able to request authorization from the user.
[0053] [0053] Using the verification method 900 described above, the user associated with a purchased application can use the application on the number of machines specified in the usage policy. For example, if the maximum number of machines is five, the user can copy the application to five different machines and go through the authorization process on each machine. If the user wants to use the application on a sixth machine, the user has to deauthorize one of the machines already authorized. To do this, the user can send a “disallow” request via one of the authorized machines. Alternatively, in some configurations, the user can send a “disallow all” request for any machine, which will have the effect of disallowing all machines on which the user was authorized. After deauthorizing a machine, the user can go back to the sixth machine and authorize it. At that point, if the verification method 900 is successful, the user can use the application.
[0054] [0054] In some cases, a user may try to circumvent the maximum machine usage policy. One way in which a user can attempt to do this is described below. Suppose that the user associated with the purchased application is already authorized for the maximum number of machines, for example, five. To release an authorization, the user disallows a machine. However, before issuing the “disallow” request, the user makes a copy of the authorization file on the machine. After deauthorization, the user copies the deauthorization file back into place. The machine now understands that the user is authorized even though the user has been disallowed.
[0055] [0055] To face this fraudulent action, a deauthorization count field can be added to the application's proof of purchase receipt and authorization file. In addition, a deauthorization count can also be maintained on the server. Figure 10 illustrates an exemplary proof of purchase receipt 1002 and an authorization file 1004 with deauthorization count fields. In authorization file 1004, a separate deauthorization count can be associated with each authorized count identifier. Each time a user deauthorizes a machine, the deauthorization count on the server associated with the count identifier can be increased. When a user purchases a new application, the deauthorization count in the deauthorization record associated with the user can be included in the application's proof of purchase receipt. In addition, when a user authorizes a machine, the deauthorization count associated with that count identifier can be included in the authorization file.
[0056] [0056] The deauthorization count can also be incorporated into the application confirmation method. When a user tries to use an application, the confirmation method can perform all the steps described in confirmation method 900. However, the confirmation method can also verify that the deauthorization count on the receipt is less than or equal to the deauthorization count in the file authorization. If this check fails, the user may be prevented from using the application on that machine.
[0057] [0057] Figure 11 illustrates an example 1100 confirmation method for an example application that uses deauthorization counters. Confirmation method 1100 can use proof of purchase receipt 1002 and authorization file 1004 in figure 10. For clarity, method 1100 is discussed in terms of an exemplary system as shown in figure 1. Although specific steps are shown in figure 10, in other modalities, a method may have more or less steps than illustrated.
[0058] [0058] The 1100 application confirmation method can be used each time a user starts an application and can be run locally by the machine on which the application is located. However, the system can also be configured so that application confirmation is performed less frequently, as in the first application launch. In addition, application confirmation can be performed by making a confirmation request to a server, or it can be a combination of local and remote actions.
[0059] [0059] Upon application launch, user terminal 102 receives a request for confirmation of an application based on a receipt 1002 of proof of purchase and an authorization file 1004 (1102). User terminal 102 can then confirm that proof of purchase receipt 1002 and authorization deposit 1004 are valid using steps similar to 904-912 in figure 9 (1104 and 1106). If any of the validation steps fail, the confirmation method aborts and the confirmation fails. Depending on the configuration, step 1104 can be performed before, after, or in parallel with step 1106. In addition, steps 1104 and 1106 do not have to be performed, but by performing the steps you can obtain a level of certainty that the files are unchanged and correspond to the application and the machine.
[0060] [0060] After confirming receipt 1002 and authorization file 1004, user terminal 102 checks whether the account number on the receipt, for example, f (DSid) is in the authorization file (1108). If so, the user who purchased the application is authorized on the machine, and confirmation can proceed to verify deauthorization counts. If the user who purchased the application is no longer authorized, user terminal 102 can make an authorization request to the application's distributor 112 (1110). If the authorization request is successful (1114), user terminal 102 can proceed and check deauthorization counts.
[0061] [0061] In step 1112, user terminal 102 confirms the deauthorization counts by checking whether the deauthorization count on the receipt is less than or equal to the deauthorization count in the authorization associated with the account identifier. If so, confirmation was successful and user terminal 102 can start the application (1116). If the confirmation of the deauthorization count fails, it is likely that an intensive deauthorization action has occurred, so that the user is prevented from using the application on the machine.
[0062] [0062] As with confirmation method 900, confirmation method 1100 can be executed within the application. In this case, the action taken upon confirmation of a failure depends on the developer of the application. For example, upon confirmation of the failure, the application could stop working. Alternatively, upon failure confirmation, the application could continue to function, but only limited functionality could be available. In addition, depending on the configuration, the application may not be able to request authorization from the user.
[0063] [0063] Figure 12 illustrates a situation of using an exemplary deauthorization counter. In this situation, the user with a DSidl account identifier is currently authorized on five machines: M1-M5. The user also wants to be able to use applications on a sixth M6 machine, but the usage policy limits the number of authorizations to five. This initial situation condition is reflected in the authorization files for machines M5 and M6 and in authorization records on the server (1210). The authorization file for the M5 machine contains a release for DSicM with an associated deauthorization count of zero. The authorization file for the M6 machine is empty. Authorization records on the server show that DSID1 is authorized on machines M1-M5 and that the user has not deauthorized any machines.
[0064] [0064] In an attempt to use applications on a sixth M6 machine, the user makes a copy of the authorization file on M5 and then disallows the machine. These actions are reflected in the authorization file on the M5 machine and in the authorization records on the server (1220). The authorization file for the M5 machine is now empty. In addition, the deauthorization count is increased to one and M5 has been removed from the list of authorized machines in the authorization records on the server.
[0065] [0065] The user now authorizes the M6 machine. This action results in two changes, which are reflected in the M5 and M6 machines and in the server (1230). First, the authorization file on machine M6 is updated to include DSidl with a deauthorization count of 1. Second, authorization records on the server are updated to include machine M6 in the list of authorized machines.
[0066] [0066] After authorization, the user replaces the authorization file with the old authorization file and purchases an application. The changes are reflected in the M5 and M6 machines and in the server (1240). The deauthorization count on the proof of purchase receipt is 1. When the user tries to use the application on the M5 machine, the machine can confirm the application using confirmation method 1100. As the deauthorization count on the proof of purchase receipt is higher than the deauthorization count in the authorization file, verification method 1100 will fail in step 1112. The user can then be prevented from using the application on the machine.
[0067] [0067] The description now turns to a discussion of a general-purpose computing device. All of the components shown in Figure 13 and discussed below, or part of them, can be used to implement the various devices and infrastructure elements discussed above. Referring to figure 13, an exemplary system 1300 includes a general purpose computing device 1300, including a processing unit (CPU or processor) 1320 and a system bus 1310 that couples various system components including system memory 1330, such as read-only memory (ROM) 1340 and random access memory (RAM) 1350 for the 1320 processor. The 1300 system may include a 1322 high speed memory cache directly connected, in close proximity, or integrated as part from the 1320 processor. The 1300 system copies data from the 1330 memory and / or the 1360 storage device to the 1322 cache for quick access by the 1320 processor. Thus, the 1322 cache provides a performance boost that avoids 1320 processor delays while waiting by data. These and other modules can be configured to control the 1320 processor and make it perform various actions. Another 1330 system memory may be available for use as well. The 1330 memory can include different multiples of memory with different performance characteristics. It can be appreciated that what is disclosed here can operate on a 1300 computing device with more than one 1320 processor or on a group or cluster of computing devices together on the same network to provide greater processing capacity. The 1320 processor can include any general purpose processor and a hardware module or software module, such as module 1 1362, module 2 1364, and module 3 1366 stored in storage device 1360, configured to control processor 1320 and also a special purpose processor where software instructions are incorporated into the design of the actual processor. The 1320 processor can essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, a memory controller, a cache, etc. A multi-core processor can be symmetric or asymmetric.
[0068] [0068] The 1310 system bus can be any one of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input / output (BIOS) stored in ROM 1340 or similar, can provide the basic routine that helps to transfer information between elements within the 1300 computing device, such as when it is turned on. The computing device 1300 further includes 1360 storage devices such as a hard disk drive, a magnetic disk drive, an optical disk drive, a tape drive or the like. The storage device 1360 may include software modules 1362, 1364, 1366 to control the 1320 processor. Other hardware or software modules are considered. The 1360 storage device is connected to the 1310 system bus via a drive interface. The associated computer-readable drives and storage media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the 1300 computing device. In one aspect, a hardware module that performs a function particular includes the software component stored in a non-transitory computer-readable medium in connection with the necessary hardware components, such as the 1320 processor, 1310 bus, 1370 output device, and so on, to perform the function. The basic components are known to those skilled in the art and appropriate variations are considered depending on the type of device, such as whether the 1300 device is a small, hand-held computing device, a desktop computer or a computer server.
[0069] [0069] Although the exemplary modality described here employs the 1360 hard drive, it should be appreciated by those skilled in the art than other types of computer-readable media that can store data that are accessible by a computer, such as magnetic tapes, memory cards flash drives, digital versatile disks, cartridges, random access memories (RAMs) 1350, read-only memory (ROM) 1340, a cable or wireless signal containing a bit stream and the like, can also be used in the exemplary operating environment. Non-transitory, computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.
[0070] [0070] To allow user interaction with the 1300 computing device, a 1390 input device represents any number of input mechanisms, such as a microphone for speaking, a touch screen for gesture or graphics input, keyboard, mouse , motion input, speech and so on. An output device 1370 can also be one or more of a number of output mechanisms known to those skilled in the art. In some cases, multimodal systems allow a user to provide multiple types of input to communicate with the 1300 computing device. The 1380 communications interface generally governs and manages user input and system output. There is no restriction on operation on any specific hardware arrangement and therefore the basic features here can easily be replaced with hardware or firmware arrangements as they develop.
[0071] [0071] For clarity of presentation, the modality of the illustrative system is presented as including individual functional blocks including functional blocks called "processor" or 1320 processor. The functions that these blocks represent can be provided through the use of shared or dedicated hardware, including, but not limited to, hardware capable of running software and hardware, such as a 1320 processor, which is purpose built to operate as a software equivalent running on a general purpose processor. For example, the functions of one or more processors shown in figure 13 can be provided by a single shared computer or by multiple processors (the use of the term “processor” should not be interpreted as referring exclusively to hardware capable of running software). Illustrative modalities may include microprocessor and / or digital signal processor (DSP) hardware, read-only memory 1340 to store software performing the operations discussed below, and random access memory (RAM) 1350 to store results. Very large-scale integration hardware (VLSI) modes, as well as a custom-made VLSI circuit pack in combination with a general purpose DSP circuit, can also be provided.
[0072] [0072] The logical operations of the various modalities are implemented as: (1) a sequence of steps, operations or procedures implemented by a computer operating in a programmable circuit within a general purpose computer, (2) a sequence of steps, operations or computer-implemented procedures operating on a programmable circuit for specific use; and / or (3) machine modules or program motors interconnected within programmable circuits. The 1300 system shown in figure 13 can practice all or part of the listed methods, can be a part of the listed systems, and / or can operate according to instructions on non-transitory computer-readable storage media. These logic operations can be implemented as modules configured to control the 1320 processor so that it performs specific functions according to the module's programming. For example, figure 13 illustrates three modules Mod1, 1362, Mod 2 1364 and Mod 3 1366 which are modules that control the 1320 processor so that it performs specific steps or a series of steps. These modules can be stored in storage device 1360 and loaded into RAM 1350 or memory 1330 at the time of operation or they can be stored as would be known in the art in other computer readable memory locations.
[0073] [0073] Modalities within the scope of this description may also include tangible and / or non-transitory computer-readable storage media for carrying or having instructions executable by computer or data structures stored therein. Such non-transitory computer-readable storage media can be any available medium that can be accessed by a computer for a general or special purpose, including the functional design of any special-purpose processor, as discussed above. For example, and not by way of limitation, such non-transitory computer-readable media may include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other means that can be used to transport or store desired program code media in the form of computer executable instructions, data structures, or processor chip design. When information is transferred or provided by a network or other communication connection (either by means of wires or cables, without using wires, or a combination of these) to a computer, the computer properly sees the connection as a computer-readable medium . Thus, any connection is properly called a computer-readable medium. Combinations of these above could also be included within the scope of the computer-readable medium.
[0074] [0074] Computer executable instructions include, for example, instructions and data that take a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a particular function or group of functions. Computer-executable instructions also include program modules that are executed by computers in isolated or networked environments. Generally, program modules include routines, programs, components, data structures, objects, and the functions inherent in the design of special purpose processors, etc. that perform particular tasks or implement particular abstract data types. Computer executable instructions, associated data structures, and program modules represent examples of the means of program code to perform steps of the methods described here. The particular sequence of such executable instructions or associated data structures represents an example of corresponding actions for implementing the functions described in such steps.
[0075] [0075] Those skilled in the art will appreciate that other modes of description can be practiced in networked computing environments with many types of computer system configurations, including personal computers, hand-held devices, multiprocessor systems, consumer electronics devices based on microprocessor or programmable, personal network computers, minicomputers, large computers and the like. Modalities can also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are connected (either by wired and cable connections, wireless connections, or by a combination of them) through a communications network. In a distributed computing environment, program modules can be located on local and remote memory storage devices.
[0076] [0076] The various modalities described above are provided by way of illustration only and should not be interpreted as limiting the scope of the description. Those skilled in the art will immediately recognize many modifications and changes that can be made to the principles described above without following the exemplary modalities and applications illustrated and described here, and without departing from the spirit and scope of the description.

权利要求:
Claims (16)
[0001]
User terminal to enforce a server-generated application usage policy, the user terminal comprising data processing facility (1320) configured to: send an authorization request to a server (112) to authorize a user to run an application on the user terminal; the user terminal being characterized by the fact that the data processing feature is further configured to: receive, from the server, a first authorization file (1004), the first authorization file specifying the user and including a first deauthorization count associated with the user; receive, from the server, in response to a deauthorization request (1220), a replacement authorization file, resulting from the deauthorization of the user at the user terminal, which no longer specifies the user; receive, from the server, an application purchase receipt (1002) in response to a purchase request to purchase the application, the application purchase receipt (1002) including a deauthorization count associated with the user; compare (1112) the app purchase receipt deactivation counts (1002) from the authorization file; and deny application usage if the deauthorization count on the application purchase receipt (1002) is greater than the deauthorization count in the authorization file.
[0002]
User terminal, according to claim 1, characterized by the fact that the data processing feature is still configured for: receive, through a user input interface (1390), the deauthorization request to deauthorize the user at the user terminal; and send the deauthorization request to the server.
[0003]
User terminal, according to claim 1, characterized by the fact that the data processing feature is still configured for: receive, through the user input interface, the purchase request to purchase the application for the user; and send the purchase request to the server, where the purchase request includes a user ID.
[0004]
User terminal, according to claim 1, characterized by the fact that the data processing feature is still configured for: verify (1104) that the application purchase receipt is valid; verify (1106) that the authorization file is valid; and verify (1108) that a user specified on the application purchase receipt is in the authorization file.
[0005]
User terminal, according to claim 4, characterized by the fact that the data processing feature is still configured to send the authorization request when the user specified in the application purchase receipt is not included in the authorization file.
[0006]
User terminal, according to claim 4, characterized by the fact that the data processing facility, to confirm that the application's purchase receipt is valid, is further configured to: generate a first subscription based on the application's purchase receipt; verify (904) that the first subscription corresponds to a second subscription associated with the application purchase receipt; checking (906) that an application identifier on the application purchase receipt matches an application identifier; and check (908) that an application version number on the application purchase receipt matches an application version number.
[0007]
User terminal, according to claim 4, characterized by the fact that the data processing facility, to confirm that the first authorization file is valid, is further configured to: generate a first signature based on the first authorization file; verify (910) that the first signature corresponds to a second signature associated with the authorization file; and check (912) that a machine identifier in the authorization file matches an identifier for the user terminal.
[0008]
User terminal, according to claim 4, characterized by the fact that the data processing feature is still configured for: allow use of the application when the verification steps are successful; and deny at least some use of the app when at least one of the verification steps fails.
[0009]
Method to enforce a server-generated application usage policy, the method characterized by the fact that it comprises the steps of, in a user terminal: send an authorization request to a server to authorize a user to run an application on a machine; receive, from the server, an authorization file (1004), the authorization file specifying the user and including a first deauthorization count associated with the user; receive, from the server, in response to a deauthorization request (1220), a replacement authorization file, resulting from the deauthorization of the user on the machine, which no longer specifies the user; receive, from the server, an application purchase receipt (1002) in response to a purchase request to purchase the application, the application purchase receipt (1002) including a deauthorization count associated with the user; compare (1112) the app purchase receipt deactivation counts (1002) from the authorization file; and deny application usage if the deauthorization count on the application purchase receipt (1002) is greater than the deauthorization count in the authorization file.
[0010]
Method according to claim 9, characterized by the fact that the data processing feature is further configured to: receive, through a user input interface (1390), the deauthorization request to deauthorize the user at the user terminal; and send the deauthorization request to the server.
[0011]
Method according to claim 9, characterized by the fact that the data processing feature is further configured to: receive, through the user input interface, the purchase request to purchase the application for the user; and send the purchase request to the server, where the purchase request includes a user ID.
[0012]
Method according to claim 9, characterized by the fact that the data processing feature is further configured to: verify (1104) that the application purchase receipt is valid; verify (1106) that the authorization file is valid; and verify (1108) that a user specified on the application purchase receipt is in the authorization file.
[0013]
Method, according to claim 12, characterized by the fact that the data processing facility is still configured to send the authorization request when the user specified in the application purchase receipt is not included in the authorization file.
[0014]
Method according to claim 12, characterized by the fact that the data processing facility, to confirm that the purchase receipt for the application is valid, is further configured to: generate a first subscription based on the application's purchase receipt; verify (904) that the first subscription corresponds to a second subscription associated with the application purchase receipt; checking (906) that an application identifier on the application purchase receipt matches an application identifier; and check (908) that an application version number on the application purchase receipt matches an application version number.
[0015]
Method, according to claim 12, characterized by the fact that the data processing facility, to confirm that the first authorization file is valid, is further configured to: generate a first signature based on the first authorization file; verify (910) that the first signature corresponds to a second signature associated with the authorization file; and check (912) that a machine identifier in the authorization file matches an identifier for the user terminal.
[0016]
Method according to claim 12, characterized by the fact that the data processing feature is further configured to: allow use of the application when the verification steps are successful; and deny at least some use of the app when at least one of the verification steps fails.

类似技术:

公开号 | 公开日 | 专利标题

BR112013009278B1|2020-11-24|USER TERMINAL AND METHOD FOR IMPOSING A SERVER GENERATED APPLICATION USE POLICY

US20210256140A1|2021-08-19|System and methods for tamper proof interaction recording and timestamping

KR101712784B1|2017-03-06|System and method for key management for issuer security domain using global platform specifications

EP3025268B1|2021-05-05|Feature licensing in a secure processing environment

BRPI0801772B1|2021-04-13|METHOD IMPLEMENTED BY COMPUTER, INFORMATION TREATMENT SYSTEM AND LEGIBLE STORAGE MEDIA BY COMPUTER

US20120310983A1|2012-12-06|Executable identity based file access

TW201145041A|2011-12-16|Provisioning, upgrading and/or changing of hardware

MX2014007102A|2014-07-28|Facilitating system service request interactions for hardware-protected applications.

TW200304620A|2003-10-01|Authenticated code method and apparatus

CN109313690A|2019-02-05|Self-contained encryption boot policy verifying

WO2020233610A1|2020-11-26|Receipt storage method combining code labelling with user and event type, and node

WO2020233639A1|2020-11-26|Receipt storage method and node based on code labeling and event function type

BR102012017289A2|2018-02-27|SYSTEM AND METHOD FOR CONNECTING PRE-INSTALLED SOFTWARE TO A USER ACCOUNT IN AN ONLINE STORE

US9053305B2|2015-06-09|System and method for generating one-time password for information handling resource

WO2015084144A1|2015-06-11|A system and method to secure virtual machine images in cloud computing

US20110145596A1|2011-06-16|Secure Data Handling In A Computer System

CN110998571A|2020-04-10|Offline activation of applications installed on a computing device

US10614454B1|2020-04-07|Remote population and redaction of high security data

CN110352411A|2019-10-18|Method and apparatus for controlling the access to safe computing resource

US10402549B1|2019-09-03|Systems and methods for creating validated identities for dependent users

US20210248090A1|2021-08-12|Protecting cache accesses in multi-tenant processing environments

KR102173264B1|2020-11-03|Cryptocurrency wallet redundancy method using multi-sig for overcoming failover

US20200327248A1|2020-10-15|Smart deployai data pipeline digital signing & encryption

WO2020233421A1|2020-11-26|Object-level receipt storage method and node based on code marking

US20220004647A1|2022-01-06|Blockchain implementation to securely store information off-chain

同族专利:

公开号 | 公开日

EP2630606A2|2013-08-28|

AU2011318417A1|2013-05-02|

KR101492757B1|2015-02-12|

AU2011318417B2|2015-10-08|

JP5624681B2|2014-11-12|

WO2012054252A3|2012-09-07|

WO2012054252A2|2012-04-26|

US20190114399A1|2019-04-18|

CN103180859A|2013-06-26|

MX2013004434A|2013-07-17|

CN103180859B|2015-11-25|

BR112013009278A2|2016-07-26|

KR20130084671A|2013-07-25|

US20120095877A1|2012-04-19|

JP2013546060A|2013-12-26|

EP2630606B1|2018-11-21|

引用文献:

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

US5708709A|1995-12-08|1998-01-13|Sun Microsystems, Inc.|System and method for managing try-and-buy usage of application programs|

US5790664A|1996-02-26|1998-08-04|Network Engineering Software, Inc.|Automated system for management of licensed software|

WO1998042098A1|1997-03-14|1998-09-24|Cryptoworks, Inc.|Digital product rights management technique|

US7051005B1|1999-03-27|2006-05-23|Microsoft Corporation|Method for obtaining a black box for performing decryption and encryption functions in a digital rights management system|

US7024393B1|1999-03-27|2006-04-04|Microsoft Corporation|Structural of digital rights management system|

US7073063B2|1999-03-27|2006-07-04|Microsoft Corporation|Binding a digital license to a portable device or the like in a digital rights management system and checking out/checking in the digital license to/from the portable device or the like|

JP2003513388A|1999-10-29|2003-04-08|コーニンクレッカフィリップスエレクトロニクスエヌヴィ|System and method for ensuring data reliability with a secured counter|

JP2002268764A|2001-03-14|2002-09-20|Dainippon Printing Co Ltd|Software license management system with ic card|

AU2002345577A1|2001-06-07|2002-12-23|Contentguard Holdings, Inc.|Protected content distribution system|

ES2266514T5|2001-06-07|2015-09-30|Contentguard Holdings, Inc.|Method and system of digital subscription rights management|

US20040088541A1|2002-11-01|2004-05-06|Thomas Messerges|Digital-rights management system|

US7549047B2|2002-11-21|2009-06-16|Xerox Corporation|Method and system for securely sharing files|

JP4340856B2|2003-04-25|2009-10-07|ソニー株式会社|Data protection method and protection device therefor|

US7949877B2|2003-06-30|2011-05-24|Realnetworks, Inc.|Rights enforcement and usage reporting on a client device|

EP1678943A1|2003-09-17|2006-07-12|Matsushita Electric Industrial Co., Ltd.|Application execution device, application execution method, integrated circuit, and computer-readable program|

AT434227T|2003-12-30|2009-07-15|Wibu Systems Ag|PROCEDURE FOR RESTORING AN AUTHORIZATION CODE|

US7725721B2|2004-11-18|2010-05-25|Cisco Technology, Inc.|Method and system for transferring software and hardware feature licenses between devices|

US20060272031A1|2005-05-24|2006-11-30|Napster Llc|System and method for unlimited licensing to a fixed number of devices|

US20060282391A1|2005-06-08|2006-12-14|General Instrument Corporation|Method and apparatus for transferring protected content between digital rights management systems|

US20060287959A1|2005-06-17|2006-12-21|Macrovision Corporation|Software license manager employing license proofs for remote execution of software functions|

JP4908961B2|2006-07-27|2012-04-04|キヤノン株式会社|Information processing method, information processing apparatus, program, and storage medium|

US8620818B2|2007-06-25|2013-12-31|Microsoft Corporation|Activation system architecture|

KR101456489B1|2007-07-23|2014-10-31|삼성전자주식회사|Method and apparatus for managing access privileges in a CLDC OSGi environment|

JP4954031B2|2007-11-16|2012-06-13|キヤノン株式会社|Image processing apparatus and reinstallation method|

CN101339592A|2008-08-14|2009-01-07|冯振周|All-purpose digital copyright protection technology frame|

US9548859B2|2008-12-03|2017-01-17|Google Technology Holdings LLC|Ticket-based implementation of content leasing|

CN101866404B|2010-06-13|2012-11-28|用友软件股份有限公司|Software system module independent authorization control method and device|US20130047271A1|2011-08-19|2013-02-21|Ding-Yuan Tang|Author Authorization of Electronic Works|

CN103379163B|2012-04-25|2016-04-06|阿里巴巴集团控股有限公司|A kind of defining method of business object and determining device|

US20140067676A1|2012-09-04|2014-03-06|Microsoft Corporation|Management of digital receipts|

US9424405B2|2012-11-28|2016-08-23|Apple Inc.|Using receipts to control assignments of items of content to users|

CN103312513B|2013-06-19|2016-03-02|北京华胜天成科技股份有限公司|The method and system of use authority are verified under distributed environment|

US9311491B2|2013-09-30|2016-04-12|Google Inc.|Systems, methods, and computer program products for securely managing data on a secure element|

EP3051755A4|2013-11-29|2016-10-19|Huawei Device Co Ltd|Installation package authorization method and device|

US9256752B2|2014-01-07|2016-02-09|Microsoft Technology Licensing, Llc|Product authorization with cross-region access|

US9424576B2|2014-09-15|2016-08-23|Xerox Corporation|Methods and systems of creating a payment record with a cryptographically secure audit trail|

CN105741153A|2014-12-10|2016-07-06|北京奇虎科技有限公司|Method and device for obtaining toolkits|

US9794231B2|2015-03-16|2017-10-17|Schlage Lock Company Llc|License management using cloud based enrollment|

CN106651342A|2016-12-13|2017-05-10|宁夏宁信信息科技有限公司|Mobile payment app control device and method|

CN106600281A|2016-12-13|2017-04-26|宁夏凯速德科技有限公司|Integrated and encrypted mobile payment app control device and method|

CN106789073B|2016-12-26|2019-10-15|北京小米支付技术有限公司|Signing messages generation method and device|

CN111597526B|2020-07-23|2020-10-27|飞天诚信科技股份有限公司|Credential correction method, system, data processing terminal and working method thereof|

CN112202772B|2020-09-29|2021-06-29|北京海泰方圆科技股份有限公司|Authorization management method, device, electronic equipment and medium|

法律状态:
2018-12-26| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

2019-10-01| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

2020-09-08| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|

2020-11-24| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 10/10/2011, OBSERVADAS AS CONDICOES LEGAIS. |

优先权:

申请号 | 申请日 | 专利标题

US12/907,915|US20120095877A1|2010-10-19|2010-10-19|Application usage policy enforcement|

US12/907,915|2010-10-19|

PCT/US2011/055653|WO2012054252A2|2010-10-19|2011-10-10|Application usage policy enforcement|

[返回顶部]