Patent Publication Number: US-11379338-B2

Title: Customizing option-selections in application based on usage pattern

Description:
FIELD 
     The field relates generally to information processing systems, and more particularly to techniques for automatically customizing selection options presented to users in such information processing systems. 
     BACKGROUND 
     Many application programs (applications) today utilize a “right-click” operation. For example, in the right-click operation, an onscreen cursor is placed over an onscreen feature and the user clicks their pointing device (e.g., typically the right most button on a mouse) to display a list of options for selection (e.g., typically a pull-down menu). One of the limitations is that the right-click menu presents a set of options with a fixed rank or order. However, depending on the extent of the flexibility and functionality of the application, usage of the right-click operation to select from available options differs from one user to another. For example, one user may frequently or exclusively select the first option in the menu while others have to scroll down the menu to frequently or exclusively select the last option in the menu. This can be frustrating if the menu has many options. 
     SUMMARY 
     Embodiments of the invention provide techniques for automatically customizing selection options presented to users in an information processing system. 
     For example, in one embodiment, a method comprises the following steps. Data is collected during use of an application program to determine an option-selection usage pattern for a given user with respect to a given option-selection list with options listed in a first order. A recommendation is generated for a modified option-selection list with the options listed in a second order based on the option-selection usage pattern. The recommendation is presented to the given user. 
     The method may further enable the given user to accept or reject the recommendation. When the recommendation is accepted by the given user, the modified option-selection list is then presented to the given user the next time the given user uses the application program, e.g., the next time the user right-clicks on the option-selection list. 
     Advantageously, illustrative embodiments provide an automated tool that transparently learns a right-click usage pattern of the user with respect to an option selection menu in the application and provides an automatic suggestion to the user for the order of different options in the menu. 
     These and other features and advantages of the invention will become more readily apparent from the accompanying drawings and the following detailed description. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  depicts a selection menu customizer based on a right-click usage pattern of a user, according to an illustrative embodiment. 
         FIG. 2  depicts pseudocode for a selection menu customizer based on a right-click usage pattern of a user, according to an illustrative embodiment. 
         FIG. 3  depicts data collected by a selection menu customizer, according to an illustrative embodiment. 
         FIG. 4  depicts a selection menu associated with a records page in a given application program with which a selection menu customizer is implemented, according to an illustrative embodiment. 
         FIG. 5  depicts a data structure for storing data collected by a selection menu customizer, according to an illustrative embodiment. 
         FIG. 6  depicts a customized selection menu generated by a selection menu customizer, according to an illustrative embodiment. 
         FIG. 7  depicts a processing platform used to implement a selection menu customizer based on a right-click usage pattern of a user, according to an illustrative embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Illustrative embodiments may be described herein with reference to exemplary information processing systems such as, but not limited to, computing environments, cloud infrastructure, data repositories, data centers, data processing systems, computing systems, data storage systems and associated servers, computers, storage units and devices and other processing and computing devices. It is to be appreciated, however, that embodiments of the invention are not restricted to use with the particular illustrative system and device configurations shown. Moreover, the phrases “information processing system,” “cloud environment,” “cloud computing platform,” “cloud infrastructure,” “data repository,” “data center,” “data processing system,” “computing system,” “data storage system,” “computing environment,” and the like as used herein are intended to be broadly construed, so as to encompass, for example, any arrangement of one or more processing devices. 
     As mentioned in the background section above, the right-click operation in applications today can be frustrating when a user constantly has to scroll through the fixed rank/order of the selection options to get to the one they most frequently use. For example, consider the RSA® Archer® application which supports business-level management of enterprise governance, risk and compliance (GRC). In the Archer® application today, one of the limitations is that the right-click context menu presents a set of options with a fixed rank or order. The Archer® application is itself a tool which allows users to select solutions in the way that they so desire. With such extensive flexibility, the usage of the right-click operation on a page differs significantly from one user to another. 
     For example, today in the Archer® application&#39;s right-click menu for a records page, the right-click operation presents a significant number of options such as, but not limited to, print, email, recalculate, export, etc. All of these options are presented in a fixed order. However, in Archer®, there is a lack of an automated tool that learns the user&#39;s actions and assists him in his customization. 
     Illustrative embodiments provide such an automated tool that transparently (to the user) learns the right-click usage patterns of the application user and provides automatic suggestions for the order of different options in the menu. A user can then accept the recommendation or reject it. In some embodiments, the user can switch on/off this customizer feature. 
     It is to be appreciated that while illustrative embodiments described herein with reference to  FIGS. 1-6  refer to the Archer® application&#39;s right-click operation, alternative embodiments are not limited to this particular application. Further, embodiments are applicable to automatically customize any user option-selection operation associated with one or more software programs, i.e., embodiments are not limited to a right-click operation. 
     According to illustrative embodiments, a smart right-click customizer silently (transparently) records the right-click usage pattern of a user with respect to an application, with respect to a given right click on a page P. Note that “page” as illustratively used herein refers to any graphical user interface entity which has one or more unique right click menus. After it has recorded N number of entries, in other words, N number of right clicks on a page P, it makes internal calculations and prompts a new recommendation of right-click menu options with a most-used option positioned on the top of the menu list. With N being the collected data window length, this tool keeps discarding some of the previous collected data as it gets a new entry so that the user&#39;s changing preference is taken into account. The suitable value for N can be determined by the tool itself using a conventional re-learning process based on the user&#39;s selection when prompted. The older the data is, the less weight it has so that the more recent the data is, the more value it has. The weight is directly proportional to d or time. In one or more illustrative embodiments, the weights vary with time and all of them are normalized between 0 and 1 so that moderate importance is given to the newest data thus the data values are not biased. 
     Referring initially to  FIG. 1 , an information processing system environment  100  is depicted with a selection menu customizer based on a right-click usage pattern of a user, according to an illustrative embodiment. More particularly,  FIG. 1  shows a user  101  currently viewing a given page  102  of an application (e.g., records page in Archer®) performing a right-click  104  on the page  102 . The right-click is an operation that can be performed by the user  101  one or more times by moving a cursor  106  over a feature on the page  102  and pressing the right button on a mouse to display a meu of selectable options (edit, copy, export as shown in  FIG. 1 ). Thus, each time the user  101  moves the cursor  106  over the feature and selects an option from the menu, it is counted as an individual right-click instance. Multiple instances of right-click selections for this particular feature are considered a right-click pattern. Other ways to perform a right-click  104  are contemplated to be within the scope of various alternative embodiments. Data  110  associated with the right-clicks of user  101  on right-click  104  is collected over time. Black shaded data is used as a current training data set. The length of the current training data window is N (i.e., corresponding to N right-clicks), as mentioned above. Collected data  110  is provided to selection menu customizer  120 . Note that data collected prior to the time interval N is discarded. Customization is performed and one or more notifications  122  are presented to the user  101 , as will be further described herein. 
     More particularly, customizer  120  gives a recommendation with a new ranking for the order of options for a given right-click  104  to the user  101  when he just right-clicked on feature of a page. The recommendation is given after the user  101  has right-clicked N times (corresponding the window length N in  FIG. 1 . That is, customizer  120  predicts, prompts, and then updates N. More specifically, predict means the customizer  120  prepares a customized ranking to be presented to the user  101 . Prompt means the customizer  120  presents a notification  122  to user  101  with the options in the customized rank with an “accept” button and “reject” button for the right-click  104 . Update N happens according to the response of the user  101 , i.e. if he clicked accept, the N is retained because the user is satisfied with the value of N, else if he selects reject, N is incremented by a small random number so that more older actions of the user can be considered (expand the window length of N). Note that there is no restriction on what the length of N (the number of right-clicks that are to be considered as part of the pattern) can be. In some embodiments, N can be configured by the user  101 , in which case it remains fixed. In other embodiments, N is configured by the system, in which case it changes according to a re-learning algorithm. In still other embodiments, a hybrid of the above methods can be implemented. Note that the pseudocode described next in the context of  FIG. 2  assumes that a re-learning algorithm is applied on N. 
     Pseudocode  200  is depicted in  FIG. 2  for execution by selection menu customizer  120  based on a right-click usage pattern of user  101 , according to an illustrative embodiment. In the pseudocode  200 , although it is mentioned as ‘day d’, it is to be understood that the subject time period need not be a day but rather can be any other time period. Pseudocode  200  is explained below in the context of cuboid  300  depicted in  FIG. 3 . 
     Assume a cuboid is used to capture the user&#39;s actions of all the right-clicks in the application. The cuboid is actually stored as a three-dimensional (3D) array in customizer  120 . The 3D cuboid  300  in  FIG. 3  has a length corresponding to the different right-clicks in the application. The width of cuboid  300  corresponds to the options belonging to the menus of those right-clicks respectively. Time is captured along the depth of cuboid  300 . The values inside the blocks of the cuboid correspond to the count of the number of times that particular right-click was used. For example, cuboid block [0][3][5] represents the number of times the 3 rd  option of right-click with ID 0 was used at the time period or day 5 (assuming that the total K right-clicks in the application are unique and numbered 0 to K). Note that in pseudocode  200 , a right-click is denoted as P or p. 
     In an illustrative embodiment, weights are assigned such that the older the data, the lesser the weight it has. Weight is normalized between 0 and 1. Weight is calculated in an illustrative embodiment as follows. While capturing data in the cuboid, weight is initially kept as unknown because the customizer  120  does not know how many days/periods it takes to complete N right-clicks on a right-click P. Once N number of right-clicks are reached, customizer  120  calculates the number of days/periods (denoted in pseudocode  200  as Q) it took to reach N. Now the weight for day 1 is 1/Q, day 2 has the weight 2/Q, and the weight corresponding to the last day is Q/Q i.e., 1. The entry at cuboid block [p][o][d] represents weight*number of times the p-th right-click was used and o was selected on a day d. 
     A separate array is used to track if a total N number of right-clicks are made on p or not. When N is reached, the weights are calculated and substituted, the total count is made, and finally the user is prompted with the new recommendation  122 . 
     Note that although  FIG. 3  uses a cuboid, it is not always uniform across two dimensions. First, on the dimension of time, since, for example, there are two right-clicks (RC 1  and RC 2 ) in an application where one of the right clicks RC 1  is very rarely used and the count never reaches N, the cuboid area corresponding to the entries of RC 1  is sparse. Whereas, on the other hand, the cuboid area for RC 2  which is heavily used is dense. One part of the cuboid corresponding to RC 2  has invalidated data since the data is old (in some embodiments, the old data needs can be archived or completely discarded) whereas the same part for RC 1  is not invalidated. Secondly, the dimension of options can be different between RC 1  and RC 2 , because each right-click has a different number of options. 
     Thus, at any given point in time, data collected by the customizer  120  is shown in the example cuboid  300  in  FIG. 3 . Assume, as an example, the record browser page  400  in the Archer® application depicted in  FIG. 4 . Assume the Archer® application&#39;s records page is one of the most used pages in the application. Upon a right-click operation on the record, the options that pop-up are as shown in  FIG. 4 . 
     If a user  101  always wants to ‘Edit’ and not ‘open in new window’ for this page, then he would want it to be on the top, similarly if user  101  never uses ‘Recalculate’, then he might be annoyed to see it there. 
     To help him with the menu items order that he wants in a page, a customizer feature (provided by customizer  120 ) is turned ON upon which the transparent learning starts, and recommendations are given. The recommendations can be accepted, or the user can opt to remain with the same settings if he wants, or in some embodiments the user can manually customize the order suggested in the recommendation. Based on his input to the recommendations, N is modified automatically by customizer  120 . 
     By way of example, assume that the Archer® application has K right-clicks. Referring back to  FIG. 3 , note that the cuboid shows data associated with two right-clicks: RC 1  and RC 2 . RC 1  has five options upon a right-click, i.e., Recalculate, Email, Export, Copy and Paste. RC 2  has four options upon a right-click, i.e., Email, Delete, Cut and Export. The third dimension of the cuboid in  FIG. 3  denotes time. Any addition of options/page leads to the additions in the size across x and y dimensions in the cuboid but the z dimension size N is determined by the user&#39;s action as mentioned above. The cuboid is populated as and when the user makes a right-click. 
     Assume, for example, the user actions for RC 2  are as below:
         Let N=20.   Time Interval 1: Never used right-click on RC 2     Time Interval 2: ‘Export’ 2 times. ‘Cut’ 4 times   Time Interval 3: ‘Export’ 5 times. ‘Delete’ 3 times   Time Interval 4: ‘Email’ 3 times, ‘Export’ 3 times   This user right-click usage pattern is depicted in table  500  in  FIG. 5 .       

     A slice of a cuboid corresponding to RC 2  is depicted as  600  in  FIG. 6 . Further, recommendation  602  generated by the customizer  120  for a customized selection menu after time interval 4 is depicted. More particularly, the cuboid for RC 2  in  FIG. 6  shows the values according to the recordings in table  500  of  FIG. 5 . In other words, if user  101  had used RC 2  and the usage pattern is such as the one shown in table  500  of  FIG. 5 , the cuboid would look as shown in  FIG. 6  and the user  101  would get a recommendation  602  according to the calculations shown in  FIG. 6  (N is 20 in this example). 
       FIG. 7  depicts a processing platform  700  used to implement a selection menu customizer based on a right-click usage pattern of a user, according to an illustrative embodiment. More particularly, processing platform  700  is a processing platform on which a computing environment with selection menu customization functionalities (e.g.,  FIGS. 1-6  and otherwise described herein) can be implemented. 
     The processing platform  700  in this embodiment comprises a plurality of processing devices, denoted  702 - 1 ,  702 - 2 ,  702 - 3 , . . .  702 -N, which communicate with one another over network(s)  704 . It is to be appreciated that the methodologies described herein may be executed in one such processing device  702 , or executed in a distributed manner across two or more such processing devices  702 . It is to be further appreciated that a server, a client device, a computing device or any other processing platform element may be viewed as an example of what is more generally referred to herein as a “processing device.” As illustrated in  FIG. 7 , such a device generally comprises at least one processor and an associated memory, and implements one or more functional modules for instantiating and/or controlling features of systems and methodologies described herein. Multiple elements or modules may be implemented by a single processing device in a given embodiment. Note that components described in the architectures depicted in the figures can comprise one or more of such processing devices  702  shown in  FIG. 7 . The network(s)  704  represent one or more communications networks that enable components to communicate and to transfer data therebetween, as well as to perform other functionalities described herein. 
     The processing device  702 - 1  in the processing platform  700  comprises a processor  710  coupled to a memory  712 . The processor  710  may comprise a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other type of processing circuitry, as well as portions or combinations of such circuitry elements. Components of systems as disclosed herein can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device such as processor  710 . Memory  712  (or other storage device) having such program code embodied therein is an example of what is more generally referred to herein as a processor-readable storage medium. Articles of manufacture comprising such processor-readable storage media are considered embodiments of the invention. A given such article of manufacture may comprise, for example, a storage device such as a storage disk, a storage array or an integrated circuit containing memory. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals. 
     Furthermore, memory  712  may comprise electronic memory such as random-access memory (RAM), read-only memory (ROM) or other types of memory, in any combination. The one or more software programs when executed by a processing device such as the processing device  702 - 1  causes the device to perform functions associated with one or more of the components/steps of system/methodologies in  FIGS. 1-6 . One skilled in the art would be readily able to implement such software given the teachings provided herein. Other examples of processor-readable storage media embodying embodiments of the invention may include, for example, optical or magnetic disks. 
     Processing device  702 - 1  also includes network interface circuitry  714 , which is used to interface the device with the networks  704  and other system components. Such circuitry may comprise conventional transceivers of a type well known in the art. 
     The other processing devices  702  ( 702 - 2 ,  702 - 3 , . . .  702 -N) of the processing platform  700  are assumed to be configured in a manner similar to that shown for computing device  702 - 1  in the figure. 
     The processing platform  700  shown in  FIG. 7  may comprise additional known components such as batch processing systems, parallel processing systems, physical machines, virtual machines, virtual switches, storage volumes, etc. Again, the particular processing platform shown in this figure is presented by way of example only, and the system shown as  700  in  FIG. 7  may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination. 
     Also, numerous other arrangements of servers, clients, computers, storage devices or other components are possible in processing platform  700 . Such components can communicate with other elements of the processing platform  700  over any type of network, such as a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or cable network, or various portions or combinations of these and other types of networks. 
     Furthermore, it is to be appreciated that the processing platform  700  of  FIG. 7  can comprise virtual (logical) processing elements implemented using a hypervisor. A hypervisor is an example of what is more generally referred to herein as “virtualization infrastructure.” The hypervisor runs on physical infrastructure. As such, the techniques illustratively described herein can be provided in accordance with one or more cloud services. The cloud services thus run on respective ones of the virtual machines under the control of the hypervisor. Processing platform  700  may also include multiple hypervisors, each running on its own physical infrastructure. Portions of that physical infrastructure might be virtualized. 
     As is known, virtual machines are logical processing elements that may be instantiated on one or more physical processing elements (e.g., servers, computers, processing devices). That is, a “virtual machine” generally refers to a software implementation of a machine (i.e., a computer) that executes programs like a physical machine. Thus, different virtual machines can run different operating systems and multiple applications on the same physical computer. Virtualization is implemented by the hypervisor which is directly inserted on top of the computer hardware in order to allocate hardware resources of the physical computer dynamically and transparently. The hypervisor affords the ability for multiple operating systems to run concurrently on a single physical computer and share hardware resources with each other. 
     It was noted above that portions of the computing environment may be implemented using one or more processing platforms. A given such processing platform comprises at least one processing device comprising a processor coupled to a memory, and the processing device may be implemented at least in part utilizing one or more virtual machines, containers or other virtualization infrastructure. By way of example, such containers may be Docker containers or other types of containers. 
     The particular processing operations and other system functionality described in conjunction with  FIGS. 1-7  are presented by way of illustrative example only, and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of operations and protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another. 
     It should again be emphasized that the above-described embodiments of the invention are presented for purposes of illustration only. Many variations may be made in the particular arrangements shown. For example, although described in the context of particular system and device configurations, the techniques are applicable to a wide variety of other types of data processing systems, processing devices and distributed virtual infrastructure arrangements. In addition, any simplifying assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the invention. Numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.