This application is related to co-pending U.S. patent application Ser. No. 13/539,434 for COMMON LICENSING OF GENERAL OFFERINGS, U.S. patent application Ser. No. 13/539,436 for CUSTOMER TARIFFS, and U.S. patent application Ser. No. 13/539,437 for PUBLIC SERVICE UNITS, which are incorporated herein by reference for all purposes.
This invention relates generally to technology licensing, and more particularly to systems and methods for tiered service licensing.
Unlike hardware products, software products are easily transferred and copied. This frees software vendors from many of the distribution and inventory costs that hardware vendors have to deal with. However, this ease of distribution and copying also makes software prone to theft, also known as software piracy.
Conventional methods to combat software piracy include associating a license key with the software product. These license keys may also be referred to as “serial numbers,” or “activation keys,” among others. When a user enables the software product, a prompt may ask for a license key. If a correct license key is entered by the user, the desired capability may be enabled. If a correct license key is not entered, the installation may exit, or a limited-functionality version of the software may be installed. License keys allow a software vendor to withhold functions of the software until the software vendor has been compensated.
Unfortunately, conventional licensing schemes do not fully protect against software piracy. Further, conventional licensing schemes often create large administrative burdens.
There is a need, therefore, for an improved method, article of manufacture, and apparatus for licensing products.
The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements, and in which:
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. While the invention is described in conjunction with such embodiment(s), it should be understood that the invention is not limited to any one embodiment. On the contrary, the scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications, and equivalents. For the purpose of example, numerous specific details are set forth in the following description in order to provide a thorough understanding of the present invention. These details are provided for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the present invention is not unnecessarily obscured.
It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium such as a computer readable storage medium or a computer network wherein computer program instructions are sent over optical or electronic communication links. Applications may take the form of software executing on a general purpose computer or be hardwired or hard coded in hardware. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
An embodiment of the invention will be described with reference to a data storage system in the form of a storage system configured to store files, but it should be understood that the principles of the invention are not limited to this configuration. Rather, they are applicable to any system capable of storing and handling various types of objects, in analog, digital, or other form. Although terms such as document, file, object, etc. may be used by way of example, the principles of the invention are not limited to any particular form of representing and storing data or other information; rather, they are equally applicable to any object capable of representing information.
System IO controller 106 may be in communication with display 110, input device 112, non-transitory computer readable storage medium 114, and/or network 116. Display 110 may be any computer display, such as a monitor, a smart phone screen, or wearable electronics and/or it may be an input device such as a touch screen. Input device 112 may be a keyboard, mouse, track-pad, camera, microphone, or the like, and storage medium 114 may comprise a hard drive, flash drive, solid state drive, magnetic tape, magnetic disk, optical disk, or any other computer readable and/or writable medium. Storage device 114 may also reside inside general purpose computer 100, rather than outside as shown in
Network 116 may be any computer network, such as a local area network (“LAN”), wide area network (“WAN”) such as the internet, a corporate intranet, a metropolitan area network (“MAN”), a storage area network (“SAN”), a cellular network, a personal area network (PAN), or any combination thereof. Further, network 116 may be either wired or wireless or any combination thereof, and may provide input to or receive output from IO controller 106. In an embodiment, network 116 may be in communication with one or more network connected devices 118, such as another general purpose computer, smart phone, PDA, storage device, tablet computer, or any other device capable of connecting to a network.
For example, the offering exposition may describe a backup service offering. Services provided within the backup service offering could include a backup service, a recovery service, and an archive service. For the backup service, the offering exposition may further define that the customer is charged annually based on the amount of data they have backed-up. Similar baseline values may be defined for the recovery service and the archive service.
In an embodiment, the vendor or producer may offer the offering exposition to a customer on a non-negotiable basis. Negotiable elements associated with the services, in contrast, may be defined in a “service tariff.” Service tariffs may be specific to each customer, and may further be associated with a specific service defined in the service offering. For example, each customer may negotiate their own tariffs for a backup service, recovery service, and archive service.
Service tariffs may include negotiable elements, such as how much each customer is charged, what locale or jurisdiction they are allowed to access the service from, what denomination/currency to use, and a set of price bands. Price bands may vary the cost of a service based on consumption. For example, a customer accessing a backup service may be charged less as they consume more. The first 10 GB, for example, may be $20, the second 10 GB may be $15, and each 10 GB increment after 20 GB may be $10.
In some embodiments, a customer may only access the services defined in the offering exposition if they have a negotiated tariff in place. The customer may be validated against the service using login credentials or some other verification mechanism.
For a detailed description of service offerings and tariffs, please see the cross-referenced applications, which are hereby incorporated by reference.
Turning now to
The resale process may be facilitated using license keys, however acceptance proxies may be a preferred alternative. For example, producer 300 may sell a block of license keys to distributor 302, who may sell a subset of those keys to retailer 304. Retailer 304 may in turn provide one or more license keys to customer 306. License keys, however, present two disadvantages to producer 300. First, once license keys are released producer 300 loses control of the intermediaries. Producer 300 may intend for a two-tiered system, but one of the intermediaries may sell the keys to an unauthorized reseller, such as another retailer. These “grey markets” may decrease demand for new services, and may negatively impact the producers ability to track them. Second, license keys are prone to piracy. If an unauthorized entity obtains a copy of the license key, they may use that key multiple times to access the associated software. The processes discussed herein help alleviate these concerns.
The architecture of
Before customer 306 can consume service 301, the acceptance proxy must be registered and the customer must be validated. In an embodiment, proxy registration occurs as an acceptance proxy moves through the system. For example, producer 300 may distribute an acceptance proxy to distributor 302. Since producer 300 is providing the acceptance proxy directly to distributor 302, producer 300 may automatically register distributor 302 as the first-tier reseller. Distributor 302, however, may provide the acceptance proxy to retail vendor 304. Retailer 304 may register the acceptance proxy using producer 300's registration process 308. Registration process 308 may register that the acceptance proxy has been distributed a second time using entitlement service 310. In this manner, producer 300 knows that the acceptance proxy has been distributed twice, and the next registration belongs to customer 306.
In an embodiment, entitlement service 310 may manage acceptance proxy registration information. Entitlement service 310 may, for example, store registration information in a database table or any other data structure. Entitlement service 310 may store a unique identifier for each acceptance proxy, a level number associated with the acceptance proxy, the number of times the acceptance proxy has been registered, an identifier associated with the registrant, whether the acceptance proxy is activated, and whether escrow is satisfied (if applicable, as discussed below). For example, Table 1 depicts a populated database table managed by entitlement service 310.
As shown in Table 1, acceptance proxy 101 is for a two-tiered system and has been registered three times. The first time is to Vendor1, which may be distributor 302, the second time is to Vendor2, which may be retailer 304, and the final time is to Customer1, which may be customer 306. While the Registrant column in Table shows the individual vendors, this information may be anonymous as discussed in reference to
Acceptance proxies may control distribution for any number of tiers, or no tiers. For example, acceptance proxy 103 represents a sale straight from a producer to a customer (i.e. Customer3). This direct sale does not involve a tiered distribution, and the level is therefore 0. Similarly, acceptance proxy 104 represents a single tier of distribution. The level for proxy 104 is therefore 1. A producer may distribute the acceptance proxy to Vendor5, who may in turn transfer the acceptance proxy to Customer4.
Turning back to
Once customer 306 has registered their acceptance proxy with producer registration process 308, customer 306 may attempt to access service 301. Customer 306 may first provide login credentials to login service 309 for validation. These login credentials could be, for example, a username/password and the acceptance proxy. Customer 306 may then access one or more services 301 for consumption in accordance with the offering exposition. Service 301 may validate the customer using entitlement validation service 311, which may query entitlement service 310 to ensure the acceptance proxy is activated. If the acceptance policy has been activated, service 301 may be provided to customer 306. If the acceptance policy is not activated, access to the service may be denied until the acceptance proxy is activated and/or the times-registered equals the proxy's level.
In some embodiments, entitlement validation service 311 may perform further authentication by comparing a customer identifier with the Registrant column. For example, Customer 306 may provide a customer identifier when accessing service 301. During the validation process, entitlement validation service 311 may check that the acceptance proxy is associated with the customer identifier when verifying the acceptance proxy is activated. If the acceptance proxy is associated with some other entity, access to the service may be denied. This may prevent unauthorized access by some third party, and unauthorized acceptance proxy resale by the customer.
The architecture of
With reference to
The system of
The architecture shown in
Similar to retailer 404, customer 406 may register its acceptance proxy with its immediate predecessor. Retailer 404 may map customer 406's identity to an anonymous identifier using identify mapping service 405, and register the proxy with distributor 402. Distributor 402 may in turn register the acceptance proxy with registration process 408 using the customer's anonymous identifier.
While
In some embodiments, a hybrid of the systems of
Turning now to
At 502 a registration request comprising an acceptance proxy and a registrant identifier may be received. The registration request could be received, for example, at retailer 404, distributor 402, and/or producer 400. In some embodiments, the registrant identifier may identify a reseller, such as a wholesaler, retailer, vendor, customer, or any other entity capable of consuming a service or distributing an acceptance proxy. Additionally or alternatively, the registrant identifier may be anonymous, as discussed in detail below.
At 504, the acceptance proxy and registrant identifier may be registered in response to the registration request. For example, they may be registered using entitlement service 310 or 410. Registering this information may comprise updating a database table, such as Table 1. For example, the acceptance proxy may be stored in the Acceptance Proxy ID column and the registrant identifier may be stored in the Registrant column. Registering the request may further comprise updating a count associated with the acceptance proxy. For example, the count may be stored in the Times Registered column of Table 1. This update may be performed, for example, using producer entitlement service 310 or 410.
At block 506, the acceptance proxy is activated when the count reaches a level. This activation could involve, for example, noting that the acceptance proxy is activated using an “Activated” column as discussed in reference to Table 1.
With reference to
At block 602, a registration request may be received from a vendor. The registration request may comprise an acceptance proxy and an anonymous customer identifier associated with the vendor's customer. For example, producer 400 may receive an anonymous identifier from wholesale vendor 402, where the anonymous identifier is associated with retail vendor 404.
At block 604, the acceptance proxy an anonymous registrant identifier may be registered. This registration process could, for example, updating a data structure managed by entitlement service 410.
At block 606, the acceptance proxy may be activated when a count reaches a specified level. This activation may be substantially similar to that discussed in reference to
Turning now to
At block 702, the service consumer may be authenticated in response to the login request. This could be accomplished, for example, by verifying a user name and password combination.
At 704, a request to access a service may be received. The service may be, for example, service 301 or 401, and the request may come from a service consumer, such as customer 306 or 406. The access request may comprise the acceptance proxy associated with a given service, customer login credentials, and/or a customer identifier.
At block 706, a check may be made to determine whether the designated level has been reached. This check could be made, for example, using entitlement validation service 311 and/or 411. In an embodiment, the count may be defined in the offering exposition and/or tariff, and may designate the number of authorized intermediaries between the producer and the final customer. For example, a check of Table 1 may determine whether the Times Registered column equals the Level column plus one. Additionally or alternatively, the check may only evaluate the Activated column with the understanding that the column will only be true if the count exceeds the level.
In some embodiments, the check at 706 may also verify the service consumer is last registrant associated with the acceptance proxy. In other words, the check may determine the service consumer is the party authorized to consume the service. This may be accomplished by comparing a registrant identifier or anonymous identifier provided by the consumer with the value in the Registrant column. If the Registrant value for an activated acceptance proxy matches the provided identifier, the service consumer is authorized to consume the service. This may provide an additional level of security beyond user authentication.
Finally, at block 708 access to the service may be provided to the customer when the acceptance proxy is activated.
In some embodiment, the login request and the access request may be received contemporaneously, or may be the same request. For example, a single access request may be received comprising login information for login service 309 and/or 409, and an acceptance proxy and identifier for service 301.
Turning now to
Escrow 802 may be in communication with each of the contracting parties. This communication is show by the black, bidirectional arrows. Notifications may be sent to escrow 802 as each party satisfies its contractual obligations. For example, retailer 804 may notify escrow 802 when customer 806 pays retailer 804 for the acceptance proxies. Similarly, customer 806 may notify escrow 802 when customer 806 receives the acceptance proxies. Once each party has notified escrow 802 that the contractual obligations owed to it are satisfied, escrow 802 may notify entitlement service 810 that escrow is satisfied an service may be provided (assuming the proxy is activated).
With reference to both
Proxy ID 102, however, is also registered to Customer 2. This entry notes that the proxy is activated, and escrow is satisfied. When the customer attempts to access service 801 using the acceptance proxy, entitlement validation service 811 will check entitlement service 810 to confirm the proxy is activated and escrow is satisfied. The customer will then be able to access the service.
The terms vendor, wholesaler, producer, and customer used herein may refer to general purpose computer systems owned by an organization or individual. They are not, necessarily, the organization or individual themselves. Additionally, the terms sell or distribute may mean an electronic data transmission. For example, “selling” acceptance proxies may involve transmitting them from one general-purpose computer to another over a physical network connection.
For the sake of clarity, the processes and methods herein have been illustrated with a specific flow, but it should be understood that other sequences may be possible and that some may be performed in parallel, without departing from the spirit of the invention. Additionally, steps may be subdivided or combined. As disclosed herein, software written in accordance with the present invention may be stored in some form of computer-readable medium, such as memory or CD-ROM, or transmitted over a network, and executed by a processor.
All references cited herein are intended to be incorporated by reference. Although the present invention has been described above in terms of specific embodiments, it is anticipated that alterations and modifications to this invention will no doubt become apparent to those skilled in the art and may be practiced within the scope and equivalents of the appended claims. More than one computer may be used, such as by using multiple computers in a parallel or load-sharing arrangement or distributing tasks across multiple computers such that, as a whole, they perform the functions of the components identified herein; i.e. they take the place of a single computer. Various functions described above may be performed by a single process or groups of processes, on a single computer or distributed over several computers. Processes may invoke other processes to handle certain tasks. A single storage device may be used, or several may be used to take the place of a single storage device. The disclosed embodiments are illustrative and not restrictive, and the invention is not to be limited to the details given herein. There are many alternative ways of implementing the invention. It is therefore intended that the disclosure and following claims be interpreted as covering all such alterations and modifications as fall within the true spirit and scope of the invention.
Number | Name | Date | Kind |
---|---|---|---|
4250550 | Fleischer | Feb 1981 | A |
4937863 | Robert | Jun 1990 | A |
5014234 | Edwards, Jr. | May 1991 | A |
5023907 | Johnson | Jun 1991 | A |
5386369 | Christiano | Jan 1995 | A |
5689233 | Kurisu et al. | Nov 1997 | A |
5864620 | Pettitt | Jan 1999 | A |
5995092 | Yuen | Nov 1999 | A |
6009401 | Horstmann | Dec 1999 | A |
6009525 | Horstmann | Dec 1999 | A |
6044469 | Horstmann | Mar 2000 | A |
6163738 | Miller | Dec 2000 | A |
6191695 | Tatsuno | Feb 2001 | B1 |
6289452 | Arnold | Sep 2001 | B1 |
6519571 | Guheen et al. | Feb 2003 | B1 |
6629081 | Cornelius et al. | Sep 2003 | B1 |
6651706 | Litt | Nov 2003 | B2 |
6948070 | Ginter | Sep 2005 | B1 |
7095854 | Ginter et al. | Aug 2006 | B1 |
7133846 | Ginter et al. | Nov 2006 | B1 |
7762470 | Finn et al. | Jul 2010 | B2 |
7849018 | Warner | Dec 2010 | B1 |
8135413 | Dupray | Mar 2012 | B2 |
8296733 | Phillips et al. | Oct 2012 | B2 |
8667382 | Martin, Jr. | Mar 2014 | B2 |
8725700 | Rappaport | May 2014 | B2 |
20020104071 | Charisius et al. | Aug 2002 | A1 |
20020116257 | Helbig | Aug 2002 | A1 |
20020138441 | Lopatic | Sep 2002 | A1 |
20020198629 | Ellis | Dec 2002 | A1 |
20030009423 | Wang | Jan 2003 | A1 |
20030046244 | Shear et al. | Mar 2003 | A1 |
20030182563 | Liu | Sep 2003 | A1 |
20030187794 | Irwin et al. | Oct 2003 | A1 |
20030220880 | Lao | Nov 2003 | A1 |
20040025058 | Kuriya | Feb 2004 | A1 |
20040039916 | Aldis | Feb 2004 | A1 |
20040133488 | Daidone et al. | Jul 2004 | A1 |
20040186785 | Basil et al. | Sep 2004 | A1 |
20040193545 | Shlasky | Sep 2004 | A1 |
20050050315 | Burkhardt | Mar 2005 | A1 |
20050076334 | Demeyer | Apr 2005 | A1 |
20050137984 | Nguyen | Jun 2005 | A1 |
20050149458 | Elgen et al. | Jul 2005 | A1 |
20060178918 | Mikurak | Aug 2006 | A1 |
20060212364 | Lawe | Sep 2006 | A1 |
20070033273 | White et al. | Feb 2007 | A1 |
20070043608 | May et al. | Feb 2007 | A1 |
20070100762 | Luo et al. | May 2007 | A1 |
20080126271 | Zanlongo | May 2008 | A1 |
20080172309 | Reimer | Jul 2008 | A1 |
20080272934 | Wang et al. | Nov 2008 | A1 |
20080281915 | Elad et al. | Nov 2008 | A1 |
20090031286 | Yee et al. | Jan 2009 | A1 |
20090055252 | Samuel | Feb 2009 | A1 |
20090271342 | Eder | Oct 2009 | A1 |
20100076835 | Silverman | Mar 2010 | A1 |
20100091964 | Daidone et al. | Apr 2010 | A1 |
20100205152 | Ansari | Aug 2010 | A1 |
20100274727 | Peterson | Oct 2010 | A1 |
20110010304 | Chan Wong et al. | Jan 2011 | A1 |
20110093371 | Clemm | Apr 2011 | A1 |
20110202443 | Martin | Aug 2011 | A1 |
20110295722 | Reisman | Dec 2011 | A1 |
20120005050 | Boldyrev et al. | Jan 2012 | A1 |
20120127509 | Faber | May 2012 | A1 |
20120155296 | Kashanian | Jun 2012 | A1 |
20120155478 | Lake et al. | Jun 2012 | A1 |
20120197722 | Mesaros | Aug 2012 | A1 |
20120253901 | Montgomery et al. | Oct 2012 | A1 |
20120290339 | Sussman et al. | Nov 2012 | A1 |
20130013459 | Kerr et al. | Jan 2013 | A1 |
20130091209 | Bennett | Apr 2013 | A1 |
20130326637 | Fang et al. | Dec 2013 | A1 |
20140108789 | Phatak | Apr 2014 | A1 |
20140129288 | Eager | May 2014 | A1 |
20140172625 | Reisman | Jun 2014 | A1 |
20140373175 | Kacharia | Dec 2014 | A1 |
20140379595 | Slattery | Dec 2014 | A1 |
20150058076 | Leff | Feb 2015 | A1 |
20160277261 | Ansari | Sep 2016 | A9 |