Abstract:
An embodiment relates generally to a method of managing entitlements. The method includes receiving an indication of at least one purchase of a product by a user and determining an entitlement history of the user. The method also includes determining a plurality of purchasing conditions based on the entitlement history state and the at least one purchase of the product and providing the plurality of purchasing conditions for a user to select.

Description:
FIELD 
       [0001]    This invention relates generally to entitlements, more particularly, to systems and methods for consolidated entitlement management. 
       DESCRIPTION OF THE RELATED ART 
       [0002]    The proliferation of the World Wide Web through the Internet has made a wealth of products and services available to users to purchase and use nearly instantaneous. Vendors, service providers, manufacturers, third party distributors, etc., may have web sites for the users to review and purchase their respective products and/or services. 
         [0003]    As users visit web sites to purchase respective products and/or services, the products and/or services can often have an associated operating period. For example, a user may purchase a technical support contract for a year to service a purchased product or a software package provides free updates for two years. Accordingly, any type of limited period of time service or license associated with a product and/or service can be regarded as an entitlement. 
         [0004]    Users often purchase products or services over a long period of time. As a result, the list of products and/or services that a user must track can accumulate to a large number especially if the user is a system administrator managing an informational technology department of a large corporation. As the number of products and/or services purchases grows over time, the managing of the associated entitlements can become burdensome. Although the vendors can often send electronic reminders or have their sales staff remind the user of renewals, the user may still have to expend a large amount of time to organize and manage the associated entitlements to ensure continuous operation of the respective products and/or services. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]    Various features of the embodiments can be more fully appreciated, as the same become better understood with reference to the following detailed description of the embodiments when considered in connection with the accompanying figures, in which: 
           [0006]      FIG. 1  depicts an exemplary system in accordance with an embodiment; 
           [0007]      FIG. 2  illustrates an exemplary service portal of the system shown in  FIG. 1  in accordance with another embodiment; 
           [0008]      FIG. 3  depicts an exemplary entitlement manager module shown in  FIG. 1  in accordance with yet another embodiment; 
           [0009]      FIG. 4  illustrates an exemplary user profile record in accordance with yet another embodiment; 
           [0010]      FIG. 5  depicts an exemplary database record in accordance with yet another embodiment; 
           [0011]      FIG. 6  illustrates an exemplary flow diagram executed by the entitlement manager module in accordance with yet another embodiment; 
           [0012]      FIG. 7  depicts an exemplary GUI in accordance with yet another embodiment; 
           [0013]      FIG. 8  illustrates another exemplary GUI in accordance with yet another embodiment; and 
           [0014]      FIG. 9  depicts an exemplary computing platform in accordance with yet another embodiment. 
       
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
       [0015]    For simplicity and illustrative purposes, the principles of the present invention are described by referring mainly to exemplary embodiments thereof. However, one of ordinary skill in the art would readily recognize that the same principles are equally applicable to, and can be implemented in, all types of information portals, and that any such variations do not depart from the true spirit and scope of the present invention. Moreover, in the following detailed description, references are made to the accompanying figures, which illustrate specific embodiments. Electrical, mechanical, logical and structural changes may be made to the embodiments without departing from the spirit and scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense and the scope of the present invention is defined by the appended claims and their equivalents. 
         [0016]    Embodiments relate to systems and methods for managing entitlements for a user. More particularly, products (hardware, software, services, etc.) purchased from a service portal can have associated entitlements. An entitlement can be any type of service or license associated with a product that may have an operating period. For example, a software application product may permit a user to an entitlement of one year of free software support plus an option for live chat for three months. Another example can be a user pack associated with a previously purchased product that may have an operating life of one year. 
         [0017]    A consolidated entitlement manager can be configured to provide a mechanism for a user to manage the associated entitlements with any product purchased from the service portal. More particularly, the consolidated entitlement manager can provide the purchasing user a mechanism to manage the associated entitlements with past purchases of products as well as current and future purchases of items on the service portal. For example, a selected user may have purchased Product A with a one year support service contract. One month later, the same user can purchase Product B with a two-year support service contract. The entitlement manager can then be configured to provide several buying options for the user. The consolidated entitlement manager can determine the price point options for synchronizing the support services contract, either extending service contract for Application A, pro-rating service contract for Application B or purchase as selected. Accordingly, a purchasing user can be provided with options on how to cost effectively manage the products purchased from the service portal. 
         [0018]      FIG. 1  illustrates an exemplary system  100  in accordance with an embodiment. It should be readily apparent to those of ordinary skill in the art that the system  100  depicted in  FIG. 1  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. Moreover, the system  100  may be implemented using software components, hardware components, or combinations thereof. 
         [0019]    As shown in  FIG. 1 , the system  100  includes users  105 , a network  110  and a service portal  115 . The users  105  can be private individuals, employees of private business or public entities or other persons interested in accessing the service portal  115 . The users  105  can access the service portal  115  using personal computers, personal mobile devices, workstations or other networked computing platforms. 
         [0020]    The network  110  can be a combination of wide area and local area networks such as the Internet. The network  110  can be configured to provide a communication channel between the users  105  and the service portal  115 . The network  110  can implement a variety of network protocols to provide the communication channel such as Internet Protocol (“IP”) Vx, ATM, SONET, or other similar network protocols. 
         [0021]    The service portal  115  can be configured to provide products and services to the user  105  as well as provisioning, installation services, updates to software and hardware products and technical support. The service portal  115  can, among other functions, provide a list of products such as software applications or hardware devices as well as services such as installation, configuration, maintenance, etc., for users to purchase. As a non-limiting example, the service portal  105  can also provide information for users to research, compare and purchase software, hardware and consulting services in support of those software and/or hardware purchases. The service portal  105  can also be configured to provide support services by subscription to those same software, service, and/or hardware purchases. 
         [0022]    In accordance with various embodiments, the service portal  115  can be configured to provide consolidated entitlement management by an entitlement manager  120 . More specifically, the entitlement manager  120  can provide a mechanism for a user to manage the associated entitlements with any product and/or service purchased from the service portal  115  along with any previous purchases. For example, a selected user may have purchased Product A with a one year support service contract. One month later, the same user can purchase Product B with a two-year support service contract. The entitlement manager  120  can then be configured to provide several buying options for the user. The entitlement manager  120  can determine the price point options for synchronizing the support services contract, i.e., either extending service contract for Application A, pro-rating service contract for Application B, or purchase as selected. Accordingly, a purchasing user can be provided with options on how to cost effectively manage the products and/or services purchased from the service portal  120 . 
         [0023]      FIG. 2  illustrates a more detailed block diagram of the service portal  105  in accordance with another embodiment. It should be readily apparent to those of ordinary skill in the art that the service portal  115  depicted in  FIG. 2  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. 
         [0024]    As shown in  FIG. 2 , the service portal  115  can include a web store module  205  that a user can interface with the service portal. The web store module  205  can provide the graphical user interfaces (“GUIs”) and associated functions and/or services for the service portal  115 . As an non-limiting example, the web store module  205  can generate a log-in GUI for a user to authenticate and enter the service portal  115 . 
         [0025]    The web store module  205  can couple with an application program interface (“API”) module  210 . The API module  210  can be configured to provide an interface between the functions and/or services provided by the web store module  205  and to the appropriate module of the service portal  115 . More particularly, the API module  210  can call or direct a requested function or service from the user to the respective module that provides that requested function or service. For example, a user may request a price of a product, e.g., an electronic mail program, the API module  210  can direct the request to a get price function in a support tools module  215 . 
         [0026]    The API module  210  can also be configured to interface with the support tools module  215 . The support tools module  215  can be configured to provide the supporting software and hardware to implement the functionality of the service portal  115 . The support tools module  215  can contain and provide access to databases that contain information such as products lines, services providers, on-line self-help (e.g., knowledgebase), etc. The support tools module  215  can also provide services like a chat services, a help desk, installation, provisioning, etc. 
         [0027]    The API module  210  can be further configured to couple with an identification (“ID”) module  220 . The ID module  220  can be configured to provide identification management services for the service portal  115 . The ID module  220  can also store information related to users such as purchase history, user profile, usage history of the user, and entitlement data. 
         [0028]    The API module  210  can be further configured to couple with a universal messaging module  225 . The universal messaging module  225  can be configured to provide a messaging application that unifies messages. More specifically, electronic mail (“email”), documents, and instant messaging can be linked in a single application. The universal messaging module  225  can also provide a mechanism for a user to view all the related documents for the user from email to Wiki pages. 
         [0029]    An installer tools  230  can be coupled to the API module  210 . One of the services provided by the service portal  115  can be the purchase of software applications provided by independent software vendors (“ISVs”). As part of the delivery of the software applications, the ISV can be required to maintain and update the installation tools to install their respective software applications. Accordingly, the install tools  230  can be a repository where independent software vendors can deposit their respective installation tools. 
         [0030]    The API module  210  can be further coupled to the communication layer  235  (labeled as COMM layer in  FIG. 2 ). The comm layer  235  can be configured to provide the underlying services for the modules of the service portal  115  to communicate. For example, the comm layer  225  can contain middleware for a product database to communicate with a graphical user interface requesting product description. 
         [0031]    The API module  210  can be further coupled to an application management module  240  (labeled as APP MGMT in  FIG. 2 ). The application management module  240  can be configured to manage applications as requested by users. More specifically, a user may purchase a prepackaged software application pack (e.g., an operating system, electronic mail program and data mining program) from the service portal  115 , the which is stored in the application stack module  245 . The application management module  240  can then deliver the purchased software stack, install and configure the software application stack at a third party site such as server farm  250  or store the software application stack in the storage farm  255  for the user to retrieve. 
         [0032]    The server farm  250  can be configured to provide computing platforms users to lease. Accordingly, users can have a backup version of their systems, a testing platform to perform quality assurance tests on new applications, execute a program requiring excess MIPS, or any other similar computing task. 
         [0033]    The storage farm  255  can be configured to provide storage space for users to lease. Accordingly, users can lease disk storage space to back up data, provide a hot data swap, or other storage intensive tasks. 
         [0034]    In some embodiments, the entitlement manager  120  can be configured to be executed in the support tools module  215 . In other embodiments, the entitlement manager  120  can be a module of the ID module  220 : In yet other embodiments, the entitlement manager  120  can be executed as a standalone module. 
         [0035]      FIG. 3  depicts a more detailed block diagram of the entitlement manager  120  in accordance with another embodiment. It should be readily apparent to those of ordinary skill in the art that the entitlement manager  120  depicted in  FIG. 3  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. 
         [0036]    As shown in  FIG. 3 , the entitlement manager  120  can comprise an entitlement manager module  305 , the user interface module  310 , a rules module  315 , a profile data interface  320 , an entitlement data interface  325 , a purchasing system interface  330  and a product database interface  335 . It should be readily obvious to one of ordinary skill in the art that the modules  305 - 335  can be implemented as software applications (programmed in C, C++, JAVA, PHP, etc.), hardware components (EEPROM, application specific integrated circuit, microprocessor, etc.) or combinations thereof. 
         [0037]    The entitlement manager module  305  can be configured to manage and interface with the other modules  310 - 335  to provide the functionality of the entitlement manager  120  as described above and further described hereinbelow. 
         [0038]    The user interface module  310  can be configured to generate graphical user interface (“GUIs”) as required by the entitlement manager module  305 . For example, the user interface module  310  can generate a product/service browse GUI for a user to view the products and services available for purchase on the service portal  115 . As part of the product/service browse GUI, a search widget can be placed on this GUI for a user to focus the search in a timely and efficient manner. 
         [0039]    The entitlement manager module  305  can also be coupled to the rules module  315 . The rules module  315  can be configured to store the heuristics or algorithms to determine the various purchase conditions based on the purchase history and entitlement data of a user. For example, one rule can be to calculate the cost of extending all previously purchased entitlements with a current selection of product or service. Another example of a rule or heuristic can be to calculate the cost of pro-rating the current selection of product or service with the earliest entitlement. Other rules can be implemented as required by the system administrators of the service portal  115 . 
         [0040]    The entitlement manager module  305  can also be coupled to the profile data interface  320 , which is configured to retrieve the profile data of the purchasing user. The profile data can be stored in the ID module  220  or, in other embodiments, the profile data can be stored in a remote secure location. Regardless, the profile data interface  320  can provide the communication channel to the persistent storage device that stores the profile data. 
         [0041]    The profile data can contain information associated with a user, as depicted in  FIG. 4 . As shown in  FIG. 4 , the profile data schema  400  can comprise a user identification field  405 , a first name field  410 , a last name field  415 , a billing address  420 , a last log-in field  425 , a user history field  430 , and a payment method field  430 . It should be readily obvious to one of ordinary skill in the art that the schema  400  is a schematic representation and that additional fields could be added or the existing fields may be removed or amended without departing from the scope of the claimed invention. 
         [0042]    The user identification (labeled as USER ID in  FIG. 4 ) field  405  can store the log-in name of the user to access the service portal  115 . The user can obtain a user ID when the user registers in the service portal  115 . 
         [0043]    The first name field  410  can store the first name of the legal name of the user. Similarly, the last name field  415  can store the surname of the legal name of the user. 
         [0044]    The billing address field  420  can store the address where the user would prefer the bills from the service portal  115  to be sent. The last log-in field  425  can be configured to store the previous log-in date and time when the user last visited the service portal  115 . 
         [0045]    The user history field  430  can be configured to contain information related to the past visits of the user to the user portal. This field  430  can contain the number of visits to a help desk, how often the user uses the knowledgebase, or other activities that the system administrator would like to track. This information can then be used to improve the existing functionality of the service portal  115  or to add additional functions. 
         [0046]    The payment method field  435  can store the method of payment for services and/or products that the user purchases. For example, this field  435  can store the corporate credit card or an account number to bill. 
         [0047]    Returning to  FIG. 3 , the entitlement manager module  305  can also be coupled to the entitlement data interface  325 , which is configured to retrieve the entitlement data of the purchasing user. The entitlement data can be stored in the entitlement manager  120 , the ID module  220  or, in other embodiments, the entitlement data can be stored in a remote secure location. Regardless, the entitlement data interface  325  can be provide the communication channel to the persistent storage device that stores the entitlement data. 
         [0048]    The entitlement data can contain the entitlement information associated with a user, as depicted in  FIG. 5 . As shown in  FIG. 5 , the entitlement data schema  500  can comprise a product purchased field  505 , an entitlement field  510 , a date purchased field  515 , and a current expiration field  520 . It should be readily obvious to one of ordinary skill in the art that the schema  500  is a schematic representation and that additional fields could be added or the existing fields may be removed or amended without departing from the scope of the claimed invention. 
         [0049]    The product purchased field  505  can be configured to store the name of the product or service purchased by a user. The name can be represented by a SKU number, UPC number, textual description, or some predefined convention. The entitlement field  510  can store the type of entitlement associated with the product. For example, one type of entitlement can be a subscription for one year of technical support. Another type of entitlement can be license to operate a product for a year (e.g., user packs). In other words, entitlements can be items associated with a product that has a limited operating life. 
         [0050]    The date purchased field  515  can indicate the date of purchase of the product or service purchased. The current expiration field  520  can be configured to store the date that the associated entitlement is going to expire. For example, a support contract indicated in entitlement field  520  can be set to expire on the date of January 30, 2008, which would be stored in the current expiration field  520 . 
         [0051]    Returning to  FIG. 3 , the entitlement manager module  305  can be further coupled to the purchasing system interface  330  and the product database interface  335 . The purchasing system interface  330  can be configured for the entitlement manager module  305  to send user selected products and/or services to be purchased. The product database interface  335  can be configured to allow the entitlement manager module  305  to retrieve information about available products and/or services for purchase on the service portal  115 . The entitlement manager module  305  can retrieve this information to display for a user to view, browse and select. 
         [0052]      FIG. 6  illustrates a flow diagram  600  executed by the entitlement manager module  305  in accordance with yet another embodiment. It should be readily apparent to those of ordinary skill in the art that the flow diagram  600  depicted in FIG.  6  represents a generalized schematic illustration and that other steps may be added or existing steps may be removed or modified. 
         [0053]    As depicted in  FIG. 6 , the entitlement manager module  305  can be configured to generate a browsing graphical user interface (GUI) for purchasing products and services, in step  605 . More particularly, a purchasing user can log-in into the service portal  105 . After the purchasing user is authenticated, a home page for the service portal  115  can be displayed. The purchasing user can select an option to purchase products and/or services provided by the service portal  115  and the user can then be directed to the browsing GUI. 
         [0054]    An exemplary embodiment of the browsing GUI  700  is depicted in  FIG. 7 . It should be readily apparent to those of ordinary skill in the art that the browsing GUI  700  depicted in  FIG. 7  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. 
         [0055]    As shown in  FIG. 7 , the browsing GUI  700  can comprise a product heading  705  and a services heading  710 . Under the product heading  705 , a product list  715  can be displayed. Each product  720  have a selection button  725 . Similarly, a service list  730  can be displayed under the service heading  710  with respective selection buttons  735  associated with a service  740 . Accordingly, a user can select a single or multiple products and/or services to purchase. Although not shown, other embodiments of the browsing GUI  700  can include a search dialog box to narrow the selection of products and/or services. 
         [0056]    The next button  745  can be configured to take the user selection and package the selected products and/or services to the purchasing system of the service portal  115  and a copy of the selected products and/or services to be stored temporarily by the entitlement manager module  305 . The cancel button  750  can be configured to cancel the prospective transaction and return the user to the home page of the service portal  115 . 
         [0057]    Returning to  FIG. 6 , the entitlement manager module  305  can be configured to enter a wait state until the user activates the next button  745  on the browsing GUI  700 , in step  610 . More particularly, the entitlement manager module  305  can store the selected products and/or services in a temporary buffer in response to the activation of the next button  745 . Although not shown, if the user activates the cancel button  750  of the displayed browsing GUI  700 , the entitlement manager module  305  can stop executing flow diagram  600 . 
         [0058]    In step  615 , the entitlement manager module  305  can be configured to determine associated entitlements of the selected products and/or services. More specifically, the entitlement manager module  305  can send a query through the product database interface  335  to retrieve the associated entitlements. The associated entitlement data for the selected products and/or services are also temporarily buffered by the entitlement manager module  305 . The associated entitlement data can comprise length of time for the associated entitlement as well as as cost among other items. 
         [0059]    In step  620 , the entitlement manager module  305  can be configured to send another query through the entitlement data interface  325  to retrieve a user history of previously purchased entitlements, i.e., a user history state. The user history can include information such as current start dates, current expiration dates, length of time for the retrieved entitlements. The user history can then be buffered by the entitlement manager module  305  in a temporary buffer. 
         [0060]    In step  625 , the entitlement manager module  305  can be configured to apply the entitlement rules from the rules module  315  to the associated entitlement data for the selected products and/or services and the user history of previously purchased entitlements. More specifically, the entitlement rules can be applied to determine multiple purchasing conditions or scenarios based on the current selected products and/or services and past entitlements. The purchasing conditions are then displayed on a purchasing GUI shown in  FIG. 8 , in step  630 . 
         [0061]      FIG. 8  depicts an exemplary purchasing GUI  800  in accordance with yet another embodiment. It should be readily apparent to those of ordinary skill in the art that the purchasing GUI  800  depicted in  FIG. 8  represents a generalized schematic illustration and that other components may be added or existing components may be removed or modified. 
         [0062]    As shown in  FIG. 8 , the purchasing GUI  800  can comprise a header line  805  that depicts purchasing option for the selected products and/or services. GUI  800  can also comprise a purchasing conditions list  810  with purchasing condition  815 - 825  with respective selection buttons  830 . Purchasing condition  815  indicates the cost for extending any previously purchased entitlements to coincide with the termination of the current selected products and/or services for a certain amount. Purchasing condition  820  can indicate the cost for pro-rating the current entitlement of the selected product and/or service to the current expiration of a previously purchased product and/or service. Purchasing condition  825  indicates the cost of purchasing the selected product and/or service as currently selected. 
         [0063]    The GUI  800  can further comprise a purchase button  835  and a cancel button  840 . A user can select one of the purchasing conditions and activate the purchase button  835  to complete the transaction. A user can also activate the cancel button  840  to cancel the current selection and return to the browsing GUI  700 . 
         [0064]    Returning to  FIG. 6 , the entitlement manager module  305  can be configured to enter a wait state for the purchasing user to select either the purchase button  835  or the cancel button  840 , in step  635 . 
         [0065]    In step  640 , the entitlement manager module  305  can be configured to receive the purchase indication from the activation of the purchase button  835 . More specifically, the entitlement manager module  305  can be configured to pass the information from the selected purchasing condition to the purchasing system of the service portal  115  through the purchasing system interface  330 . 
         [0066]    In step  645 , the entitlement manager module  305  can be configured to update the entitlement data with the purchased product and/or service with the associated entitlement through the entitlement data interface  325 . 
         [0067]      FIG. 9  illustrates an exemplary block diagram of a computing platform  900  where an embodiment may be practiced. The functions of the entitlement manager  120  may be implemented in program code and executed by the computing platform  400 . The entitlement manager  120  may be implemented in computer languages such as PASCAL, C, C++, JAVA, etc. 
         [0068]    As shown in  FIG. 9 , the computer system.  900  includes one or more processors, such as processor  902  that provide an execution platform for embodiments of the entitlement manager  120 . Commands and data from the processor  902  are communicated over a communication bus  904 . The computer system  900  also includes a main memory  906 , such as a. Random Access Memory (RAM), where the entitlement manager  120  may be executed during runtime, and a secondary memory  908 . The secondary memory  908  includes, for example, a hard disk drive  910  and/or a removable storage drive  912 ; representing a floppy diskette drive, a magnetic tape drive, a compact disk drive, etc., where a copy of a computer program embodiment for the entitlement manager  120  may be stored. The removable storage drive  912  reads from and/or writes to a removable storage unit  914  in a well-known manner. A user interfaces with the entitlement manager  120  with a keyboard  916 , a mouse  918 , and a display  920 . The display adapter  922  interfaces with the communication bus  904  and the display  920 . The display adapter  922  also receives display data from the processor  902  and converts the display data into display commands for the display  920 . 
         [0069]    Certain embodiments may be performed as a computer program. The computer program may exist in a variety of forms both active and inactive. For example, the computer program can exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats; firmware program(s); or hardware description language (HDL) files. Any of the above can be embodied on a computer readable medium, which include storage devices and signals, in compressed or uncompressed form. Exemplary computer readable storage devices include conventional computer system RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. Exemplary computer readable signals, whether modulated using a carrier or not, are signals that a computer system hosting or running the present invention can be configured to access, including signals downloaded through the Internet or other networks. Concrete examples of the foregoing include distribution of executable software program(s) of the computer program on a CD-ROM or via Internet download. In a sense, the Internet itself, as an abstract entity, is a computer readable medium. The same is true of computer networks in general. 
         [0070]    While the invention has been described with reference to the exemplary embodiments thereof, those skilled in the art will be able to make various modifications to the described embodiments without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the method has been described by examples, the steps of the method may be performed in a different order than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.