Patent Application
20130254113
The present subject matter described herein, in general, relates to licensing of software applications, and more particularly to pay-per-use for licensing software applications.
Traditional models for acquisition, use, and rental of software require a customer to pay for an expected number, or instances, of a software product that is intended to operate on the customer's computer network or system. For example, a customer desiring to provide a word processing software product for use by the customer's employees will generally pay for one copy of the software product for each of the customer's employees that will use the software product. Such payment may give the customer a license to use the software product at each of the employee work stations. The license typically prohibits copying and further distribution of the software product to other employees of the customer. The customer, moreover, pays a full price for each license thus obtained.
However, some or all of the customer's employees may use the software product only on a part-time basis. Thus, the customer in effect pays for excess capacity to ensure that all employees, including the ones that use the software product sparingly, have access to the software product. As an alternative, the customer could acquire a limited number of software product licenses. In this alternate arrangement, some employees may not be able to use the software product when needed or desired, thereby reducing the work output of the customer.
Finally, the customer's hardware needs may change rapidly. Acquisition or disposal of hardware may affect the number of software licenses the customer needs to have in place. By having to separately purchase additional licenses of the software product, the customer may experience delays before the newly acquired hardware is fully functional. Therefore, pay-per-use (PPU) licensing of software applications is getting enormous popularity.
This summary is provided to introduce concepts related to systems and methods for administering PPU licensing of software applications and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
In one implementation, a system for administering pay-per-use (PPU) licensing of software applications is disclosed. The system comprises a processor and a memory. The memory comprises an administrative module configured to generate a license file based upon a request sent by a user. The license file is used by the user for accessing a software application. The administrative module is further configured to receive a log file from the user. The log file comprises a track of at least one of a number of usages of the software application and a time period of the software application. In one implementation, the log file is signed using a private key of the user. The memory further includes an assessment module configured to determine a validity of the license file based upon the log file.
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
Systems and methods for administering pay-per-use (PPU) software licensing of software applications are described. In a PPU licensing mechanism, users pay as per their usage of the software applications, rendering them to pay a very nominal amount for the usage of software applications as against paying a lump sum as a one time payment. Hence, PPU licensing systems which generate PPU licenses for software applications are getting popular day by day. These PPU licensing systems help in curbing software piracy and other illegal means of using a software application. However, conventional PPU licensing systems neither ensure security of the licenses generated and nor do they administer the entire PPU licensing mechanism efficiently. For example, conventional PPU licensing systems do not facilitate encryption and decryption of licenses. Further, it is difficult to carry-forward unused trials or time period as the relevant data can not be retrieved upon expiry/during subsequent renewal.
In one implementation of the present subject matter, a user may wish to install a software application on a client device belonging to the user. Examples of the software application may include a gaming software, a text editor, or any other software application. The installation of the software application may require a license. In order to obtain the license, the user may send a request for generating a license file to a PPU licensing system. Based upon the request, the PPU licensing system may generate a license file. In one embodiment, the PPU licensing system may employ a technique, such as Public Key Infrastructure (PKI) for generation of the license file. The license file may either be a pre-paid license file or a post-paid license file. The license file (either pre-paid or post-paid) and a private key obtained from the PPU licensing system may be used by the user to install and access the software application on the client device, thereby making accessing of the software application secure. In one implementation, the PPU licensing system also generates reports for the licenses files that are valid or have expired.
In one implementation, when the user installs the software application using the license file, the client device may track a number of usages of the software application and a time period of usage of the software application. For example, the client device may generate and maintain one or more log files to track usages of the software application. The log file may be digitally signed using the private key and may subsequently be uploaded to the PPU licensing system to determine validity of the license file. The PPU licensing system may generate a report on all the log files that are confirmed as valid and the ones that are confirmed as corrupted. In case of a pre-paid license file, determining the validity may include computing a carry forward of left over usages, such as unexhausted time period and unexhausted number of trials of the software application. However, in case of a post-paid license file, determining the validity may include generating an invoice for the usage of the license file a billing cycle. Therefore, the present subject matter allows secure access of the software application along with efficient administration of the entire PPU licensing mechanism.
While aspects of described system and method for administering pay-per-use (PPU) licensing of software applications may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system.
Referring now to
Further, the system 102 may be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. It will be understood that the system 102 may be communicatively coupled to the PPU client devices 104-1, 104-2, . . . 104-N, referred to as client device(s) 104 hereinafter. The client devices 104 may be implemented in devices, such as a portable computer, a personal digital assistant, a handheld device, and a workstation. The client devices 104 are communicatively coupled to the system 102 through a network 106.
In one implementation, the network 106 may be a wireless network, a wired network or a combination thereof. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network 106 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
In one implementation, a user may wish to install a software application on the client devices 104. Examples of the software application may include a gaming software, a text editor, and or any other software application. In order to install the software application in the client device 104, the user may require a license. In order to obtain the license, the user may use the client device 104 to send a request to the system 102 for generating a license file. In one example, the system 102 may host a webpage where user may register and submit the request for generating the license file. It may be understood that the request for generating the license file may be submitted by any device other than the client device. For example, the request may be sent though a smart phone whereas the software application may be installed in the client device, such as a laptop. Based upon the request, the system 102 may provide the user with the options of generating a pre-paid license file or a post-paid license file. Based upon these options, the user may request the system 102 to generate either a pre-paid license file or a post-paid license file. The license file (either pre-paid or post-paid) obtained from the system 102 may be used by the user to install and access the software application on the client device 104. In one example, the license file may include a pass code that may facilitate installation of the software application on the client device. In one implementation, the PPU licensing system also generates reports for the licenses files that are valid or have expired. For example, these reports keep a track of a number of license files being generated and whether those license files are valid/active or have expired. These reports may be stored in a license file database.
In one implementation, when the user installs the software application using the pre-paid license file, a log generating module (shown in
However, in another embodiment, when the user installs the software application using the post-paid license file, a log generating module (shown in
Referring now to
The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions stored in a memory.
Also, the system 102 and the client device 104 include a system I/O interface 204-1 and a client I/O interface 204-2, respectively, which are collectively referred to as I/O interfaces 204. The I/O interface 204 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 204 may allow the system 102 to interact with a user directly or through the client device 104. Further, the I/O interface 204 may enable the system 102 to communicate with other computing devices, such as web servers, external data servers and remote monitoring and/or maintenance servers (not shown). The I/O interface 204 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface 204 may include one or more ports for connecting a number of devices to one another or to another server.
The system 102 and the client device 104 may further include one or more memory components, referred to as a system memory 206-1 and a client memory 206-2, coupled to the system processor 202-1 and the client processor 202-2, respectively. The system memory 206-1 and the client memory 206-2 are collectively referred to memory 206. The memory 206 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
In one embodiment, the system memory 206-1 includes system modules 208 and system data 210. The system modules 208 may include an administrative module 212, an assessment module 214, and other system modules 216. The system modules 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. The other system modules 216 may include programs or coded instructions that supplement applications and functions of the system 102.
The system data 210, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the system modules 208. The system data 210 may include a license file database 218 and other system data 220. The other system data 220 may include data generated as a result of the execution of one or more modules in the other system modules 216.
In one embodiment, the client memory 206-2 includes client modules 222 and client data 224. The client modules 222 may include a central unit 226, a log generating module 228, and other client modules 230. The client modules 222 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. The other client modules 230 may include programs or coded instructions that supplement applications and functions of the client device 104.
The client data 224, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the client modules 222. The client data 224 may include a log repository 232 and other client data 234. The other client data 234 may include data generated as a result of the execution of one or more modules in the other client modules 230.
In one implementation, a user may install a software application on the client device 104. In one example, the software application may be a stand alone software application and may be purchased in the form of a computer readable media, such as a compact disc (CD) or may be downloaded from the Internet for installation on the client device 104. The stand alone application is locally hosted on the client device and not on the Internet. The software application, such as gaming software, text editor, or any other software application, may require a license before the user may install or access the software application. In order to obtain the license, the user may register into the system 102 by providing information related to the software application along with certain personal details. Subsequent to the registration in the system 102, the user may send a request to the system 102 for generating a license file. It may be understood that the request for generating the license file may be submitted by any device other than the client device as well. For example, the request may be sent though a smart phone whereas the software application may be installed in the client device, such as a laptop. Based upon the request, the system 102 may provide the user with the options of generating a pre-paid license file or a post-paid license file.
In one implementation, based upon the user's request for obtaining the license file, the administrative module 212 may present several pre-paid plans and several post paid plans on the I/O interface of the system 102. The user may choose to pay either upfront, i.e., pre-paid or after every billing cycle, i.e., post-paid for the license file. In one implementation, the administrative module 212 of the system 102 generates the license file. Further, the license file generated by the administrative module 212 is one of the pre-paid license file or the post-paid license file based upon the user's selection. In one embodiment, the administrative module 212 may also generate a public-private key pair using a Public Key Infrastructure (PKI) known in the art. However, in another embodiment, the administrative module 212 may use any other encryption technique known in the art to generate the license file. The license file comprises an information block and a signature block. Further, the license file may be encrypted by the administrative module 212 using methods known in the art. In the present implementation, the license files may be stored in the license file database 218.
As known, each pre-paid plan of the several pre-paid plans may cost a fixed price having a fixed number of usages for a fixed time period. In one example, out of the several pre-paid plans, the user may choose to activate a pre-paid plan X. The pre-paid plan X may require the user to pay a sum of $10 for 50 usages/trials to be used within a time period of 30 days. A pre-paid license file X generated in accordance with the pre-paid plan X may be sent to the client device 104 along with the private key. The client device 104 may store the pre-paid license file X in the central unit 226. In one embodiment, the user may access the pre-paid license file X and feed the pre-paid license file X and the private key into the software application running on the client device 104. As the pre-paid license file X is encrypted, a license checker (not shown) present in the software application may decrypt the pre-paid license file X using the public-private key pair to check the authenticity of the same. Upon successful decryption of the pre-paid license file X by the license checker, the user may access the software application.
In the present implementation, after the user starts using the software application, the log generating module 228, which gets installed in the client device 104 with the installation of the software application, may generate a log file for tracking a number of usages and a time period of the software application. The log file includes the track of a number of exhausted usages, a number of unexhausted usages, exhausted time period, and unexhausted time period associated of the software application. In one example, based upon the usage of the software application, the log file for the pre-paid license file X may suggest that the number of exhausted usages is 15/50, i.e., the user had logged into the software application and used the same 15 times out of a total of 50 trials. Similarly, the log file may suggest that the number of unexhausted usages is 35/50, i.e., 35 trials are remaining out of the 50 trials. Similarly, the log file may suggest that the exhausted time period is 30/30 days, i.e., the time period within which the user had exhausted the 15 trials of the software application is 30 days. Similarly, the log file may suggest that a remaining time period or the unexhausted time period is zero days. In the present implementation, the log files may be stored in the log repository 232.
As the user has exhausted the complete time period of 30 days, the user may wish to renew the pre-paid license file X. It may be understood that the user may renew the pre-paid license file X anytime after the first purchase of the pre-paid license file X. In order to renew the pre-paid license file X, the user may first digitally sign the log file using the private key. Subsequently, the user may upload or send the log file to the administrative module 212 of the system 102 using the client device 104 or any other device. The administrative module 212 may send the log file to the assessment module 214. The assessment module 214 may use the public key to check tampering of the log file. After the log file is established to be un-tampered, the assessment module 214 may determine a validity of the pre-paid license file X based upon the log file. Determining the validity by the assessment module 214 may include computing a carry forward of the unexhausted time period and the number of unexhausted usages of the software application upon renewal of the pre-paid license file X. In the present example, when the user renews the pre-paid license file X for a sum of $10, the user may get 50+35, i.e., 85 usages/trials that he may use within a time period of 30 days. Therefore, it may be understood that left over number of usages or time periods may be carry forwarded in case of pre-paid license files.
Similarly, in another implementation, the user may activate a post-paid plan Y to generate a post-paid license file Y. In the present implementation, the user may pay a predetermined security amount to generate the post-paid license file Y. Subsequently, the administrative module 212 may generate the post-paid license file Y along with a public-private key pair. The post-paid license file Y may be encrypted by the administration module. Further, the post-paid license file Y along with the private key may be fed by the user into the software application. As the post-paid license file Y is encrypted, the license checker (not shown) present in the software application may decrypt the post-paid license file Y using the public-private key pair to check the authenticity of the same. Upon successful decryption of the post-paid license file Y by the license checker, the user may access the software application.
After the user starts using the software application, the log generating module 228 of the client device 104 may generate a log file corresponding to the post-paid license file Y. The log file may keep a track of a number of usages of the software application in a billing cycle and may be stored in the log repository 232. The log file, after being digitally signed using the private key, may be uploaded by the user onto the system 102 after the billing cycle. The assessment module 214 may use the public key to check tampering of the log file. After the log file is established to be un-tampered, the assessment module 214 may determine a validity of the post-paid license file Y based upon the log file. Determining the validity of the license file may include generating an invoice for the billing cycle of the post-paid license file Y. The post-paid license file Y may get renewed after the user pays the invoice.
Referring now to
The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 300 or alternate methods. Additionally, individual blocks may be deleted from the method 300 without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method 300 may be considered to be implemented in the above described system 102.
At block 302, a license file may be generated based upon a request sent by a user. The license file may be used to install and access a software application on the client device 104. In one example, the license file may be generated by the administrative module 212.
At block 304, a log file comprising a track of at least one of a number of usages of the software application and a time period of the software application may be received from the client device 104. In one example, the log file may be received by the administrative module 212.
At block 306, a validity of the license file may be determined based upon the log file. In case of a pre-paid license file, determining the validity may include computing a carry forward of left over usages and time period. However, in case of a post-paid license file, determining the validity may include computing an invoice for the usage of the software application in a billing cycle. In one example, the validity may be determined by the assessment module 214.
Referring now to
The order in which the method 400 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 400 or alternate methods. Additionally, individual blocks may be deleted from the method 400 without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method 400 may be considered to be implemented in the above described client device 104.
At block 402, a request for generating a license file may be transmitted. In one example, the request may be transmitted to the system 102 by the central unit 226.
At block 404, the license file may be received based upon the request. The license file may be used by a user for accessing a software application. In one example, the license file may be sent by the system 102 and received by the central unit 226.
At block 406, a log file for tracking of at least one of a number of usages of the software application and a time period of the software application may be generated. In one example, the log file may be generated by the log generating module 228. Further, the based upon the log file, the PPU licensing of software applications may be managed.
Although implementations for methods and systems for administering pay-per-use (PPU) licensing of software applications have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for administering PPU licensing of software applications.
| Number | Date | Country | Kind |
|---|---|---|---|
| 764/MUM/2012 | Mar 2012 | IN | national |
