Source: https://patents.google.com/patent/US9948721B2/en
Timestamp: 2019-05-20 09:22:28
Document Index: 708928857

Matched Legal Cases: ['Application No. 61', 'art 400', 'art 500', 'art 600', 'art 700', 'art 800']

US9948721B2 - Methods and systems for providing time and date specific software user interfaces - Google Patents
Methods and systems for providing time and date specific software user interfaces Download PDF
US9948721B2
US9948721B2 US14/613,172 US201514613172A US9948721B2 US 9948721 B2 US9948721 B2 US 9948721B2 US 201514613172 A US201514613172 A US 201514613172A US 9948721 B2 US9948721 B2 US 9948721B2
US14/613,172
US20150149917A1 (en
2010-03-26 Priority to US31797310P priority Critical
2010-07-06 Priority to US12/831,196 priority patent/US8977675B2/en
2015-02-03 Application filed by salesforce com Inc filed Critical salesforce com Inc
2015-02-03 Priority to US14/613,172 priority patent/US9948721B2/en
2015-05-28 Publication of US20150149917A1 publication Critical patent/US20150149917A1/en
2018-04-17 Publication of US9948721B2 publication Critical patent/US9948721B2/en
Computer systems, methods and software for responding to remote clients with content selected based on when the request is made. The method may include selecting one or more interface components based on the time of day and/or date of the request, and returning a response including the selected interface components. The method may include adjusting the time for a time zone for the remote client and/or user. Interface components may be fully embedded in the response, or may be references to external components. Interface components may include data relating to a user task associated with the date and/or time of day, formatting information for displaying the task data to the user of the remote client, instructions for user interaction with the task data, etc.
This application is a continuation of U.S. patent application Ser. No. 12/831,196 filed Jul. 6, 2010 entitled METHODS AND SYSTEMS FOR PROVIDING TIME AND DATE SPECIFIC SOFTWARE USER INTERFACES, which claims the benefit of U.S. Provisional Application No. 61/317,973 filed on Mar. 26, 2010 entitled METHOD FOR PROVIDING TIME AND DATE SPECIFIC COMPUTER INTERFACES; both applications are hereby incorporated herein by reference in their entireties.
The present invention generally relates to the computer systems, methods, and software for responding to remote client requests. More specifically, embodiments of the present invention pertain to responding to remote clients with content selected based on when the request is made.
Typical Web systems employ HTTP (Hypertext Transfer Protocol) as a communication protocol used between a Web browser and a Web server (i.e., HTTP server). In HTTP, communication is initiated by the Web browser. Namely, one HTTP communication is comprised of an HTTP request issued by the Web browser and an HTTP response returned by the Web server in response to the HTTP request.
Referring now to FIG. 1, a response 100 from a web server typically includes a response header 101 and a body 102. The header 101 may include cookies 110, such as a session id 111 which the Web browser can return to associate future requests with a single session. The body 102 typically comprises an HTML “page” 120 that includes both data and formatting information for display to a user of the Web browser. Many conventional Web applications divide a display area into interface components (e.g., portlets, sidebars, banners, etc.), where each component is associated with a particular task or type of data and given a portion of the Web browser display area.
FIG. 2 shows an exemplary web page display area 240 with a banner area 241, and sidebar area 242, and a main body area 243. Sidebar area 242 is further divided into areas 245, 246, and 247. These interface components may be incorporated within the body of a response within HTML sections such as <div> tags 141, 142, and 143 of FIG. 1) or may be references to external data (e.g., data to be retrieved by further HTTP requests) with HTML sections such as <iframe> tags 145, 146, and 147. An HTML page may also include interface components such as cascading style sheets (CSS) (e.g., <style> tag 132) and JavaScript code (e.g., <script> tag 131) to further define and/or customize the layout, formatting, behavior, and other attributes of the HTML page.
The user of a Web browser typically communicates with the Web server via a series of HTTP requests and responses. Each response typically provides links or other interface affordances (e.g., forms, JavaScript actions, etc.) to retrieve data and/or to perform tasks. Typically, a web page is built from the same set of interface components every time the user accesses a given Web page or application, unless new features or added or the user manually changes one or more of the interface components. For example, in a portal application the user may have configured a sports section, a financial news section, and a stock price section. When the user visits the portal Web application, the interface components are selected from the sections selected by the user. The same interface components are selected displayed every time the user visits the “home” page of the Web application. Thus, the user interface for a Web application generally remains the same, independent of the time of day, day of the week, day of the year, etc.
It would be beneficial to the user if the Web server were to change the user interface dynamically depending on the time at which the Web server is accessed in order to give the user quicker, easier, or automatic access to items, pages, data, or screens they need, without them having to explicitly select or request them. The embodiments described herein include methods and systems for responding to remote clients in a time and/or date sensitive manner. An embodiment of a method may include steps of receiving a request from a remote client, determining a time of day and/or a date for the request, selecting one or more interface components based on the time of day and/or date, and returning a response to the client including the selected interface components. In some embodiments, the method includes determining a time zone for the remote client and/or user and selecting one or more of the interface components based on the time adjusted for the time zone.
Interface components may be fully embedded in the response, or may be references to external components. The interface components may include, for example, style and/or formatting information (e.g., cascading style sheet [CSS] data), executable code (e.g., scripts, browser add-ons and extensions, Java applets, ActiveX controls, etc.), structured and/or formatted data, etc. Thus, one or more of the selected interface components may include data relating to a user task, where the task is particularly associated with a date and/or time of day. The interface components may further comprise instructions and/or formatting information for displaying the task data to the user of the remote client. Other interface components may include instructions and/or information (e.g., scripts, html forms, hyperlinks, etc.) for user interaction with the task data.
In an exemplary embodiment, the method may include determining a current time period (e.g., the current business day), determining a time of previous access by the remote client and/or the remote user, and selecting one or more of the interface components based on whether said time of previous access is within said current time period (e.g., to display tasks scheduled for the beginning of the business day).
In some embodiments, the method includes determining a time of previous access by the remote client and/or user and selecting one or more of the interface components based on a duration of a period between the time of previous access and the time of day for the request. In other embodiments, the method includes creating and/or accessing session data corresponding to the request and setting a session duration for the session data based on the time of day (e.g., to provide a longer login session during normal business hours and/or on business days).
In another embodiment, the method may include selecting one or more current time periods from a plurality of pre-defined time periods (e.g., “morning,” “lunchtime,” “afternoon”, “during business hours,” “holiday,” etc.) and selecting one or more of the interface components based on the current time period(s).
FIG. 1 is a diagram of an exemplary HTTP response;
FIG. 2 is a diagram of an exemplary Web page layout;
FIG. 3 is a diagram of an exemplary Web application server and client;
FIG. 4 is a flowchart showing an exemplary method for customizing a response for a user's first access during a time period;
FIG. 5 is a flowchart showing an exemplary method for customizing a response based on the time of a user's previous access;
FIG. 6 is a flowchart showing an exemplary method for customizing a response based on the time of login;
FIG. 7 is a flowchart showing an exemplary method for changing products included in a response based on the time of day;
FIG. 8 is a flowchart showing an exemplary method for changing display styles in a response based on the time of day.
The systems, methods, and software of the present invention provide mechanisms for providing the user of a remote client computer with a web application experience by acting upon time-based values in order to customize, stylize, or differentiate information displayed to the user, to help them work more effectively. Embodiments of the invention may, for example, present sets of data and/or tools adapted to the user's likely needs to help them prioritize and perform tasks at an appropriate time.
FIGS. 3-8 generally show exemplary methods including steps of receiving a request from a remote client, determining a time of day and/or a date for the request, selecting one or more interface components based on the time of day and/or date, and returning a response to the client including the selected interface components. It will be recognized that the methods described herein may be implemented as software instructions to be executed on one or more computer processing systems.
FIG. 3 shows an exemplary web server 310 communicating over network 303 with a browser software application 302 running on a client computer system 301. It will be recognized that web server 310 generally includes a plurality of software components, and that any of these components may be running on multiple computer processors, and that each of the exemplary components described herein may be further so subdivided.
Request processor 311 may comprise an HTTP server such as the Apache HTTP server, Microsoft Internet Information Services, etc. While the embodiments herein are generally described in terms of HTTP communication protocols and HTML presentation formats, it will be recognized by those skilled in the art that the concepts are applicable to a wide variety of communication protocols and data formats. Furthermore the client software may include, in addition to web browsers, dashboard applications, sidebars, tickers, etc. In an exemplary implementation, request processor 311 receives a request and parses the request to determine how to respond. Request processor 311 may simply return a data file specified by the request, or may delegate processing to another component (e.g., to application service 314) based on the request. In addition, request processor 311 may communicate with identification server 312 to associate the request with a particular client system and/or user (e.g., based on login credentials provided by the user). Request processor 311 may also communicate with session service 313 to associate the request with user session data (e.g., data stored on the web server in order to maintain a session state between requests).
Application service 314 may comprise a custom web application configured to process one or more types of requests from request processor, or may comprise a conventional web application server or object request broker. In exemplary embodiments, the application service 314 communicates, directly or indirectly, with a component selector 315 configured to receive a time and/or date from time source 316 and to select one or more interface components based on the time of day and/or date.
Component selector 315 may select interface components based on, for example, time of day, day of week, day of month, month within the fiscal quarter, holidays, business days, day or night, typically active time for the user, or off-hours for the user based on their historical norm, number of minutes since the last login, number of minutes since the last view of a given page, screen, or record set, number of minutes since login, number of minutes until the user session will expire, number of minutes since last user session ended, any combination of the above, etc.
Exemplary components that the component selector 315 may select may include landing pages, redirect URLs, or other screens to display after login success or initiation of the application, portlets or summary views to display on a “Home” page, executive dashboard views, dashboard view orders, tab orders, styles, scripts, executable code (e.g., Java Applets, ActiveX controls, Adobe Flash applications), etc. The application service 314 or other components may also adjust other aspects of the response and/or session in response to the time, such as whether previous session data or cookies are reused, session duration, etc.
Referring now to FIG. 4, flowchart 400 shows an exemplary method for customizing a response for a user's first access during a time period. At step 401, a user logs in to an application. For example, the user may enter a username and password, or use other login credentials, on a login page for a support case tracking web application. At step 402, the application determines the current time. At step 403, the application uses the current time to determine the current time period and the start time for that period. For example, a “user day” may be configured to begin at 3 A.M. each day.
At step 405, the application determines whether the user has previously logged or otherwise accessed the application after the start of the current period. If the user has previously logged in during the current period, then the application may return a default application home page including a default set of components at step 410. The browser or other client application then displays the default page at step 411. If, however, the user has not logged in to the system since the start of the current period, then the application may proceed to step 420 to return a set of components customized for a “first of the day” page. For example, in a support case tracking web application the “first of the day” page may include one or more components to show support cases and tasks scheduled for the day, cases that have not been updated in the last 72 hours, cases that have been opened since their last “first of the day” login, etc.
Referring now to FIG. 5, flowchart 500 shows an exemplary method for customizing a response based on the time of a user's previous access. At step 500, a user of a remote client logs out of the web application. At step 502, in processing the log-out request, the web application stores a time of the logout and at step 503 saves an interface state.
At step 510, the user logs in again. At step 511, the application determines the amount of time elapsed since the last login. At step 512, the application determines whether the time elapsed is greater than some threshold (e.g., one hour). If the time elapsed is not greater than the threshold, then the application loads the saved interface state at step 520 and returns a page in the saved state at step 521. For example, the page with saved state may include persisted values for a current page, search history, navigation tree state, etc. Otherwise, at step 530 the application may return a default home page (e.g., with no search history, a fully closed set of folders in the navigation tree, etc.).
Referring now to FIG. 6, flowchart 600 shows an exemplary method for customizing a response based on the time of login. At step 601 a user selects the application site (e.g., from a bookmark/favorites list, from a portal application, etc.) and at step 602 the client browser requests the appropriate page. At step 603 the application determines whether there is any session state associated with the request (e.g., from a session cookie or other parameter included in the request) and at step 604 determines whether the session is valid. If there is no valid session, then at step 610 the application returns a login page. In step 611 the client browser displays the login page. At step 612 the user enters login credentials, and at step 613 the client browser sends a login request to the application. At step 614 the application determines whether the login credentials are valid. If not, the login page is returned again at step 610.
If the login is valid, then the application proceeds to step 620 to determine the current time. At step 621, the application determines the session duration based on the current time. For example, if the current time is within the window of normal business hours Monday-Friday for the company (or user, if per-user values are available), the session may be granted with a duration of eight hours. If the current time is outside of normal business hours, then a different duration may be granted. For example, between 6 am and 8 pm on a normal workday, a four hour session may be granted. Or, a one hour session may be granted. Note that, in this example and all other examples, the duration of a session and the time period to which the duration applies can be defined in a variety of ways. In some implementations, the duration and time period are defined to maximize hardware resources. In other implementations, the duration and time periods are based on business needs, client agreement, or some other factor/combination of factors.
Referring now to FIG. 7, flowchart 700 shows an exemplary method for changing products included in a response based on the time of day. At steps 701 and 702 the user selects the site and the browser sends a request to the application. At step 710, the application determines an internet protocol (IP) address of the client system. At step 711 the application determines a time zone for the user based on the IP address (e.g., using a GeoIP database) and at step 712 determines the user's local time by adjusting for the time zone. At step 713 the application determines the current time period, e.g. “daytime”, for the user of the remote client. At step 720, the application returns a page based on the current time period. For example, if it is “daytime” at step 720 the application may return a page including business use or other “daytime” products on the page. Otherwise, at step 730 the application may return a page including other information for home use or “nighttime” products on the page.
Referring now to FIG. 8, flowchart 800 shows an exemplary method for changing display styles in a response based on the time of day. An exemplary web application may generally be styled with primarily black text on a white background, with blue trim. Throughout the day, the remote client may request application pages at step 801, either in response to user activity or in response to scripts or other application logic executed on the client. The application processes the request at step 802, and at least part of the processing may include steps 803-818 to modify the display of the site in response to the time of day. Thus at step 803 the application determines the current time. In steps 810, 812, 814, and 816 the application may compare the current time to one or more predefined time periods (e.g., deadline approaching, morning, lunchtime, end of day) and adjust style components appropriately at steps 811, 813, 815, 817, and 818.
Thus, as the day progresses the default blue trim may change appearance slightly, becoming lighter during the mornings and through the afternoon, and progressively darker through late afternoon through evening, and very dark blue at night. For a business application or corporate intranet site, for example, the application may unobtrusively give workers an update on the relative time of day. While a digital clock included with most operating systems provides a specific time of day, the coloring could provide timing subtle cues to the user. For example, a schedule component may fade to gray during lunch break for a worker, fade to red if an action hasn't been taken in a given amount of time, fade to black as the dedicated call center hour's end of day approaches, etc.
Thus, the present invention provides methods, software, and computer systems for changing the user interface of a web application dynamically depending on the time at which the Web server is accessed in order to give the user quicker, easier, or automatic access to items, pages, data, or screens they need, without the user having to explicitly select or request these particular components.
1. A computer processing system including one or more processors and a non-transitory computer-readable medium storing computer-executable instructions for controlling the one or more processors to:
receive a first login request from a user at a first time;
register a second time at which the user logs out;
store an interface state for a web page responsive to the user logging out at the second time;
receive a second login request from the user at a third time after the second time;
determine a first amount of time that elapsed between the third time and the first time;
determine whether the first amount time is more than a first threshold amount of time;
provide, responsive to a determination that the first amount of time is more than a first threshold amount of time, the web page according to a default display state; and
provide, responsive to a determination that the first amount of time is less than a first threshold amount of time, the web page according to the interface state.
2. The computer processing system of claim 1, wherein the interface state reflects changes made to the default display state by the user.
3. The computer processing system of claim 1, wherein the first threshold amount of time is one hour.
4. The computer processing system of claim 1, wherein the interface state includes one or more items selected from the group consisting of: persisted values for the web page, search history data associated with the web page, and navigation tree state for a navigation tree in the web page.
5. The computer processing system of claim 1, wherein the non-transitory computer-readable medium stores further computer-executable instructions for controlling the one or more processors to:
determine that the first time is during a first predefined time period during a predefined time interval;
determine whether any other login requests from the user have been received prior to the first time and within the first predefined time period;
provide, responsive to a determination that another login request from the user was received prior to the first time and within the first predetermined time period, a web page with first content; and
provide, responsive to a determination that no other login request from the user was received prior to the first time and within the first predetermined time period, a web page with second content that is at least partially different from the first content.
6. The computer processing system of claim 5, wherein the first predefined time period is one of several predefined time periods during the predefined time interval.
7. The computer processing system of claim 6, wherein the predefined time interval is a day.
8. The computer processing system of claim 7, wherein:
the first content includes content for a default application home page, and
the second content includes at least one piece of content that is not part of the default application home page and that is selected from the group consisting of: support cases and tasks scheduled for the day, support cases that have not been updated in the last 72 hours, and new support cases that have been opened since a previous first login request from the user was received, wherein the previous first login request from the user is the most recent login request from the user that was received a) during another day prior to the predefined time interval and b) prior to any other login requests from the user during a second predefined time period in the other day.
9. The computer processing system of claim 7, wherein the first predefined time period starts at 3:00 AM and ends at a time after noon.
10. The computer processing system of claim 1, wherein the non-transitory computer-readable medium stores further computer-executable instructions for controlling the one or more processors to:
determine a current local time of the user based on the first time;
select one or more products for inclusion in the webpage based on the current local time of the user; and
include the one or more products selected based on the current local time of the user in the webpage.
11. The computer processing system of claim 10, wherein the non-transitory computer-readable medium stores further instructions for controlling the one or more processors to:
determine an internet protocol (IP) address associated with the user;
determine a time zone of the user based on the IP address; and
determine the current local time of the user taking into account the time zone of the user.
12. The computer processing system of claim 10, wherein the non-transitory computer-readable medium stores further instructions for controlling the one or more processors to select business products for inclusion in the webpage when the local time of the user is associated with daytime.
13. The computer processing system of claim 10, wherein the non-transitory computer-readable medium stores further instructions for controlling the one or more processors to select nighttime products for inclusion in the webpage when the local time of the user is associated with nighttime.
14. The computer processing system of claim 1, wherein the default display state includes one or more items selected from the group consisting of: a fully closed set of folders in a navigation tree and a blank search history.
US14/613,172 2010-03-26 2015-02-03 Methods and systems for providing time and date specific software user interfaces Active 2031-08-08 US9948721B2 (en)
US31797310P true 2010-03-26 2010-03-26
US12/831,196 US8977675B2 (en) 2010-03-26 2010-07-06 Methods and systems for providing time and date specific software user interfaces
US14/613,172 US9948721B2 (en) 2010-03-26 2015-02-03 Methods and systems for providing time and date specific software user interfaces
US15/908,656 US20180191833A1 (en) 2010-03-26 2018-02-28 Methods and systems for providing time and date specific software user interfaces
US12/831,196 Continuation US8977675B2 (en) 2010-03-26 2010-07-06 Methods and systems for providing time and date specific software user interfaces
US15/908,656 Continuation US20180191833A1 (en) 2010-03-26 2018-02-28 Methods and systems for providing time and date specific software user interfaces
US20150149917A1 US20150149917A1 (en) 2015-05-28
US9948721B2 true US9948721B2 (en) 2018-04-17
ID=44657571
US12/831,196 Active 2031-04-13 US8977675B2 (en) 2010-03-26 2010-07-06 Methods and systems for providing time and date specific software user interfaces
US14/613,172 Active 2031-08-08 US9948721B2 (en) 2010-03-26 2015-02-03 Methods and systems for providing time and date specific software user interfaces
US15/908,656 Pending US20180191833A1 (en) 2010-03-26 2018-02-28 Methods and systems for providing time and date specific software user interfaces
US (3) US8977675B2 (en)
US20110066977A1 (en) 2009-09-16 2011-03-17 International Business Machines Corporation Analyzing an interaction history to generate a customized webpage
2010-07-06 US US12/831,196 patent/US8977675B2/en active Active
2015-02-03 US US14/613,172 patent/US9948721B2/en active Active
2018-02-28 US US15/908,656 patent/US20180191833A1/en active Pending
"Customer Relationship Management" from Wikipedia, the free encyclopedia, [online]; [published on Oct. 16, 2008]; [retrieved on Feb. 26, 2010]; retrieved from http://en.wikipedia.org/wiki.Customer_Relationship_Management, 1 page.
"Flat file database"-Wikipedia, the free encyclopedia, [online]; [published on Apr. 22, 2008]; [retrieved on Feb. 26, 2010]; retrieved from http://en.wikipedia.org/wiki/Flat_file_database, 4 pp.
"Push technology"-Wikipedia, the free encyclopedia, [online]; [published on Oct. 17, 2008]; [retrieved on Feb. 26, 2010]; retrieved from http://en.wikipedia.org/wiki/Push_technology, 4 pp.
"Relational database"-Wikipedia, the free encyclopedia, [online]; [published on Apr. 25, 2008]; [retrieved on Feb. 26, 2010]; retrieved from http://en.wikipedia.org/wiki/Relational_database, 6 pp.
"Flat file database"—Wikipedia, the free encyclopedia, [online]; [published on Apr. 22, 2008]; [retrieved on Feb. 26, 2010]; retrieved from http://en.wikipedia.org/wiki/Flat_file_database, 4 pp.
"Push technology"—Wikipedia, the free encyclopedia, [online]; [published on Oct. 17, 2008]; [retrieved on Feb. 26, 2010]; retrieved from http://en.wikipedia.org/wiki/Push_technology, 4 pp.
"Relational database"—Wikipedia, the free encyclopedia, [online]; [published on Apr. 25, 2008]; [retrieved on Feb. 26, 2010]; retrieved from http://en.wikipedia.org/wiki/Relational_database, 6 pp.
Lee et al. "Composition of executable business process models by combining business rules and process flows", Expert Systems With Application, Oxford, GB, vol. 33, No. 1, Dec. 22, 2006 pp. 221-229.
Mietzer et al. (2009) "Combining Different Multi-Tenancy Patterns in Service-Oriented Applications", IEEE International Enterprise Distributed Object Computing Conference, NJ, USA, pp. 131-140.
U.S. Final Office Action dated Jan. 15, 2013 issued in U.S. Appl. No. 12/831,196.
U.S. Notice of Allowance dated Nov. 3, 2014 issued in U.S. Appl. No. 12/831,196.
U.S. Office Action dated Aug. 24, 2012 issued in U.S. Appl. No. 12/831,196.
Wang et al. (2008) "A Study and Performance Evaluation of the Multi-Tenant Data Tier Design Patterns for Service Oriented Computing", IEEE International Conference On E-Business Engineering, NJ, USA, pp. 94-101.
Wang et al. (2009) "Integrated Constraint Violation Handling for Dynamic Services Composition", IEE International Conference on Services Computing, NJ, USA, pp. 168-175.
Wermelinger et al. (2003) "Using coordination contracts for flexible adaptation to changing business rules", Proceedings of the Sixth International Workshop on Software Evolution, NJ, USA, pp. 115-120.
US20150149917A1 (en) 2015-05-28
US20110238736A1 (en) 2011-09-29
US8977675B2 (en) 2015-03-10
US20180191833A1 (en) 2018-07-05
US7739594B2 (en) 2010-06-15 Encoding and displaying default landing page content