DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in responsive to communication(s): original application filed on 06/15/2023. Claims 1-20 are pending. Claims 1, 10, and 16 are independent.
Specification
The disclosure is objected to because of the following informalities:
in ¶ [0064], "FIG. 4 depicts a block diagram 200 for proactive content service delivery …" appears to be "FIG. 4 depicts a block diagram 400 for proactive content service delivery …".
Appropriate correction is required.
Claim Objections
Claims 2, 5-8, 10, 14-15, 17, and 19-20 are objected to because of the following informalities:
in Claim 2, lines 9-10; and Claim 17, lines 9-10, "… determining, for each delivery interval dimension, a predetermined delivery interval …" appears to be "… determining, for said each delivery interval dimension, a predetermined delivery interval …";
in Claim 5, lines 1-2; and Claim 19, lines 1-2, "… wherein selecting one of a full update and a partial update comprises …" appears to be "… wherein selecting one of the full update and the partial update comprises …";
in Claim 6, lines 1-2; Claim 7, lines 1-2; Claim 8, lines 1-2; and Claim 20, lines 1-2, "… wherein training the classification model to predict whether content will result in an impression comprises …" appears to be "… wherein training the classification model to predict whether the content will result in the impression comprises …";
in Claim 6, lines 5-7; and Claim 20, lines 5-7, "… wherein a positive sample denotes a content update known to have resulted in an impression and a negative sample denotes a content update that did not result in an impression" appears to be "… wherein the positive sample denotes a first content update known to have resulted in the impression and the negative sample denotes a second content update that did not result in the impression";
in Claim 7, lines 2-3, "… weighting each content update of the plurality of unique prior content updates …" appears to be "… weighting said each content update of the plurality of unique prior content updates …";
in Claim 8, lines 3-6, "… defining each content update of the plurality of unique prior content updates according to … inputting … the plurality of input features for each content update as …" appears to be "… defining said each content update of the plurality of unique prior content updates according to … inputting … the plurality of input features for said each content update as …";
in Claim 10, lines 1-2, "A system having a memory, computer readable instructions, and one or more processors for executing the computer readable instructions …" appears to be "A system comprising: a memory having/storing computer readable instructions, and one or more processors for executing the computer readable instructions …" (see Claim 16, and 101 rejections to Claims 10-15);
in Claim 14, lines 2-3, "… receives an indicator identifying whether a full update or a partial update is included in the content update" appears to be "… receives an indicator identifying whether the full update or the partial update is included in the content update";
in Claim 15, lines 2-3, "… does not receive any indicators identifying whether a full update or a partial update is included in the content update" appears to be "… does not receive any indicators identifying whether the full update or the partial update is included in the content update".
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 16 recite the limitation "... defining a plurality of delivery interval dimensions, each delivery interval dimension comprising a unique combination of one time cohort of two or more time cohorts and one user cohort of two or more user cohorts; determining a time cohort and a user cohort for the user; and selecting a predetermined delivery interval of the delivery interval dimension matching the time cohort and the user cohort of the user as the delivery interval ..." in lines 5-11 and 7-13 respectively, which rendering these claims indefinite because (a) it is unclear whether ".
Claims 2-9 and 17-20 are rejected for fully incorporating the deficiency of their respective base claims.
Claims 2 and 17 recite the limitation "… estimates a number of daily active users as a function of test intervals applied to each of the plurality of delivery interval dimensions … estimates a number of requests per second as a function of the test intervals applied to each of the plurality of delivery interval dimensions …" in lines 3-8, which rendering these claims indefinite because it is unclear whether these two instances of ".
Claims 2 and 17 recite the limitation "… determining … a predetermined delivery interval that maximizes the first linear regression function …" in lines 9-10, which rendering these claims indefinite because ".
Claims 3-4 are rejected for fully incorporating the deficiency of their respective base claims.
Claim 10 recites the limitation "… receiving … a delivery interval for content updates; requesting to participate in content updates from the proactive content delivery system …" in lines 5-8, which rendering the claim indefinite because it is unclear whether these two instances of ".
Claims 11-15 are rejected for fully incorporating the deficiency of their respective base claims.
Claim 18 recites the limitation "the threshold maximum allowable change" in lines 1-2. There is insufficient antecedent basis for these limitations in the claim. Since "the threshold maximum allowable change" are recited in Claim 17 and not in Claim 16, for examination purpose, consider that Claim 18 is depending on Claim 17 instead of Claim 16.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 10-15 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because "A system having ... computer readable instructions ..." is recited in these claims, and "computer readable instructions" (i.e., software per se.) of the claimed system does/do not fall within at least one of the four categories of patent eligible subject matter. See Claim Objections to Claim 10 for resolving 101 issue.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 10-13 and 15 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mandyam et al. (US 2009/0271778A1, pub. date: 10/29/2009), hereinafter Mandyam.
Independent Claim 10
Mandyam discloses a system (Mandyam, ¶¶ [0082]-[0083] and [0095] with 100 in FIG. 1: mobile widget system 100 includes a wireless communication device 700; a network device 120 is operable to communicate with any other network-side or infrastructure elements of system 100 and/or with wireless communication device 700) having a memory (Mandyam, ¶ [0097] with 124 in FIG. 4: network device 120 includes a memory 124; ¶ [0121] with 706 in FIG. 10: the wireless device 700 includes a memory 706), computer readable instructions (Mandyam, ¶ [0097] with FIG. 4: a memory 124 for storing local versions of software programs or applications, including scripts, codes, algorithms, heuristics, neural networks, rules, fuzzy logic, and executable instructions; ¶ [0121] with FIG. 10: memory 706 is operable for storing applications), and one or more processors (Mandyam, ¶ [0096] with 122 in FIG. 4: network device 120 includes a processor component 122 which can include a single processor, or multiple set of processors or multi-core processors; ¶ [0121] with 708 in FIG. 10: the wireless device 700 includes a processor 708 which can include a single processor, or multiple set of processors or multi-core processors) for executing the computer readable instructions (Mandyam, ¶ [0097] with FIG. 4: software programs or applications, including scripts, codes, algorithms, heuristics, neural networks, rules, fuzzy logic, and executable instructions, being executed by processor component 122; ¶ [0121] with FIG. 10: applications being executed by processor 708), the computer readable instructions controlling the one or more processors to perform operations (Mandyam, ¶ [0096] with FIG. 4: processor component 122 is operable to execute a software program or application from memory in order to receive and process inputs and generate outputs corresponding to the functionality of the respective infrastructure element as described herein; ¶ [0121] with FIG. 10: processor 708 is operable for carrying out processing functions associated with one or more of components and functions described herein) comprising:
receiving, from a proactive content delivery system, a delivery interval for content updates (Mandyam, ¶ [0062]: mobile widget or widget: a user interface (UI) element with which a device end user interacts; ¶¶ [0076] and [0070]: provides update schedules for widget content updates and a timetable for periodic retrieval of digital locker contents, where the digital locker may be a WMS (Widget Management System) component that includes mobile widget information and configuration for end users; ¶ [0086] with FIG.1: a widget configuration may include settings relating to an appearance of widget 102, as well as an operation of widget 102, including one or more content update settings; ¶ [0104] with FIGS. 1 and 5: a recommended update schedule 222 that defines a recommendation or suggestion of the developer/provider 108 of when the content represented by the widget should be updated for example, the temporal aspects of widgets may vary, as so Some widgets such as a stock watcher widget may preferably have frequent updates during market hours and much less frequent updates after market hours, versus a weather widget which may preferably be updated only a few times per day; ¶ [0108]: provide automated update schedules for individual or groups of mobile widgets 102 or end users 104; ¶ [0125]-[0127] with FIG. 11: widget manager 710 includes a content update scheduler 712 that includes logic that is operable to update the schedule for content delivery based on one or more preconfigured content delivery attributes; content delivery attributes may include, but are not limited to, widget usage, time of day/week/month/year, user/device location or the like; e.g., widget usage may dictate that more frequently accessed widgets (e.g. widgets that are clicked-on or the like) are provided more frequent content updates while less accessed widgets are provided less frequent content updates; in another example, the logic may determine what time of day a user is most likely to access a widget and, in turn, schedule more frequent content updates during that time; additionally, the logic may associate location with content updates, such that when the user/device is the vicinity of a specified location, more or less frequent updates occur; e.g., if a user is within the vicinity of a sports stadium, the logic may be configured to provide more frequent updates for a sports information-related widget; while the content update scheduler 712 provides logic to determine update schedules based on one or more content delivery attributes, the schedule can also be based on network preferences/factors for content delivery and/or user configuration of content schedules; the content update schedule 712 may additionally include logic that provides for prioritizing, weighting, or otherwise factoring content delivery based on the content delivery attributes, the network preferences/factors, and/or the user configuration; the user may override the content update scheduler 712 and either provide for their own content update schedule via an option in the widget management module 722 of the widget wizard 718; additionally the widget may be configured through the widget management module 722 of the widget wizard 718 with a button or other user interface that allows for the user to instantaneously request a content update... );
requesting to participate in content updates from the proactive content delivery system according to the delivery interval (Mandyam, ¶ [0088]: widget management portal 800 that allows end user 104 to access WMS 300 to inquire about available mobile widgets 102 and widget catalogs 302; widget management portal 800 allows end user 104 to configure the functionality and appearance of mobile widget 102 on wireless communication device 700; ¶ [0108]: a widget manager component 242 that allows operator/carrier 110 to change one or more parameters or characteristics of mobile widget 102; e.g., widget manager component 242 may allow operator/carrier 110 to: activate or deactivate a respective mobile widget 102 for operation on system 100; set or change a widget identifier, such as identifier 230; set or change widget application/code, such as application/code 232; set or change a widget update schedule, such as update schedule 234; and/or set or change pricing information, such a pricing 236; widget manager component 242 may further include an update scheduling manager 244 to specifically allow interaction with, and setting of updates schedules for one or a group of mobile widgets 102;e.g., update scheduling manager 244 may include logic, algorithms, heuristics, fuzzy logic, neural networks, etc., operable to provide automated update schedules for individual or groups of mobile widgets 102 or end users 104, e.g., that take into account and/or balance end user considerations, mobile widget characteristics such as temporal aspects of content, and operator/carrier considerations; ¶¶ [0110]-[0114] with FIG. 8; WMS 300 provides an end user facing interface that allows end user 104, via WMC 804 on wireless communication device 700 and/or via widget management portal 800, to view, select, purchase/download, and configure mobile widgets 102; subscription manager component 312 may be operable to control one or a plurality of subscriber records 314 in a database such as digital locker 304; each subscriber record 314 includes information on each end user and on each mobile widget 102 corresponding to each end user to enable the management and control of mobile widgets for subscribers; subscription information 318 including a subscription identifier, a subscription description, a subscription key, a license, a validity time period, a service level, and any other information relevant to enabling operation of a mobile widget on a wireless device—such subscription information 318 may authorize end user 104 and/or wireless communication device 700 to receive or operate an individual or a class of mobile widgets, and may further authorize or identify a ser vice level that may allow one of a number of levels of service corresponding to a mobile widget, wherein Such service levels may regulate a number or Volume of content updates, message exchanges, etc. performed by the respective mobile widget; ¶ [0132]: the widget configuration module 752 may include content update schedule configuration 754 operable to allow the user to define the frequency by which each widget is provided content updates and content rendering configuration 756 operable to provide the user with the ability to define the manner in which widgets are rendered/presented on the user interface, such as the position on the display, the size of the widget or the like; ¶¶ [0144]-[0145] with FIG. 15: the advertising serving platform 1000 is in communication with content access server 900, such that advertisements 1010 are communicated from the advertising serving platform 1000 to the wireless device 700 through the content access server 900.similar to a content update request as described above, wireless device may issue an advertisement request 1040 operable to request delivery of an advertisement for presentation of an advertisement on the wireless device; ¶¶ [0153]-[0158] and [0064] with FIGS. 18-23: a widget management portal (WMP) 1801 interacts with WMS 300 to select and configure the mobile widget; the WMS 300 interacts with CAS 900 to obtain the content for the mobile widget; the WMS 300 forwards the mobile widget and/or the content update for the mobile widget to the widget management client (WMC) 704 via the message router; WMC 704 interacts with WMS 300 to select and configure the mobile widget; the WMS300 interacts with CAS 900 to obtain the content for the mobile widget; further, the WMC 704 may request a content update for the mobile widget from the CAS 900, which responds with the updated content, which the WMC 704 confirms receiving; based on the occurrence of a content update event, WMC 704 sends a content update request via the message router 500 to the CAS900; the CAS900 bundles the corresponding content update and transmit it to the WMC 704 via the message router 500; rather than being event driven, the content update request may be user initiated; WMC 704 may package metering/tracking data along with the content update request; a high level call flow relates toa reporting of widget metering/tracking data and a corresponding adjustment of a widget update schedule based on the reported metering/tracking data; the analytics and reporting components 1200 and 1300 then determine usage data based on the reported metering/tracking data, which is provided as an input to the WMS 300 and/or the UWM 200 for use in determining content update schedules; based on the usage data, a new update schedule is determined for one or more users, and/or for one or more mobile widgets. The new update schedule is stored at the WMS 300 and/or the UWM 200, and is further communicated to the WMC 704 via the message router 500; thus, a new update schedule is effected based on an analysis of the reported metering/tracking data provided by WMC 704.);
receiving, from the proactive content delivery system, a content update comprising one of a full update and a partial update at a frequency defined by the delivery interval (Mandyam, ¶ [0066]: widget operation modes: (i) compressed mode: an individual widget frame for display on a widget wall; and (ii) expanded mode: an individual widget frame for display when the mobile widget is selected, where the widget frame in the expanded mode may be sized larger than the respective widget frame in the compressed mode; ¶¶ [0133]-[0135] with FIG. 11: the listing of widgets in the catalog may be periodically updated, based on a set schedule or a user input, to insure the currency of the widgets available to the user; the update controller 724 is operable to control upstream and downstream data delivery to and from WMC 704; update controller 724 may be operable to receive widget content updates, updates to the widget catalog 722, configuration settings for content update schedules, content reporting requests or the like; ¶¶ [0143] with FIG.14: the metadata 1012 may include the TTL (Time to Live) 1022 for the Advertisement, which defines the expiration date for the advertisement on the wireless device, and time/frequency of display metrics 1024, which define specific times and/or the frequency by which the advertisement should be displayed on the wireless device; the metadata 1102 may include contextual display metrics 1026, which define other context parameters related to the display of the advertisement and wireless device metric collection instructions 1028, which define the metrics that are to be collected at the wireless device, and subsequently communicated to the network, in relation to the dis play of the advertisements, such as time/frequency of display, frequency of user interaction with the advertisements, depth of click-throughs and the like; ¶¶ [0146]-[0148] with FIG. 15: advertising campaign criteria may dictate that certain advertisements are pushed to wireless devices having expiration dates and frequency of display rates related to the advertising campaign; provide for the advertisers 1004 to bid on widget advertising based one or more advertising criteria, such as a position/placement of the advertisement on the widget wall, the frequency of presentation, the time of presentation, the demographics of the target audience and the like; ¶¶ [0159]-[0163]: efficient content delivery may become even more desirable when several different transport mechanisms (e.g. SMS, HTTP (web) connection, IP socket, etc.) are utilized for a service; compact protocol may be utilized to support widget content delivery; a mobile widget service can send a simple widget identifier when a content update is desired; data compression may be utilized for transport optimization; delta compression schemes can be used to further to further improve efficiency in transporting content for updates, particularly if the updates are provided multiple times per day; if we assume, for instance, that only one news item had changed from a previous update, then resending the whole file may be avoided and instead just enough metadata to update the previous file can be sent; as such, in one aspect, only a delta content update is sent, wherein the delta content update represents the difference between the prior content update and the current content update; a benefit in this case is to save on decompression computation at the wireless communication device; in another aspect, the data compression scheme may be applied to the delta content update to further reduce its size; ¶¶ [0164]-[0179] with FIGS. 1 and 24-26 and TABLE 1: the transport of mobile widget content may be further optimized by taking into account widget depth, or widget level or layer content interaction; widget depth refers to the number of clicks into a widget from the widget wall that is possible before the user's experience within the widget is terminated; CAS 900 may be operable to receive user navigation pattern historical data 901 that tracks one or more widget depths 903 corresponding to user inter action with one or more mobile widgets 102; CAS 900 may be operable to receive updated content 944 from content provider 902, wherein updated content 944 includes one or more content portions 907 corresponding to one or more widget depths 903 of a respective mobile widget 102; content update package bundler 910 of CAS 900 includes an analyzer module 911 operable to access user navigation pattern historical data 901 and determine one or more depth ranges 913, 915 corresponding to a distribution of recorded user interactions with a respective mobile widget 102; analyzer module 911 may include one or any combination of logic, fuzzy logic, heuristics, algorithms, neural networks, etc., which may be configurable by operator/carrier 110 (FIG. 1) or another interested party to determine how frequently end user 104 (FIG. 1) interacts with various widget depths and separating such interactions into the one or more depth ranges 913, 915 in a manner to efficiently utilize wireless interface 106; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of analyzer 911 to initiate sending a content update message 945 to wireless device 700, where content update message 945 includes a first portion 907 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; e.g., referring to Table 1, if a user is observed interacting with a widget only to a depth of 2, then content update message 945 could be provided with a first portion of updated content 944 corresponding to the depth of 2, e.g. the update message would include the list of articles and individual articles with byline, but would not include the supporting WAP/HTML/XHTML article; correspondingly, subsequent content update messages may include a second portion of updated content 944 corresponding to a second informational hierarchical depth range based on the user navigation pattern historical data 901, e.g. continuing with the example of Table 1, the subsequent update may include only the supporting WAP/HTML/XHTML article, thereby supplementing the previously-sent content update message 945; moreover, content update package bundler 910 may include a compression module 919 operable to apply compression scheme 921 to updated content 944; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of compressor 919 to initiate sending a content update message 947 to wireless device 700, where content update message 947 includes a first compressed portion 923 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; updating content for a mobile widget includes obtaining updated content corresponding to a mobile widget having a plurality of widget depths at 612, wherein the updated content comprises a first size; obtaining user navigation pattern historical data corresponding to the mobile widget, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 614; obtaining a first widget depth range for inclusion in a first content update message, wherein the first widget depth range is based on the user navigation pattern historical data at 616; at 618, reducing a size of a first portion of the updated content corresponding to the first widget depth range according to a compression scheme, thereby defining a first compressed portion of the updated content having a second size less than the first size; wirelessly transporting the first (optionally, compressed) portion of the updated content in the first content update message to a wireless communication device corresponding to the mobile widget (Block 620); in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request; storing a mobile widget on a wireless communication device, where the mobile widget comprises a plurality of widget depths at 632; tracking user navigation patterns corresponding to the mobile widget to define user navigation pattern historical data, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 634; forwarding the user navigation pattern historical data to a network device associated with a content source at 636; wirelessly receiving a first (optionally, compressed) portion of updated content in a first content update message from the content source at 638; in this case, in one aspect, the first portion of updated content corresponds to a first widget depth range of the mobile widget based on the user navigation pattern historical data; in another aspect, the first portion of the updated content is compressed according to a compression scheme and thus comprises a second size less than a first size of a corresponding first decompressed portion of the updated content; e.g., in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request);
locally caching the content update; and rendering a preview frame from the cached content update (Mandyam, ¶¶ [0062]-[0063]: a mobile widget or widget is a relatively small, specialized graphical user interface (GUI) application, which may include a combination of a graphical symbol and program code or a software module executable to provide visual information or easy access to a function, such as a clock, a calendar, a news aggregator, weather information, etc.; widget frame: a static user interface display area of a mobile widget; ¶ [0072]: content access server (CAS): an infrastructure element operable to handle routing of metering information related to mobile widget activity or end user interactivity with mobile widgets from one or more wireless communication devices; further operable to manage providing content updates to mobile widgets, and to retrieve/cache corresponding content updates from one or more content providers; ¶ [0084] with FIG. 1: mobile widget 102 may present any content generated by a content provider 902, including text, graphics, audio, video and multimedia content, etc.; further, content presentable by mobile widget 102 may include an advertisement, such as from an advertisement serving platform 1000, where the advertisement may be mixed with other content or may be the sole content; ¶ [0086]: a widget recommender 306 to provide end user 104 with advice, suggestions, or recommendations of mobile widgets 102 that may be of benefit or of interest to end user 104; ¶ [0130] with FIG. 11: widget manager 710 additionally includes widget-specific renderer 716 that includes logic operable for presenting the widget 102 on the wireless device 700 based on one or more rendering attributes; rendering attributes widget usage, time of day/week/month/year, user/device location or the like; e.g. widget usage may dictate that more frequently accessed widgets (e.g., widgets that are clicked-on or the like) are provided on the initial wall of the user interface or in a prominent position on the user interface).
Claim 11
Mandyam discloses all the elements as stated in Claim 10 and further discloses receive, from a user, an impression of the preview frame (Mandyam, ¶ [0084]: tracking feedback relating to the usage of advertisements on wireless communication devices 700; ¶¶ [0128]-[0129] with FIG. 12: widget manager 710 also includes widget usage reporter 714 that includes logic operable for collecting and reporting widget usage information; the reporter 714 may include usage data collector 740 operable to collect widget usage data 742; the widget usage data may include widget access frequency, the depth of the access (i.e., how many click-throughs the widget undergoes during an access), the time of day/week that the widget is accessed and the like; the WMS may implement the usage data 742 to determine content update schedules for the widget, to prioritize widgets in the user's personal widget catalog or the like; ¶ [0134]: in those aspects that provide for advertising widgets, the widget usage reporter 714 may be configured to provide specific collection and reporting of usage data related to the interaction that a user may experience with an advertisement, such as time viewed or the accessed depth of the advertisement; ¶¶ [0164]-[0167] with FIG. 24: the transport of mobile widget content may be further optimized by taking into account widget depth, or widget level or layer content interaction; in one aspect, widget depth refers to the number of clicks into a widget from the widget wall that is possible before the user's experience within the widget is terminated; different widget depths for a typical news site RSS feed widgets are shown in Table 1; receive user navigation pattern historical data 901 that tracks one or more widget depths 903 corresponding to user interaction with one or more mobile widgets 102; an analyzer module 911 operable to access user navigation pattern historical data 901 and determine one or more depth ranges 913, 915 corresponding to a distribution of recorded user interactions with a respective mobile widget 102).
Claim 12
Mandyam discloses all the elements as stated in Claim 10 and further discloses when the content update comprises the full update, render a flyout frame from the cached content update (Mandyam, ¶ [0066] with FIG. 3: widget operation modes: expanded mode: an individual widget frame for display when the mobile widget is selected, where the widget frame in the expanded mode may be sized larger than the respective widget frame in the compressed mode; ¶ [0128]: the widget usage data may include the depth of the access (i.e., how many click-throughs the widget undergoes during an access); ¶¶ [0164]-[0170] with TABLE 1: different widget depths for a typical news site RSS feed widgets are shown in Table 1; for the 1st click, list of articles will be rendered within the widget experience; for the 3rd click, where a WAP article is usually required, to be rendered within the widget experience; if a user is observed interacting with a widget only to a depth of 2, then content update message 945 could be provided with a first portion of updated content 944 corresponding to the depth of 2, e.g. the update message would include the list of articles and individual articles with byline, but would not include the supporting WAP/HTML/XHTML article).
Claim 13
Mandyam discloses all the elements as stated in Claim 10 and further discloses when the content update comprises the partial update: request an out-of-schedule content update comprising the full update from the proactive content delivery system; receive, from the proactive content delivery system, the full update; locally cache the full update; and render a flyout frame from the cached full update (Mandyam, ¶¶ [0062]-[0063]: a mobile widget or widget is a relatively small, specialized graphical user interface (GUI) application, which may include a combination of a graphical symbol and program code or a software module executable to provide visual information or easy access to a function, such as a clock, a calendar, a news aggregator, weather information, etc.; widget frame: a static user interface display area of a mobile widget; ¶ [0066]: widget operation modes: (i) compressed mode: an individual widget frame for display on a widget wall; and (ii) expanded mode: an individual widget frame for display when the mobile widget is selected, where the widget frame in the expanded mode may be sized larger than the respective widget frame in the compressed mode; ¶ [0072]: content access server (CAS): an infrastructure element operable to handle routing of metering information related to mobile widget activity or end user interactivity with mobile widgets from one or more wireless communication devices; further operable to manage providing content updates to mobile widgets, and to retrieve/cache corresponding content updates from one or more content providers; ¶ [0086]: a widget recommender 306 to provide end user 104 with advice, suggestions, or recommendations of mobile widgets 102 that may be of benefit or of interest to end user 104; ¶ [0130] with FIG. 11: widget manager 710 additionally includes widget-specific renderer 716 that includes logic operable for presenting the widget 102 on the wireless device 700 based on one or more rendering attributes; rendering attributes widget usage, time of day/week/month/year, user/device location or the like; e.g. widget usage may dictate that more frequently accessed widgets (e.g., widgets that are clicked-on or the like) are provided on the initial wall of the user interface or in a prominent position on the user interface; ¶¶ [0133]-[0135] with FIG. 11: the listing of widgets in the catalog may be periodically updated, based on a set schedule or a user input, to insure the currency of the widgets available to the user; the update controller 724 is operable to control upstream and downstream data delivery to and from WMC 704; update controller 724 may be operable to receive widget content updates, updates to the widget catalog 722, configuration settings for content update schedules, content reporting requests or the like; ¶¶ [0143] with FIG.14: the metadata 1012 may include the TTL (Time to Live) 1022 for the Advertisement, which defines the expiration date for the advertisement on the wireless device, and time/frequency of display metrics 1024, which define specific times and/or the frequency by which the advertisement should be displayed on the wireless device; the metadata 1102 may include contextual display metrics 1026, which define other context parameters related to the display of the advertisement and wireless device metric collection instructions 1028, which define the metrics that are to be collected at the wireless device, and subsequently communicated to the network, in relation to the dis play of the advertisements, such as time/frequency of display, frequency of user interaction with the advertisements, depth of click-throughs and the like; ¶¶ [0146]-[0148] with FIG. 15: advertising campaign criteria may dictate that certain advertisements are pushed to wireless devices having expiration dates and frequency of display rates related to the advertising campaign; provide for the advertisers 1004 to bid on widget advertising based one or more advertising criteria, such as a position/placement of the advertisement on the widget wall, the frequency of presentation, the time of presentation, the demographics of the target audience and the like; ¶¶ [0159]-[0163]: efficient content delivery may become even more desirable when several different transport mechanisms (e.g. SMS, HTTP (web) connection, IP socket, etc.) are utilized for a service; compact protocol may be utilized to support widget content delivery; a mobile widget service can send a simple widget identifier when a content update is desired; data compression may be utilized for transport optimization; delta compression schemes can be used to further to further improve efficiency in transporting content for updates, particularly if the updates are provided multiple times per day; if we assume, for instance, that only one news item had changed from a previous update, then resending the whole file may be avoided and instead just enough metadata to update the previous file can be sent; as such, in one aspect, only a delta content update is sent, wherein the delta content update represents the difference between the prior content update and the current content update; a benefit in this case is to save on decompression computation at the wireless communication device; in another aspect, the data compression scheme may be applied to the delta content update to further reduce its size; ¶¶ [0164]-[0179] with FIGS. 1 and 24-26 and TABLE 1: the transport of mobile widget content may be further optimized by taking into account widget depth, or widget level or layer content interaction; widget depth refers to the number of clicks into a widget from the widget wall that is possible before the user's experience within the widget is terminated; CAS 900 may be operable to receive user navigation pattern historical data 901 that tracks one or more widget depths 903 corresponding to user inter action with one or more mobile widgets 102; CAS 900 may be operable to receive updated content 944 from content provider 902, wherein updated content 944 includes one or more content portions 907 corresponding to one or more widget depths 903 of a respective mobile widget 102; content update package bundler 910 of CAS 900 includes an analyzer module 911 operable to access user navigation pattern historical data 901 and determine one or more depth ranges 913, 915 corresponding to a distribution of recorded user interactions with a respective mobile widget 102; analyzer module 911 may include one or any combination of logic, fuzzy logic, heuristics, algorithms, neural networks, etc., which may be configurable by operator/carrier 110 (FIG. 1) or another interested party to determine how frequently end user 104 (FIG. 1) interacts with various widget depths and separating such interactions into the one or more depth ranges 913, 915 in a manner to efficiently utilize wireless interface 106; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of analyzer 911 to initiate sending a content update message 945 to wireless device 700, where content update message 945 includes a first portion 907 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; e.g., referring to Table 1, if a user is observed interacting with a widget only to a depth of 2, then content update message 945 could be provided with a first portion of updated content 944 corresponding to the depth of 2, e.g. the update message would include the list of articles and individual articles with byline, but would not include the supporting WAP/HTML/XHTML article; correspondingly, subsequent content update messages may include a second portion of updated content 944 corresponding to a second informational hierarchical depth range based on the user navigation pattern historical data 901, e.g. continuing with the example of Table 1, the subsequent update may include only the supporting WAP/HTML/XHTML article, thereby supplementing the previously-sent content update message 945; moreover, content update package bundler 910 may include a compression module 919 operable to apply compression scheme 921 to updated content 944; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of compressor 919 to initiate sending a content update message 947 to wireless device 700, where content update message 947 includes a first compressed portion 923 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; updating content for a mobile widget includes obtaining updated content corresponding to a mobile widget having a plurality of widget depths at 612, wherein the updated content comprises a first size; obtaining user navigation pattern historical data corresponding to the mobile widget, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 614; obtaining a first widget depth range for inclusion in a first content update message, wherein the first widget depth range is based on the user navigation pattern historical data at 616; at 618, reducing a size of a first portion of the updated content corresponding to the first widget depth range according to a compression scheme, thereby defining a first compressed portion of the updated content having a second size less than the first size; wirelessly transporting the first (optionally, compressed) portion of the updated content in the first content update message to a wireless communication device corresponding to the mobile widget (Block 620); in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request; storing a mobile widget on a wireless communication device, where the mobile widget comprises a plurality of widget depths at 632; tracking user navigation patterns corresponding to the mobile widget to define user navigation pattern historical data, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 634; forwarding the user navigation pattern historical data to a network device associated with a content source at 636; wirelessly receiving a first (optionally, compressed) portion of updated content in a first content update message from the content source at 638; in this case, in one aspect, the first portion of updated content corresponds to a first widget depth range of the mobile widget based on the user navigation pattern historical data; in another aspect, the first portion of the updated content is compressed according to a compression scheme and thus comprises a second size less than a first size of a corresponding first decompressed portion of the updated content; e.g., in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request).
Claim 15
Mandyam discloses all the elements as stated in Claim 10 and further discloses wherein a native application receiving the content update does not receive any indicators identifying whether a full update or a partial update is included in the content update (Mandyam, ¶ [0066]: widget operation modes: (i) compressed mode: an individual widget frame for display on a widget wall; and (ii) expanded mode: an individual widget frame for display when the mobile widget is selected, where the widget frame in the expanded mode may be sized larger than the respective widget frame in the compressed mode; ¶¶ [0159]-[0163]: efficient content delivery may become even more desirable when several different transport mechanisms (e.g. SMS, HTTP (web) connection, IP socket, etc.) are utilized for a service; compact protocol may be utilized to support widget content delivery; a mobile widget service can send a simple widget identifier when a content update is desired; data compression may be utilized for transport optimization; delta compression schemes can be used to further to further improve efficiency in transporting content for updates, particularly if the updates are provided multiple times per day; if we assume, for instance, that only one news item had changed from a previous update, then resending the whole file may be avoided and instead just enough metadata to update the previous file can be sent; as such, in one aspect, only a delta content update is sent, wherein the delta content update represents the difference between the prior content update and the current content update; a benefit in this case is to save on decompression computation at the wireless communication device; in another aspect, the data compression scheme may be applied to the delta content update to further reduce its size; ¶¶ [0164]-[0179] with FIGS. 1 and 24-26 and TABLE 1: the transport of mobile widget content may be further optimized by taking into account widget depth, or widget level or layer content interaction; widget depth refers to the number of clicks into a widget from the widget wall that is possible before the user's experience within the widget is terminated; CAS 900 may be operable to receive user navigation pattern historical data 901 that tracks one or more widget depths 903 corresponding to user inter action with one or more mobile widgets 102; CAS 900 may be operable to receive updated content 944 from content provider 902, wherein updated content 944 includes one or more content portions 907 corresponding to one or more widget depths 903 of a respective mobile widget 102; content update package bundler 910 of CAS 900 includes an analyzer module 911 operable to access user navigation pattern historical data 901 and determine one or more depth ranges 913, 915 corresponding to a distribution of recorded user interactions with a respective mobile widget 102; analyzer module 911 may include one or any combination of logic, fuzzy logic, heuristics, algorithms, neural networks, etc., which may be configurable by operator/carrier 110 (FIG. 1) or another interested party to determine how frequently end user 104 (FIG. 1) interacts with various widget depths and separating such interactions into the one or more depth ranges 913, 915 in a manner to efficiently utilize wireless interface 106; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of analyzer 911 to initiate sending a content update message 945 to wireless device 700, where content update message 945 includes a first portion 907 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; e.g., referring to Table 1, if a user is observed interacting with a widget only to a depth of 2, then content update message 945 could be provided with a first portion of updated content 944 corresponding to the depth of 2, e.g. the update message would include the list of articles and individual articles with byline, but would not include the supporting WAP/HTML/XHTML article; correspondingly, subsequent content update messages may include a second portion of updated content 944 corresponding to a second informational hierarchical depth range based on the user navigation pattern historical data 901, e.g. continuing with the example of Table 1, the subsequent update may include only the supporting WAP/HTML/XHTML article, thereby supplementing the previously-sent content update message 945; moreover, content update package bundler 910 may include a compression module 919 operable to apply compression scheme 921 to updated content 944; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of compressor 919 to initiate sending a content update message 947 to wireless device 700, where content update message 947 includes a first compressed portion 923 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; updating content for a mobile widget includes obtaining updated content corresponding to a mobile widget having a plurality of widget depths at 612, wherein the updated content comprises a first size; obtaining user navigation pattern historical data corresponding to the mobile widget, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 614; obtaining a first widget depth range for inclusion in a first content update message, wherein the first widget depth range is based on the user navigation pattern historical data at 616; at 618, reducing a size of a first portion of the updated content corresponding to the first widget depth range according to a compression scheme, thereby defining a first compressed portion of the updated content having a second size less than the first size; wirelessly transporting the first (optionally, compressed) portion of the updated content in the first content update message to a wireless communication device corresponding to the mobile widget (Block 620); in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request; storing a mobile widget on a wireless communication device, where the mobile widget comprises a plurality of widget depths at 632; tracking user navigation patterns corresponding to the mobile widget to define user navigation pattern historical data, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 634; forwarding the user navigation pattern historical data to a network device associated with a content source at 636; wirelessly receiving a first (optionally, compressed) portion of updated content in a first content update message from the content source at 638; in this case, in one aspect, the first portion of updated content corresponds to a first widget depth range of the mobile widget based on the user navigation pattern historical data; in another aspect, the first portion of the updated content is compressed according to a compression scheme and thus comprises a second size less than a first size of a corresponding first decompressed portion of the updated content; e.g., in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Mandyam in view of Lee et al. (US 2008/0113656 A1, pub. date: 03/15/2008), hereinafter Lee.
Claim 14
Mandyam discloses all the elements as stated in Claim 10 except and further discloses wherein a native application receiving the content update further (Mandyam, ¶ [0066]: widget operation modes: (i) compressed mode: an individual widget frame for display on a widget wall; and (ii) expanded mode: an individual widget frame for display when the mobile widget is selected, where the widget frame in the expanded mode may be sized larger than the respective widget frame in the compressed mode; ¶¶ [0159]-[0163]: efficient content delivery may become even more desirable when several different transport mechanisms (e.g. SMS, HTTP (web) connection, IP socket, etc.) are utilized for a service; compact protocol may be utilized to support widget content delivery; a mobile widget service can send a simple widget identifier when a content update is desired; data compression may be utilized for transport optimization; delta compression schemes can be used to further to further improve efficiency in transporting content for updates, particularly if the updates are provided multiple times per day; if we assume, for instance, that only one news item had changed from a previous update, then resending the whole file may be avoided and instead just enough metadata to update the previous file can be sent; as such, in one aspect, only a delta content update is sent, wherein the delta content update represents the difference between the prior content update and the current content update; a benefit in this case is to save on decompression computation at the wireless communication device; in another aspect, the data compression scheme may be applied to the delta content update to further reduce its size; ¶¶ [0164]-[0179] with FIGS. 1 and 24-26 and TABLE 1: the transport of mobile widget content may be further optimized by taking into account widget depth, or widget level or layer content interaction; widget depth refers to the number of clicks into a widget from the widget wall that is possible before the user's experience within the widget is terminated; CAS 900 may be operable to receive user navigation pattern historical data 901 that tracks one or more widget depths 903 corresponding to user inter action with one or more mobile widgets 102; CAS 900 may be operable to receive updated content 944 from content provider 902, wherein updated content 944 includes one or more content portions 907 corresponding to one or more widget depths 903 of a respective mobile widget 102; content update package bundler 910 of CAS 900 includes an analyzer module 911 operable to access user navigation pattern historical data 901 and determine one or more depth ranges 913, 915 corresponding to a distribution of recorded user interactions with a respective mobile widget 102; analyzer module 911 may include one or any combination of logic, fuzzy logic, heuristics, algorithms, neural networks, etc., which may be configurable by operator/carrier 110 (FIG. 1) or another interested party to determine how frequently end user 104 (FIG. 1) interacts with various widget depths and separating such interactions into the one or more depth ranges 913, 915 in a manner to efficiently utilize wireless interface 106; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of analyzer 911 to initiate sending a content update message 945 to wireless device 700, where content update message 945 includes a first portion 907 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; e.g., referring to Table 1, if a user is observed interacting with a widget only to a depth of 2, then content update message 945 could be provided with a first portion of updated content 944 corresponding to the depth of 2, e.g. the update message would include the list of articles and individual articles with byline, but would not include the supporting WAP/HTML/XHTML article; correspondingly, subsequent content update messages may include a second portion of updated content 944 corresponding to a second informational hierarchical depth range based on the user navigation pattern historical data 901, e.g. continuing with the example of Table 1, the subsequent update may include only the supporting WAP/HTML/XHTML article, thereby supplementing the previously-sent content update message 945; moreover, content update package bundler 910 may include a compression module 919 operable to apply compression scheme 921 to updated content 944; in one optional aspect, CAS 900 or content update package bundler 910 may utilize the results of compressor 919 to initiate sending a content update message 947 to wireless device 700, where content update message 947 includes a first compressed portion 923 of updated content 944 corresponding to a first informational hierarchical depth range 913 based on the user navigation pattern historical data 901; updating content for a mobile widget includes obtaining updated content corresponding to a mobile widget having a plurality of widget depths at 612, wherein the updated content comprises a first size; obtaining user navigation pattern historical data corresponding to the mobile widget, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 614; obtaining a first widget depth range for inclusion in a first content update message, wherein the first widget depth range is based on the user navigation pattern historical data at 616; at 618, reducing a size of a first portion of the updated content corresponding to the first widget depth range according to a compression scheme, thereby defining a first compressed portion of the updated content having a second size less than the first size; wirelessly transporting the first (optionally, compressed) portion of the updated content in the first content update message to a wireless communication device corresponding to the mobile widget (Block 620); in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request; storing a mobile widget on a wireless communication device, where the mobile widget comprises a plurality of widget depths at 632; tracking user navigation patterns corresponding to the mobile widget to define user navigation pattern historical data, wherein the user navigation pattern historical data corresponds to the plurality of widget depths at 634; forwarding the user navigation pattern historical data to a network device associated with a content source at 636; wirelessly receiving a first (optionally, compressed) portion of updated content in a first content update message from the content source at 638; in this case, in one aspect, the first portion of updated content corresponds to a first widget depth range of the mobile widget based on the user navigation pattern historical data; in another aspect, the first portion of the updated content is compressed according to a compression scheme and thus comprises a second size less than a first size of a corresponding first decompressed portion of the updated content; e.g., in order to efficiently utilize wireless bandwidth when updating one or more mobile widgets, the most frequently reviewed portions of the updated content are sent first, and the remaining portions of content may be sent later or only sent upon request).
Mandyam fails to explicitly disclose wherein a native application receiving the content update further receives an indicator identifying whether a full update or a partial update is included in the content update.
Lee teaches a system and a method for updating contents (Lee, ¶ [0003]), wherein a native application receiving the content update further receives an indicator identifying whether a full update or a partial update is included in the content update (Lee, ¶¶ [0037]-[0039] with FIG. 1: the content provision server 104 receives, from the mobile terminals 101 through 103, a selection of content information to be updated; the content provision server 104 determines scheduling of update time information, which is classified by the member, and transmits, to the mobile terminals 101 through 103 of each member, the update time information being the determined scheduling; the
update time information may denote a time of transmitting the updated content information when contents desired by the member are updated, and may be variously set for each member; ¶¶ [0046]-[0057] with FIG. 2: the scheduling unit 201 determines scheduling of update time information which is classified by a member; the update time information is a time related to transmitting the updated contents to each mobile terminal of each member, and the scheduling unit 201 may classify the member into at least two groups, and variously set the update time information for each group; the update time information includes at least one of an update starting time, an update completion time, a standard time, a delay time from the standard time, and an update interval; the update starting time includes information of an update execution starting time, and the update completion time includes information of an update execution completion time; also, the standard time denotes a time being a standard of an update execution, and the delay time denotes a delay time which an update is executed from the standard time; also, the update interval denotes an interval between an update execution and a subsequent update execution; the content information includes update information and template information; also, the update information is changed at each update of the content information, and the template information is a basic structure configuring the content information, and is maintained for each update of the content information; the update information includes update type information and update detail information; the update type information is information of a type of information to be
updated, and is information of a type of content which classifies information provided for the member, such as a stock and news; also, the update detail information is detail information provided for the member of the mobile terminal, and includes various forms based on the update type and an output type, e.g., a text file (TXT), an image file (IMG), and the like; determines whether the content information included in the mobile terminal 210 is up-to-date information; when the content information is out-of-date information, the system 200 for updating the contents may control the content provision server 104 so that the up-to-date content information may be transmitted to the corresponding terminal 210; ¶¶ [0071]-[0075] with FIG. 3: the content provision server 104 may store update type information/update detail information and inventory information in the content information corresponding to the current server state; the update detail information is an update method, e.g., any one of a total update (Ο) and a partial update (Δ); also, the inventory information includes a sequence corresponding to the update detail information; when it is currently "8:50", the system 200 for updating the contents according to the present invention may receive an update request signal for a first member at "9:00", and transmit the content information with respect to "0001 news" (the total update (Ο)) to the mobile terminal 210 of the first member; also, the system 200 for updating the contents may receive the update request signal for a second member at "9:00", and transmit the content information with respect to "0001 news, a stock, and weather" (the total update (Ο)) to the mobile terminal 210 of the second member; also, when it is currently "10:50", the system 200 for updating the contents according to the present invention may receive the update request signal for the first member at "11:00", and transmit the content information with respect to "0003 news" (the partial update (Δ)) to the mobile terminal 210 of the first member; also, the system 200 for updating the contents may receive the update request signal for the second member at "11:00", and transmit the content information with respect to "0002 stock" (the partial update (Δ)) and the content information with respect to "0003 news" (the total update (Ο)) to the mobile terminal 210 of the second member; also, the system 200 for updating the contents may store a membership channel which is classified by the member, a standard time, the inventory information, and the update detail information which is classified by the update type after the update).
Mandyam and Lee are analogous art because they are from the same field of endeavor, a system and a method for updating contents. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to apply the teaching of Lee to Mandyam. Motivation for doing so would effectively perform the synchronization between the mobile terminal and the server (Lee, ¶¶ [0072] and [0143]).
Allowable Subject Matter
Claims 1-9 and 16-20 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action.
The following is a statement of reasons for the indication of allowable subject matter:
In regard to independent Claims 1 and 16, prior arts of records, either singularly or in combination, do not teach or suggest the combination of claimed elements including "a method for proactive content service delivery, the method comprising: determining a delivery interval for a content update provided to a user, wherein determining the delivery interval comprises: defining a plurality of delivery interval dimensions, each delivery interval dimension comprising a unique combination of one time cohort of two or more time cohorts and one user cohort of two or more user cohorts; determining a time cohort and a user cohort for the user; and selecting a predetermined delivery interval for one of the plurality of delivery interval dimensions matching the time cohort and the user cohort of the user as the delivery interval; determining a delivery content for the content update provided to the user, wherein determining the delivery content comprises: training a classification model to predict whether content will result in an impression; inputting, into the classification model, the content update; receiving, as output from the classification model, an impression score for the content update; and selecting one of a full update and a partial update as the delivery content from the impression score; and pushing the content update comprising the delivery content to a client device of the user at a frequency defined by the delivery interval" or "a system comprising: a proactive content delivery system comprising a memory having computer readable instructions and one or more processors for executing the computer readable instructions, the computer readable instructions controlling the one or more processors to perform operations comprising: determining a delivery interval for a content update provided to a user, wherein determining the delivery interval comprises: defining a plurality of delivery interval dimensions, each delivery interval dimension comprising a unique combination of one time cohort of two or more time cohorts and one user cohort of two or more user cohorts; determining a time cohort and a user cohort for the user; and selecting a predetermined delivery interval for one of the plurality of delivery interval dimensions matching the time cohort and the user cohort of the user as the delivery interval; determining a delivery content for the content update provided to the user, wherein determining the delivery content comprises: training a classification model to predict whether content will result in an impression; inputting, into the classification model, the content update; receiving, as output from the classification model, an impression score for the content update; and selecting one of a full update and a partial update as the delivery content from the impression score; and pushing the content update comprising the delivery content to a client device of the user at a frequency defined by the delivery interval" when interpreted as a whole.
Mandyam discloses all the elements as stated in Claims 10-15.
Lee discloses all the elements as stated in Claim 14.
Vijay et al. (US 2017/0026331 A1, pub. date: 01/26/2017) discloses in ABSTRACT and ¶¶ [0026]-[0030] that (1) optimizing a delivery time for the delivery of messages; (2) determine, for each of a plurality of time intervals, a likelihood of a particular member of an online social network service performing a particular member user action on a particular message content item during the corresponding time interval; (3) the plurality of time intervals are then ranked, based on the determined likelihoods corresponding to the plurality of time intervals; (4) thereafter, a particular time interval is identified from among the plurality of time intervals that is associated with a highest ranking; (5) the particular time interval is then classified as an optimum personalized message delivery time for the particular member; (6) predict the likelihood of a user performing a user action on a particular email content item; (7) predict the likelihood that a particular member of an online social network service (e.g., Linkedin®) will click on a particular item in a digest email; (8) predict the likelihood that a particular member of the online social network service will access, open, or view any mail; (9) determine or predict what emails (or what content within emails) a member of an online social network service is likely to interact with; (10) this information may be used by the email response prediction system to, e.g., downshift/filter out certain email's to members if the email response prediction system determines that there's a low likelihood of a click on that email, which may reduce costs and member annoyance, while dramatically improving click through rate (CTR); (11) encode raw data from external data sources into feature vectors, and assembles the feature vectors to generate an assembled feature vector; (12) the assembled feature vector output by the source module may include various features describing a member of a social networking website, a particular email content item, a member's email activities, a member's other activities on the social networking website, activities of similar members, activities of a member's connections, and so on; (13) the assembled feature vector may then be passed to a prediction module for predicting whether the particular member will click on the particular email content item; (14) the prediction module may apply a statistics-based machine learning model such as a logistic regression model to the features in the assembled feature vector; e.g., use an L2-regularized logistic regression; (15) to improve the user experience, for a given member and email type or content, predict the response probability (where the response can be a click, registration or any other activity); and (16) with such a probability, a number of actions can be taken, including deciding not to send the email, recommending an un-subscription, personalizing the email by re-ordering the contents, portfolio optimization processes (where the e-mail response prediction system adjusts various aspects of e-mail distribution to conform to members interests holistically), and so on. Vijay further discloses in ¶¶ [0031]-[0035] with FIG. 1 that (1) the user interface module(s) 22 may receive requests in the form of Hypertext Transport Protocol (HTTP) requests, or other web-based, application programming interface (API) requests; (2) individual application server modules 24 are used to implement the functionality associated with various services and features of the social network service; e.g., the ability of an organization to establish a presence in the social graph of the social network service, including the ability to establish a customized web page on behalf of an organization, and to publish messages or status updates on behalf of an organization; (3) profile data, including both member profile data as well as profile data for various organizations; (4) when one member follows another, the member who is following may receive status updates or other messages published by the member being followed, or relating to various activities undertaken by the member being followed; (5) similarly, when a member follows an organization, the member becomes eligible to receive messages or status updates published on behalf of the organization; e.g., messages or status updates published on behalf of an organization that a member is following will appear in the member's personalized data feed or content stream; (6) the social network service may provide a broad range of other applications and services that allow members the opportunity to share and receive information, often customized to the interests of the member; (7) members may be able to self-organize into groups, or interest groups, organized around a subject matter or topic of interest; (8) the members' behavior (e.g., content viewed, links or member-interest buttons selected, etc.) may be monitored and information concerning the member's activities and behavior may be stored, wherein this information may be used to classify the member as being in various categories; e.g., if the member performs frequent searches of job listings, thereby exhibiting behavior indicating that the member is a likely job seeker, this information can be used to classify the member as a job seeker; and (9) this classification can then be used as a member profile attribute for purposes of enabling others to target the member for receiving messages or status updates. Vijay also discloses in ¶¶ [0037]-[0076] with FIGS. 2-16 that (1) the source module 202 is configured to access various data, including email content data describing a particular email content item and member email interaction data describing a particular member's interactions with various email content; (2) the source module 202 also encodes the data accessed from the external data sources into one or more feature vectors, and assembles the one or more feature vectors to thereby generate an assembled feature vector (see FIG. 5); (3) thereafter, the prediction module 204 performs a prediction modeling process based on the assembled feature vector and a prediction model to predict a likelihood of a particular member performing a particular user action on a particular email content item (e.g., the email content item described by the raw email content data); (4) the prediction module 204 may use any one of various known prediction modeling techniques to perform the prediction modeling; e.g., the prediction module 204 may apply a statistics- based machine learning model such as a logistic regression model to the assembled feature vector; (5) the raw features may be any type of information that may be used to predict the likelihood that a particular member will perform a particular user action on a particular email content item; e.g., the source modules 202 may access email content data describing a particular email content item and member email interaction data describing a particular member's interactions with various email content; (6) the term "email content item" refers to an email of a particular type, such as a network connection update e-mail, a news update e-mail, a jobs update e-mail, an influencer post update e-mail, a company update e-mail, a group update e-mail, and a university update e-mail; (7) the email type is a digest e-mail associated with an online social network service (see FIG. 3), the digest e-mail including at least one of network connection update information, news update information, jobs update information, influencer post update information, company update information, group update information, university update information; (8) the term "email content item" refers to content included within an email (e.g., a digest email), such as network update information, influencer update information, jobs update information, groups update information, universities update information, companies update information, etc.; (9) the email content item may be an advertisement, offer, promotion, coupon, special, deal, an article, a news item, a blog post, and so on, included in an email or another notification (e.g., text message, instant message, chat message, etc.); (10) the user action may be a click response, a non-click response, a hover response (e.g., the user causes a mouse cursor to hover over the email content item for a predetermined period of time), an unsubscribe response, a conversion response (e.g., the user selects an advertisement or offer in the email and completes a transaction based on the advertisement), a like response (e.g., the member likes the item), a comment response (e.g., the member comments on the item), a share response e.g., the member shares the item), a follow response (e.g., the member follows the items), a rating response (e.g., the member rates the email content item, based on a range of rating options displayed in conjunction with the email content item), and so on; (11) the email content data accessed by the source module 202 specifies an email type, email format, email title, email keywords, and email image, email content item rendering information (e.g., various rendering characteristics of an email content item with respect to the appearance of the email content item, such as email format, email size/shape, email image characteristics, email color characteristics, email border/frame characteristics, email title font size, email title font type, email keyword font size, email keyword font type, etc.), and so on; (12) FIG. 6 illustrates an example of e-mail content data 600 that may be accessed by the source module 202 and encoded into a feature vector, wherein the email content data 600 identifies email type, email format, email title, email keywords, and email image, etc., for a given email; (13) thus, the source module 202 may encode the aforementioned email content data 600 into one or more feature vectors 501, which may be then be included in the final assembled feature vector 510 that is passed to the prediction module 204 (e.g., see FIG. 5); (14) the supervised-learning model performed by the prediction module 204 may take into account features related to the member's email activities (how many emails were sent out for each type and how many clicks were received, or if the member has unsubscribed from any types of emails, etc.); e.g., the source module 202 may access, from a data source (e.g., data sources 50a-50c in FIG. 5), member e-mail interaction data describing a history of the member's interaction with various e-mail content items for various types of emails (network connection update e-mail, a news update e-mail, etc.); (15) the member email interaction data may indicate a quantity of various email types transmitted to the particular member (e.g., over a given time interval), a quantity of clicks submitted by the particular member in conjunction with the various email types (e.g., over a given time interval), a quantity of email unsubscribe requests submitted by the particular member in conjunction with the various email types (e.g., over a given time interval); (16) FIG. 7 illustrates an example of member e-mail interaction data 700 that may be accessed by the source module 202 and encoded into a feature vector 502, wherein the member e-mail interaction data 700 identifies how many of a first type of e-mail and the user has received (e.g., over a given time period), how many of the first type of e-mail to the user has clicked on (e.g., over a given time interval), whether or not the user has unsubscribed from the first type of e-mail (e.g., during a given time interval), and so on for other types of e-mails; (17) thus, the source module 202 may encode the aforementioned member e-mail interaction data 700 into one or more feature vectors 502, which may be then included in the final assembled feature vector 510 that is passed to the prediction module 204 (e.g., see FIG. 5); (18) the supervised learning model performed by the prediction module 204 may take into account features related to the member's other activities on the site (page views, likes, the volume and type of the content consumed, the searches conducted on the site, etc.); (19) the member site interaction data may indicate a quantity of various user actions (e.g., views, impressions, likes, comments, shares, follows, posts, etc. performed by the particular member in association with the various features, products, or content, associated with an online social network service (e.g., a content feed, a people you may know user interface, a search user interface, a jobs page, a member profile page, a company's page, a groups page, an Influencers page, a university page, etc., on Linkedin); (20) FIG. 8 illustrates an example of member site interaction data 800 that may be accessed by the source module 202 and encoded into a feature vector 503, wherein the member e-mail interaction data 800 identifies how many times the user has performed a particular user action (e.g., views, impressions, likes, comments, shares, follows, posts, etc.) in conjunction with the particular product feature (e.g., during a given time interval); (21) thus, the source module 202 may encode the aforementioned member site interaction data 800 into one or more feature vectors 503, which may be then included in the final assembled feature vector 510 that is passed to the prediction module 204 (e.g., see FIG. 5); (22) the member email interaction data and/or member site interaction data may include context data or context features describing a potential or actual context in which a particular member may interact with a particular email content item or site product; (23) examples of raw context data include time, date, hour of day, day of week, hour of week, Internet Protocol (IP) address, current user geo-location information, whether the email is accessed via a mobile device (e.g., smartphone or tablet) or a non-mobile device (e.g., desktop), the channel through which the email content item is displayed (e.g., email application, web-accessible email, SMS or MMS text message, instant chat message, in-mail service on Linkedin®, Messenger service on Facebook®, etc.), browser data describing a browser utilized to render email content (e.g., browser model, browser brand, browser capabilities, browser version, etc.), and so on; (24) the supervised learning model performed by the prediction module 204 may take into account member profile data related to the member (e.g., member profile attributes); e.g., the source module 202 may access, from a data source (e.g., data sources 50a-50c in FIG. 5), member profile data describing a particular member, including gender, age, current location, previous locations, industry, education, alma mater, current job, current employer, previous jobs, previous employers, experience, skills, number of connections, endorsements, seniority level, company size, identity of connections, networks, groups, interests, preferences, hobbies, purchase history, browsing history, ethnicity, sexual orientation, and so on; (25) FIG. 9 illustrates an example of member profile data 900 that may be accessed by the source module 202 and encoded into a feature vector 504, which may be then included in the final assembled feature vector 510 that is passed to the prediction module 204 (e.g., see FIG. 5); (26) the supervised learning model performed by the prediction module 204 may take into account various features related to the member connections of the particular member on the online social network service; (27) the source module 202 may extract various types of data described above ( e.g., member profile data, member e-mail interaction data, member site interaction data, etc.) that are associated with the member's connections; (28) the source module 202 may access such information associated with one or more member connections having a certain degree of connectedness with the particular member (e.g., first-degree only, or first and second degree connections only, etc.); (29) the source module 202 may access information associated with one or more member connections that have interacted with the particular member to a certain extent degree (e.g., exchanged a threshold number of messages, posts, recommendations, endorsements, etc., with the particular member), and so on; (30) thus, the source module 202 may encode the aforementioned data into one or more feature vectors 505, which may be then included in the final assembled feature vector 510 that is passed to the prediction module 204 (e.g., see FIG. 5); (31) in a case where features for a single member connection are utilized, the source module 202 may generate a feature vector for the data (e.g., the member site interaction data) for a single member connection for insertion into the assembled feature vector; (32) in a case where features from multiple member connections are utilized, the source module 202 may generate a separate feature vector for the data (e.g., the member site interaction data) of each member connection for insertion into the assembled feature vector, or the source module 202 may generate a single feature vector for the data (e.g., the member site interaction data) of all the member connections (e.g., based on average, median, mean, etc., values) for insertion into the assembled feature vector; (33) the activity of the member connections may be weighted by the strength of the connection; e.g., if the source module 202 determines that a given member connected to the particular member has a strong relationship with the particular member (e.g., based on the exchange of a threshold number of messages, posts, recommendations, endorsements, etc., with the particular member), then the source module 202 may weigh the data associated with this member connection more than the data associated with another member connection; (34) the supervised learning model performed by the prediction module 204 may take into account various features related to members of the online social network service that are similar to the particular member; e.g., the source module 202 may extract various types of data described above (e.g., member profile data, member e-mail interaction data, member site interaction data, etc.) that are associated with similar members; (35) the source module 202 may determine similar members based on similarities in the member profile data of various members e.g. members that have the same/similar titles, seniority levels, etc., or work in the same industry, function area, etc.), as well as similarities based on other member activities ( e.g., member site interaction data, member e-mail interaction data, etc.), or based on similarities in the connections of the members, and so on; (36) thus, the source module 202 may encode the features of similar members into one or more feature vectors 506, which may be then included in the final assembled feature vector 510 that is passed to the prediction module 204 (e.g., see FIG. 5); (37) in a case where features for a single similar member are utilized, the source module 202 may generate a feature vector for the data (e.g., the member site interaction data) for a single similar member for insertion into the assembled feature vector; (38) in a case where features from multiple similar members are utilized, the source module 202 may generate a separate feature vector for the data (e.g., the member site interaction data) of each similar member for insertion into the assembled feature vector, or the source module 202 may generate a single feature vector for the data (e.g., the member site interaction data) of all the similar members (e.g., based on average, median, mean, etc., values) for insertion into the assembled feature vector; (39) the activity of the member connections may be weighted by how similar the member is to the particular member; e.g., if the source module 202 determines that a similar member is very similar to a particular member (e.g., based on a close match between the member profile attributes of the similar member and the particular member), then the source module 202 may weight the data associated with this similar member more than the data associated with another member that is not as similar to the particular member; (40) the features associated with one or more similar members or member connections of the particular member may replace the features associated with the particular member of themselves; e.g., the features associated with similar members or member connections may be inserted into the feature vectors 502-504; (41) the source module 202 encodes the data accessed from the external data sources into one or more feature vectors 501-506, and assembles the one or more feature vectors to thereby generate an assembled feature vector 510 (see FIG. 5); (41) the source module 202 may access a configuration file (e.g., in database 208) specifying raw data encoding rules that describe how the rotator is to be encoded into the feature vectors; (42) the prediction module 204 performs a prediction modeling process based on the assembled feature vector 510 and a prediction model to predict a likelihood (e.g., the probability) of the particular member performing a particular user action (e.g., click) on the particular email content item ( e.g., a particular type of e-mail); (43) the prediction module may perform the prediction modeling process based on a statistics-based machine learning model such as a logistic regression model; (44) logistic regression is an example of a statistics-based machine learning technique that uses a logistic function; (45) the logistic function is based on a variable, referred to as a logit which is defined in terms of a set of regression coefficients of corresponding independent predictor variables; (46) logistic regression can be used to predict the probability of occurrence of an event given a set of independent/predictor variables; (47) the independent/predictor variables of the logistic regression model are the attributes represented by the assembled feature vectors described throughout; (48) the regression coefficients may be estimated using maximum likelihood or learned through a supervised learning technique from data collected in logs or calculated from log data; (49) accordingly, once the appropriate regression coefficients (e.g., B) are determined, the features included in the assembled feature vector may be plugged in to the logistic regression model in order to predict the probability that the event Y occurs (where the event Y may be, e.g., whether the particular member clicks on the particular email content item in the particular context); i.e., provided an assembled feature vector including various features associated with a particular member, a particular email content item, a member's email activities, a member's other activities on an online social network service website, and so on, the assembled feature vector may be applied to a logistic regression model to determine the probability that the particular member will respond to the particular email content item in a particular way (e.g., click); (50) other prediction modeling techniques may include other machine learning models such as a Naive Bayes model, a support vector machines (SVM) model, a decision trees model, and a neural network model; (51) if the prediction module 204 is utilizing a logistic regression model, then the regression coefficients of the logistic regression model may be learned through a supervised learning technique from data collected in logs or calculated from log data; e.g., access all the log entries in the past 30 days where various members performed various user actions (e.g., a click or a non-click) on various email content items, and the email response prediction system may convert each of these log entries into an assembled feature vector; (52) for the purposes of training the system 200, the system 200 generally needs both positive training examples of where users performed an action (e.g., click), as well as negative training examples of where users did not perform the action (e.g., non-click); (53) the assembled feature vectors (e.g., the assembled feature vector 510 illustrated in FIG. 5) may then be passed to the prediction module, in order to refine regression coefficients for the logistic regression model; (53) once the regression coefficients are determined, the email response prediction system 200 may operate to perform online inferences based on the trained model (including the trained model coefficients) on a single assembled feature vector; (54) the email response prediction system 200 is configured to predict the likelihood that a particular member will perform a particular user action for various email content items, in order to determine which of the various email content items should be displayed to the particular member in the particular context; (55) in operation 401, the source module 202 accesses email content data describing a particular email content item and member email interaction data describing a particular member's interactions with various email content; (56) in operation 402, the source module 202 encodes the data accessed from the external data sources into one or more feature vectors; (57) in operation 403, the source module 204 assembles the one or more feature vectors to thereby generate an assembled feature vector (see FIG. 5); (58) finally, in operation 404, the prediction module 204 performs a prediction modeling process based on the assembled feature vector and a prediction model to predict a likelihood of a particular member (e.g., the member described in the raw member data) performing a particular user action on a particular email content item (e.g., the email content item described by the raw email content data); (59) in operation 1001, the source module 202 identifies similar members of the online social network service that are similar to the particular member; (60) the similar members may be identified by: accessing member profile data associated with the particular member; and determining a match between member profile data associated with the similar members and the accessed member profile data associated with the particular member; (61) the similar members may be identified by similarities based on other member activities e.g., member site interaction data, member e-mail interaction data, etc.), or based on similarities in the connections of the members, and so on; (62) in operation 1002, the source module 202 accesses at least one of member profile data, member email interaction data, and member site interaction data associated with the one or more similar members; (63) in operation 1003, the source module 202 inserts at least one of the member profile data, the member email interaction data, and the member site interaction data associated with the one or more similar members into the assembled feature vector; (64) in operation 1101, the source module 202 identifies member connections that are connected to the particular member via the online social network service. In operation 1102, the source module 202 accesses at least one of member profile data, member email interaction data, and member site interaction data associated with the one or more member connections; (65) in operation 1103, the source module 202 inserts at least one of the member profile data, the member email interaction data, and the member site interaction data associated with the one or more member connections into the assembled feature vector; (66) after the prediction module 204 determines the likelihood that a particular member performs a particular user action (e.g., clicks, opens, views, etc.) on an e-mail content item (e.g., a particular type of e-mail such as a network update e-mail, jobs update e-mail, a news update e-mail, etc.), the email management module 206 of the email response prediction system 200 may compare the likelihood with various predetermined thresholds, in order to adjust, downshift, or refine the quantity, frequency, and type of e-mails being transmitted to the particular member; (67) if the predicted likelihood is lower than a predetermined threshold (e.g., indicating that the particular member is not likely to click on that e-mail content item), then the email management module 206 may reduce the distribution of that type of e-mail content item to the particular member; e.g., (a) the email management module 206 may adjust e-mail preference settings associated with the particular member (e.g., see FIG. 12) to cause the reduction in the distribution of that particular type of e-mail content item to the particular member; (b) the email management module 206 may reduce the frequency of that particular type of e-mail from being transmitted to the member (e.g., from daily to weekly or monthly, etc.); (c) the email management module 206 may temporarily prevent that e-mail type from being transmitted to the member, e.g., the email management module 206 may prevent the next X e-mails of that type from being transmitted to the member, or the email management module 206 may prevent that e-mail type from being transmitted to the member for a given time period, such as the next week, or month, or six months, etc.); (d) the email management module 206 may automatically unsubscribe the user from that type of e-mail; and (e) the email management module 206 may reduce a quantity of that e-mail content item within an e-mail message (e.g., only 2 news items per e-mail instead of 10 news items per e-mail), the 206 may reduce this quantity of e-mail content type either temporarily or indefinitely (e.g., until the user changes the appropriate settings in their e-mail preference settings); (68) in the case of a digest e-mail (which may include network updates, news updates, influencer posts, group updates, etc.), if the prediction module 204 determines that the likelihood that the particular member will perform the user action on that e-mail content item is lower than a specific threshold, then the email management module 206 may reduce the distribution of that particular content item in the digest e-mails; (69) if the likelihood is higher than a predetermined threshold (e.g., indicating that the particular member is likely to click on that e-mail content item), then the email management module 206 may maintain or increase the distribution of that type of e-mail content item to the particular member; (70) in the case of a digest e-mail (which may include network updates, news updates, influencer posts, group updates, etc.), if the prediction module 204 determines that the likelihood that the particular member will perform the user action on that e-mail content item is higher than a specific threshold, then the email management module 206 may maintain or increase the distribution of that particular e-mail content item in the digest e-mails; (71) the email response prediction system may be utilized for portfolio optimization processes (e.g., where the e-mail response prediction system adjusts various aspects of e-mail distribution to conform to members interests holistically);e.g., the prediction module 204 may utilize the calculated likelihoods for the purposes of e-mail portfolio optimization by placing more or less restrictions on the amounts, type, characteristics, and so on, e-mails sent to one or more members of an online social network; (72) the email response prediction system may adjust the frequency of email distribution via thresholds or via a more holistic approach where a number of parameters can be optimized simultaneously, or a number of different constraints can be enforced simultaneously; (73) based on particular member's interests and inferred intent, the system 200 may choose a set of e-mails every week to send to a member; (74) in operation 1401, the email management module 206 determines that the likelihood of the particular member performing the particular user action on the particular email content item is lower than a predetermined threshold; (75) in operation 1402, the email management module 206 reduces a distribution of the particular email content item to the particular member; (76) the email management module 206 may update email preference settings associated with the particular member, the updated email preference settings specifying a reduced quantity or frequency of the particular email content item for distribution to the particular member; (77) in operation 1501, the source module 202 determines that the likelihood of the particular member performing the particular user action on the particular email content item is greater than a predetermined threshold; (78) in operation 1502, the source module 202 increases a distribution of the particular email content item to the particular member; e.g., the email management module 206 may increase a quantity of the particular email content item included in an e-mail for distribution to the particular member; (79) for the representation of the features, the system 200 use a number of techniques, including computing confidence intervals based on historical actions (depending on their distribution, e.g., binomial distribution, etc.) and use the boundary values as features; (80) the promotion content may be similar to an advertisement and may be configured to promote (or provide a user with a sample of) different types of products and services of the online social network service; (81) FIG. 16 illustrates an exemplary e-mail 1600 (e.g., digest e-mail), where the e-mail 1600 includes a main portion 1601 with one or more pieces of content, as well as a lower portion 1602 that includes promotion content 1603, where such promotion content may be included in any type of e-mail, such as network update e-mails, content to digest e-mails group digest e-mails, and so on, in order to encourage users to become engaged with various products on Linkedin or another website or service; (82) find what piece of promotion content makes more sense for each e-mail and/or for each user; and (83) more specifically, the e-mail response prediction system may be utilized to determine the particular type and form of promotion content 1603 that is most appropriate to include in a particular e-mail having other types of content. Vijay further teaches in ¶¶ [0077]-[0103] with FIGS. 2, 5, and 17-19 that (1) FIG. 17 illustrates examples of an inclusive vector approach 1 and a segmented model approach 2; (2) in approach 1, a model M may be trained based on a feature vector 1700 including a feature F (e.g., job seeker status), which may have either a value V1 (e.g., user is a job seeker) and a value V2 ( e.g., user is not a job seeker), as well as other features in addition to Feature F; (3) thus, in approach 1, all the features of both job-seekers and non-job seekers as well as an feature F indicating whether a member is a job-seeker or not) are included in a vector 1700; (3) in contrast, in approach 2, the data for job-seekers is separated and included in the vector 1701 associated with Model M1, whereas the data for non-job seekers is separated and included in the vector 1702 for Model M2, and each model M1 and M2 is trained separately; (4) thus, in approach 2, all the data examples for job-seekers are included in a first model M1 and all the data examples for non-job-seekers are included in a second model M2, and each model is trained separately; (5) in some cases, the overall performance may be better with the 2nd approach, particularly if the behavior of job-seekers and non-job seekers is dramatically different; (6) a segmented model approach may be utilized for any other feature (e.g., members viewing from a mobile device versus members viewing from a PC, members with a regular subscription versus members with a premium subscription, etc.); (7) in the context of a Delivery Time Optimization (MD) process or campaign; (8) identify when would be the best time to deliver/send email(s) to members in accordance with DTO, in order to improve the response rate (clicks, conversions, etc.) to the email(s) by sending the email(s) at the most appropriate time; (9) predict a personalized delivery time (which could be in the form of day-of-week and/or hour-of-day value, etc.) for a given member and email pair; (10) utilize a member's profile data (context information, geolocation information, access time information, etc.), as well as a member's historical activities on emails and on the site, and any other features as described herein, in order to predict the aforementioned personalized delivery time; (11) in a case where there are multiple emails to send in a given time window (e.g., mails selected in connection with an email portfolio optimization process), predict when exactly to send such emails; (12) predict a likelihood of a particular user X performing a particular user action Y on a particular message content item Z; (12) utilize this approach to determine the optimum personalized delivery time to transmit a message to a particular member of an online social network service; (13) determine, for each of a plurality of time intervals, a likelihood of a particular member of an online social network service performing a particular user action on a particular message content item during the corresponding time interval; (14) the plurality of time intervals may then be ranked, based on the determined likelihoods corresponding to the plurality of time intervals; (15) thereafter, a particular time interval that is associated with a highest ranking may be identified from among the plurality of time intervals; (16) the particular time interval may then be classified as an optimum personalized message delivery time for the particular member; (17) one of the features utilized in predicting the likelihood that a member will interact with a message content item is the current time zone of the member (i.e., the time zone associated with the current location of the member); e.g., a time zone inference module 210 (see FIG. 2) configured to determine the current time zone of the member; (18) thus, a time zone feature e.g., a numerical value indicating a time zone associated with a given member) may then be input into the feature vector for the purposes of performing prediction modeling; (19) such feature(s) may be included in the feature vector 504 including the member profile data as shown in FIG. 5 or alternatively, as illustrated in FIG. 18, such time zone feature(s) may be included in a separate time zone feature vector 1807 that may be passed into the assembled feature vector 510; (20) time zone feature(s) may be useful for determining the likelihood that a particular member in a particular time zone will perform a particular user action on a particular message content item, since such features may be utilized to identify trends of how other members located in a particular time zone responded to e-mails; e.g. it may be the case that most users in a particular time zone (e.g., the Pacific time zone (PST)) tend to respond strongly to e-mails in the afternoon, local PST, whereas most users in another time zone (e.g., China standard Time zone (CST)) tend to respond more strongly to e-mails in the morning, local CST; (21) in order to determine the weight or relevance of such features in predicting how likely it is the user will interact with a particular content item during a particular time interval; e.g., the prediction models described herein may be trained based on training data indicating how members located in each time zone have interacted with e-mail content during various local times of the day; (22) thus, when performing an online inference to determine the likelihood that a particular member located in a particular time zone will interact in some manner with a particular content item, the historical interactions by other members in that time zone may be utilized in the prediction modeling; (23) one of the features utilized in predicting the likelihood that a member will interact with a message content item is experimental data indicating the results of various e-mail response experiments; e.g., (a) an experiment module 212 configured to transmit messages to a plurality of members at various local times (e.g., times of the day) and analyze the response to the messages; the experiment module 212 may send messages to users in each location at different (e.g., random or fixed) times of the day, and by analyzing how the users interact with the transmitted e-mails, and (b) the experiment module 212 may determine which times of the day produce the best responses to the messages (e.g., as measured by click through rates) in that time zone; (24) such experiment features (e.g., numerical values indicating message experiment response metrics associated with each of various locations or time zones) may then be input into a feature vector for the purposes of performing prediction modeling; (25) as shown in FIG. 5, such feature(s) may be included in the feature vector 502 including the member e-mail interaction data or alternatively, as illustrated in FIG. 18, such experiment feature(s) may be included in a separate experiment data feature vector 1808 that may be passed into the assembled feature vector 510; (25) determining the likelihood that a particular member will perform a particular user action on a particular e-mail content item, since such features may be utilized to identify trends of how other members located in a particular time zone have responded to e-mails during experiments; (26) the prediction models may be trained on experiment feature data in conjunction with various other features described herein, in order to determine the weight or relevance of such features in predicting how likely it is the user will interact with a particular content item during a particular time interval; e.g., the prediction models may be trained based on training data indicating experiment response metrics associated with members located in each time zone; (27) thus, when performing an online inference to determine the likelihood that a particular member located in a particular time zone will interact in some manner with a particular content item, the experimental results indicating interactions by other members in that time zone may be utilized in the prediction modeling; (28) the prediction module 204 may be trained based on training data associated with members in the particular time zone (e.g., the features included in the vectors 501-506, 1807, and 1808 may be associated with members located in a particular time zone), in order to generate a model optimized for that particular time zone; (29) a single prediction module 204 may perform the modeling for each time zone; (30) multiple prediction modules 204 may be provided, with each prediction module performing modeling for a given time zone; (31) in operation 1901, the prediction module 204 determines, for each of a plurality of time intervals, a likelihood of a particular member of an online social network service performing a particular member user action on a particular message content item during the corresponding time interval; (32) the message content item corresponds to at least one of an email message, a text message, a social network instant message, and a chat message; (33) each of the plurality of time intervals corresponds to a particular hour of the day; (34) each of the plurality of time intervals corresponds to a particular day of the week; (35) the time interval could also be any other time interval, such as an interval measured in seconds, minutes, days, weeks, months, seasons, etc.; (36) in operation 1902, the prediction module 204 ranks the plurality of time intervals, based on the determined likelihoods corresponding to the plurality of time intervals; e.g., the time interval associated with the highest likelihood may be ranked highest/first, the time interval associated with the second highest likelihood may be ranked second, and so on; (37) in operation 1903, the prediction module 204 identifies a particular time interval from among the plurality of time intervals that is associated with a highest ranking; e.g., if each of the time intervals corresponds to a particular hour of the day, then the prediction module 204 will identify the hour of the day when the particular member is most likely to perform the particular user action on the message content item; (38) in operation 1904, the prediction module 204 classifies the particular time interval as an optimum personalized message delivery time for the particular member; e.g., if the time interval associated with the highest likelihood is 2-3 pm, then the optimum personalized message delivery time may be set to 2-3 pm; (39) alternatively, the optimum personalized message delivery time may be set to a particular time or smaller time interval within the relevant time interval (e.g., 2:30 PM), or another time interval that is associated with the relevant time interval (e.g., the preceding hour, such as 1-2 PM), or a greater time interval that includes the relevant time interval (e.g., 1-5 PM, etc.); (40) thereafter, the prediction module 204 may adjust message delivery preferences associated with the particular member to indicate the optimum personalized message delivery time; (41) further, the prediction module 204 may transmit a message to the particular member at the optimum personalized message delivery time, based on the updated message delivery preferences associated with the particular member; (42) the time zone inference module 210 may utilize a combination of member profile attributes and IP address login information associated with a member in order to determine the current time zone of the member; (43) if the time zone inference module 210 determines that a single time zone is associated with the particular country, the time zone inference module 210 may determine that the member is currently located in that single time zone; (44) on the other hand, if the time zone inference module 210 determines that multiple time zones are associated with the particular country, then the time zone inference module 210 may access the last IP address associated with the last member login request from that member (e.g., from the last time that member logged into a website); (45) based on this IP address, the time zone inference module 210 may determine a geographic location (e.g., a city) associated with the IP address, and a time zone associated with that geographic location, in order to ultimately identify the specific time zone (from among the multiple time zones in that country) that the particular member is currently located in; (46) the time zone inference module 210 may determine the current time zone of the member based on different sources of information, and if there is a discrepancy in these determinations, the time zone inference module 210 may place a greater emphasis on the determination from a first source of information if that first source of information is associated with a higher weight; e.g., the time zone inference module 210 may place a lower weight on member profile data of the member, but a higher weight in the geolocation information from the member's mobile device; (47) if it is important for a particular product to have access to the real-time time zone of the member e.g., perhaps for an e-mail being sent immediately), then the geolocation information, IP address information, or the social activity information may be given greater importance and be assigned a higher weight, whereas the member profile data may be assigned smaller weight; (48) on the other hand, if it is important for a particular product to have access to a stable long-term time zone of the member (e.g., perhaps for weekly or monthly digest e-mails being transmitted to the member), then perhaps the member profile data may be assigned a higher weight in comparison to other sources of information; (49) the time zone inference module 210 may perform prediction modeling, using one or more prediction models (e.g., statistical machine learning models), in order to generate the aforementioned confidence score; (50) examples of prediction models include a logistic regression model, a Naive Bayes model, a support vector machines (SVM) model, a decision trees model, and a neural network model; (51) the time zone inference module 210 may take into account historical data associated with any of the aforementioned sources of information in order to detect a change in time zone associated with the member, and in order to determine whether such a change in time zone represents a permanent or temporary change in time zone; (52) the experiment module 212 is configured to identify the optimum time for delivering messages ( e.g., e-mails) to users in different geographic locations (e.g., different time zones).; (53) the experiment module 212 may identify optimum local message delivery times by performing various message response experiments with respect to users in each location; (54) the geographic locations described herein may correspond to any known type of location, such as a time zone, building, street, neighborhood, suburb, city, county, state, region, country, latitude, longitude, etc.; (55) the response metrics may correspond to any type of metric for measurement of how a user interacts with or responds to a content item such as a message; e.g., (a) the response metric may correspond to an access rate indicating rates at which users open, view, or access a message (e.g., by clicking on the message in an inbox in order to open and view the message), and such an access rate may measure the number of access events in comparison to a number of impressions (e.g., the number of times the message was transmitted); (b) the response metric may also correspond to a raw number of access events, a number of access events during a predetermined time interval, and so on; (c) the response metric may correspond to a click through rate indicating rates at which users click on some content within the message (e.g., a reference link that takes the user to a site), and such a click through rate may measure the number of clicks in comparison to a number of impressions (e.g., the number of times the message was rendered to users); (d) the response metric may also correspond to a raw number of clicks, a number of clicks during a predetermined time interval, and so on; (e) the response metric may correspond to a reply rate indicating rates at which users reply to the message, and such a reply rate may measure the number of replies in comparison to a number of impressions (e.g., the number of times the message was rendered and viewed by users, or the number of times the message was transmitted to users); (f) the response metric may also correspond to a raw number of replies, a number of replies to during a predetermined time interval, and so on; and (g) similarly, other types of response metrics capturing other possible types of responses may be utilized (e.g., specific user interface movements such as swipes, expanding content, zooming in and out of content, conversions, deletions of content, unsubscribes, marking content as spam, hover responses, etc.); (56) the experiment module 212 may display a user interface enabling a user of the email response prediction system 200 to specify exact times when e-mails should be transmitted, or to specify that e-mails should be transmitted at fixed intervals e.g., every second, every minute, every 30 minutes, every hour, etc.); and (57) determine not only an optimum time of the day to transmit e-mails, but also an optimum day of the week to transmit e-mails; e.g., the experiment module 212 may transmit e-mails to each of the 5000 members in the test base at the same time of the day (e.g., 10 AM) on a random weekday doing the given experiment cycle, and may analyze the results to determine if e-mails transmitted on a certain day of the week tend to produce greater response metrics.
Ju et al. (US 2018/0139295 A1, pub. date: 05/17/2018) discloses in ABSTRACT and ¶¶ [0003]-[0004] that (1) predicts the user's activity on the online system during a future time interval (e.g., the next day); (2) collect activity data, such as actions that the user has taken; (3) predict whether the user is likely to be active during the future time interval based on features extracted from the activity data; (4) determine selection of notifications and delivery of notifications based on the predicted time when the user is likely to be active on the online system; (5) further record the user's past interactions with notifications, such as whether the user viewed the notification, whether the user interacted with a content item associated with the notification, and so on; (6) determine a rate of delivery of notifications to the user based on the frequency of past user interactions with notifications; (7) determines a rate at which notifications are delivered to a user based on a prediction of the likelihood that the user will interact with the notifications; (8) determine a number of notifications to be delivered to the user in a time interval based on information describing past user interactions with notifications, e.g., whether the user viewed the notification, and, if the notification is associated with a content item whether the user interacted with the content item; (9) determine that the user interacts with notifications frequently, increase the rate at which notifications are delivered to the user for the future time interval; (10) if determine that the user interacts with notifications relatively infrequently, decrease the rate at which notifications are delivered to the user for the future time interval; (11) generate a machine learning based model for predicting a likelihood of a user interacting with a candidate notification; e.g., the machine learning model outputs a score indicating a predicted click-through rate for the candidate notification; (12) identify candidate notification having a predicted click-through rate exceeding threshold click-through rate and sends the identified candidate notification to the user; and (13) the machine learning model uses features based on information describing the notification, e.g., a content type for a content item associated with the notification, a user identifier associated with the notification, and so on. Ju further discloses in ¶¶ [0017]-[0063] with FIGS.2A-2B that (1) a user profile includes declarative information about the user that was explicitly shared by the user and may also include profile information inferred by the online system 140; (2) examples of information stored in a user profile include biographic, demographic, and other types of descriptive information, such as work experience, educational history, gender, hobbies or preferences, geographic location, and the like; (3) examples of content represented by an object include a page post, a status update, a photograph, a video, a link, a shared content item, a gaming application achievement, a check-in event at a local business, a brand page, or any other type of content; (4) examples of actions include adding a connection to another user, sending a message to another user, uploading an image, reading a message from another user, viewing content associated with another user, attending an event posted by another user, among others, wherein a number of actions may involve an object and one or more particular users; (5) examples of interactions with objects include: logging on to the online system 140, commenting on posts, sharing links, checking-in to physical locations via a mobile device, posting content items, accessing content items, and any other interactions; (6) additional examples of interactions with objects on the online system 140 that are included in the action log 220 include: commenting on a photo album, communicating with a user, establishing a connection with an object, joining an event to a calendar, joining a group, creating an event, authorizing an application, using an application, expressing a preference for an object ("liking" the object), and engaging in a transaction; (7) data from the action log 220 is used to infer interests or preferences of a user, augmenting the interests included in the user's user profile and allowing a more complete understanding of user preferences; (8) an edge store 225 stores information describing connections between users and other objects on the online system 140 as edges; (9) users may generate edges with other users that parallel the users' real-life relationships, such as friends, co-workers, partners, and so forth; (10) other edges are generated when users interact with objects in the online system 140, such as expressing interest in a page on the online system, sharing a link with other users of the online system, and commenting on posts made by other users of the online system; (11) features included in an edge describe rate of interaction between two users, how recently two users have interacted with each other, the rate or amount of information retrieved by one user about an object, or the number and types of comments posted by a user about an object; (12) a feature may represent the level of interest that a user has in a particular topic, the rate at which the user logs into the online system 140, or information describing demographic information about a user; (13) each feature may be associated with a source object or user, a target object or user, and a feature value; (14) a feature may be specified as an expression based on values describing the source object or user, the target object or user, or interactions between the source object or user and target object or user; (15) hence, an edge may be represented as one or more feature expressions; (16) the edge store 225 also stores information about edges, such as affinity scores for objects, interests, and other users; (17) affinity scores, or "affinities," may be computed by the online system 140 over time to approximate a user's affinity for an object, interest, and other users in the online system 140 based on the actions performed by the user; (18) a user's affinity may be computed by the online system 140 over time to approximate a user's affinity for an object, interest, and other users in the online system 140 based on the actions performed by the user; (19) groups include one or more users and can be associated with particular subject matter; (20) users included in a group are referred to as "members" of the group or "group members"; (21) a user becomes included in a group after the user joins the group, and a single user can join a plurality of groups; (22) the plurality of groups that a particular user has joined is referred to as the "user's groups," "user's associated groups," or "groups connected to the user; (23) groups can be "open," allowing anyone to join, or "closed," requiring a user to request to join or be invited by an existing group member to join; (24) thus, a user is unable to join a "closed" group until addition of the user to the group is approved, for instance by a group manager, and/or the user provides credentials (such as an email address from a particular domain, a password, or the like); (25) a group may have a dedicated page on the online system serving as an information hub that allows group members to communicate with each other; (26) similar to other objects, groups are represented in the social graph by a node; (27) a node representing a user that is a member of the group is connected to the node representing the group by an edge representing the association of the user with the group; (28) the notification module 235 provides notifications to users of the online system 140, wherein a notification is a message that informs a user of an action that has taken place on the online system 140; (29) notifications can be provided for actions that have taken place with respect to content items connected to the user's groups, brand pages, and other pages that can be viewed by the user; e.g., a notification may inform a user that another user has uploaded, expressed a preference for ("liked"), or added a comment to a content item ( e.g., an image, a link, or a text post) on one of the user's groups; (30) identify the highest quality content items and generates candidate notifications describing these content items for sending to users; (31) notifications can also be provided for actions taken on the online system 140 toward objects other than content items; e.g., a notification may inform a user that a connection has been created between two other users (e.g., the two other users have become "friends") or that another user has expressed a preference (e.g., "liked") for a brand page; (32) since actions may include commenting on posts, sharing links, posting content items, accessing content items, commenting on a photo album, establishing a connection with an object, joining an event to a calendar, joining a group, creating an event, expressing a preference for an object ("liking" the object), the notifications provided by the notification module 235 may alert a user to these or any other kinds of actions that users perform on the online system 140; (33) the notification module 235 may perform activity prediction and notification pacing for each user of the online system based on data associated with each user; (34) similarly, the notification module 235 may train and store separate activity models 255 and CTR models 275 for each user of the online system 140.; (35) the activity prediction module 245 receives and stores activity data about a user of the online system 140 and generates a prediction of the user's activity on the online system 140 during a future time interval; (36) the activity data can include any data that has predictive value in determining the user's activity on the online system 140 during a future time interval; (37) the activity data includes a record of the user's actions on the online system 140 as recorded by the action logger 215 and stored in the action log 220; (38) the activity data may also include demographic information about the user, such as the user's age, occupation, gender, and location; (38) after collecting the activity data, the activity prediction module 245 derives features from the activity data; (39) the activity prediction module 245 uses the features to generate a prediction of the user's activity during a future time interval (e.g., the next calendar day); (40) a time interval as used herein refers to a contiguous period of time, e.g., a day, an hour, a week, and so on; (41) the activity module 245 generates the prediction by providing the features as input to the activity model 255; (42) the module 245 generates the prediction using a process, e.g., a rules-based process that assigns a fixed weight to each feature and determines a weighted aggregate value based on the features; (43) the prediction generated by the activity prediction module 245 is a value that quantifies the user's predicted activity during the future time interval; e.g., (a) the prediction may be a Boolean value that represents whether the user will be active at least once during the future time interval (e.g., a value of 1 if the user is predicted to be active at least once during the future time interval and a value of 0 if the user is not predicted to be active during the future time interval); (b) the prediction might be a value indicating a likelihood or probability (e.g., a scalar value between 0 and 1 or a percentage between 0% and 100%) that the user will be active at least once during the future time interval; and (c) the prediction might be a value indicative of a number of times the user is predicted to be active during the future time interval (e.g., a predicted number of actions that the user will perform during the future time interval); (44) the activity learning module 250 applies machine learning techniques to generate an activity model 255 that when applied to a future time interval outputs a prediction of whether a user will be active during the future time interval; (45) as part of the generation of the activity model 255, the activity learning module 250 forms a training set of past time intervals by identifying a training set of past time intervals during which the user was active, and a negative training set of past time intervals during which the user was not active; (46) the activity learning module 250 extracts feature values from past time intervals in the same manner that the activity prediction module 245 derives features for a future time interval, but the activity learning module 250 extracts feature values using the value of activity data at the time of a past time interval; (47) the activity learning module 250 applies dimensionality reduction (e.g., linear discriminant analysis (LDA), principle component analysis (PCA), or the like) to reduce the amount of data in the feature vectors for past time intervals to a smaller, more representative set of data; (48) different machine learning techniques—such as linear support vector machine (linear SVM), boosting for other algorithms (e.g., AdaBoost), neural networks, logistic regression, naive Bayes, memory-based learning, random forests, bagged trees, decision trees, boosted trees, or boosted stumps-may be used; (49) the activity learning module 250 applies the trained activity model 255 to the past time intervals of the validation set to quantify the accuracy of the activity model 255; (50) common metrics include: Precision=TP/(TP+FP) and Recall=TP/(TP+FN), where TP is the number of true positives, FP is the number of false positives, and FN is the number of false negatives; (51) precision is how many past time intervals in the validation set the activity model correctly predicted out of the total it predicted, and recall is how many past time intervals in the validation set the activity model 255 correctly predicted out of the total number of past time intervals during which the user was actually active; (52) a third metric is the F-score: F-score = 2*(precision*recall)/(precision + recall), wherein the F-score unifies precision and recall into a single measure; (53) the activity learning module 250 iteratively retrains the activity model 255 until the occurrence of a stopping condition, such as the accuracy measurement indication that the model 255 is sufficiently accurate (e.g., the precision, recall, or F-score exceed respective threshold values), or a number of training rounds having taken place; (54) the notification pacing module 260 records the user's interactions with notifications that have been sent to the user and uses the interactions to determine the number of notifications to be sent to the user during a future time interval, such as the next calendar day; the notification pacing module 260 generates one or more interaction metrics based on the user's interactions with past notifications and uses the interaction metrics to generate the number of notifications to be sent to the user; (55) the notification selection module 265 identifies a set of candidate notifications, scores the candidate notifications, and uses the scores to select a limited number of notifications to be sent to the user; (56) the module 265 identifies a candidate notification corresponding to every action that has taken place with respect to content items connected to the user's groups, brand pages, and other objects during a trailing time window (e.g., the preceding five days); (57) the module 265 may also identify candidate notifications corresponding to actions that have taken place with respect to content items that are not connected to any of the user's groups, brand pages, or other objects during the trailing time window; e.g., the module may identify a candidate notification for content items that are exceptionally popular on the social network, such as a content item posted on a brand page for well-known public figure that receives an exceptionally large amount (e.g., more than a high threshold value) of interactions from other users; (58) the module may further identify candidate notifications for actions taken on the online system 140 toward objects other than content items, such as the creation of a connection between two other users (e.g., the two other users have become "friends"), or another user expressing a preference (e.g., "liked") for a brand page; (59) the notification selection module 265 identifies candidate notifications for actions taken with respect to content items in "large" groups but not in "small" groups, wherein (a) a large group can be defined as a group having a number of members exceeding a threshold (e.g., 250), and a small group can be defined a group having a number of members below the threshold; (b) the distinction between large groups and small groups can also be based on the activity of the group; e.g., a group can be classified as a large group if the number of content items posted to it over a preceding time period exceeds a threshold number, if the number of interactions that take place with content items posted in the group exceeds a threshold number, or some combination of these and other metrics; (c) the distinction can also be based on a combination of group size (i.e., number of group members) and group activity; and (d) similar rules can also be applied to classify other types of objects that are connected to many users and content items into "large" and "small" objects (e.g., brand pages); (60) the notification delivery module 280 may be configured to automatically send a notification for every content item posted in a small group (or other object), while the notification selection module 265 selects a limited number of notifications from the large groups; (61) selecting and sending notifications in this manner is advantageous because the user is likely to be more interested in content items posted in a small group (where the user is more likely to know the other users who are members of the group), while the scoring process for the candidate notifications causes the notification selection module 265 to select the notifications that the user is most likely to find interesting from among a large number of candidate notifications arising from large groups; (62) the notification selection module 265 scores the candidate notifications with a twostep process: (a) first, the module 265 generates a base score for each candidate notification; e.g., (i) for a candidate notification associated with both an action and a content item, the base score can be based on the number of interactions with the content item associated with the candidate notification, and the module 265 generates the base score by calculating a weighted sum of the number of times users have viewed the content item, expressed a preference ("liked") the content item, added a comment to the content item, and shared the content item; and (ii) for a candidate notification associated with an action but not with a content item, the base score can be based on the affinity score between the user performing the action and the user receiving the selected notifications, or based on the features of the edge between the user performing the action and the user receiving the selected notifications, wherein generating a base score in this manner is advantageous because it has the effect of quantifying how likely the user is to find the candidate notification interesting, and similarly, a user is more likely to find a notification associated with an action interesting if that user had a higher affinity score with the user who performed the action; and (b) second, the notification selection module 265 applies a time decay to the base score to reduce the base score by an amount proportional to the amount of time that has since between the time of the associated action; (63) after generating scores for the candidate notifications, the notification selection module 265 selects one or more candidate notifications based on the scores (e.g., by selecting the one or more notifications with the highest scores); (64) the notification selection module 265 uses the click-through rate (CTR) model 275 to perform a combined process that both determines the number of notifications to be selected and selects the notifications; (65) The notification selection module 265 compares each predicted CTR to a threshold CTR that the module 265 generates based on the user's interactions with past notifications; (66) the module 265 selects one or more candidate notifications that have a predicted CTR that exceeds the threshold CTR; (67) the click-through rate (CTR) learning module 270 applies machine learning techniques to generate a clickthrough rate (CTR) model 275 that when applied to a candidate notification outputs a predicted click-through rate (CTR) for the candidate notification; (68) the notification delivery module 280 receives the selected notifications from the notification selection module 265 and sends the notifications to one or more client devices 110 associated with the user; (69) the notification delivery module 280 sends the notifications to the client devices 110 on a push basis; i.e., a notification originates from the online system 140 without receiving any specific requests for the notification from a client device 110 associated with the user; (70) the notification delivery module 280 sends the notifications as pull notifications, which means the notification delivery module 280 sends the notifications responsive to receiving a request from a client device 110; (71) the notification delivery module 280 sends, on a push basis, an indication that a new notification is available, but the notification delivery module 280 does not send the notification itself; and (72) when the user selects the icon to view the notifications, the client device 110 pulls the notifications from the online system 140. Ju also discloses in ¶¶ [0063]-[0076] with FIGS. 3A-B that (1) the online system 140 collects 305 activity data corresponding to the user; (2) activity data includes demographic information about the user, such as the user's gender, location, ethnicity, languages, financial status, place of employment, and so on; (3) demographic information can also have some value in predicting a user's future activity; e.g., female users may access the online system 140 at a different frequency than male users, users located in urban areas may access the online system 140 more frequently than users located in rural areas, and users who hold white-collar office jobs may access the online system 140 more frequently than users who hold manufacturing or agricultural jobs; (4) the activity prediction module 245 derives 310 features from the activity data, wherein the features include activity metrics which are features derived from user action data, and each activity metric is an integer value representing the number of time intervals (e.g., the number of days) during which the user was active at least once in a preceding time period; (5) the activity prediction module 245 determines for each of the one or more previous sub-intervals, whether the user was active during the sub-interval at least once; (6) the activity prediction module 245 generates an activity metric representing a count of previous sub-intervals during which the user was active at least once; e.g., the preceding time period may be a week and each sub-interval represents a day; (6) in FIG. 3B, three example activity metrics are shown: (a) the length of each time interval is one day, and the first activity metric 360 is associated with a preceding time period of one day; i.e., the first activity metric 360 represents whether the user was active at least once during the preceding day, and here, the user was active five times during the preceding day, so the first activity metric 360 has a value of 1; (b) similarly, the second activity metric 362 is associated with a preceding time period of seven days, so the second activity metric 362 represents the number of days in the preceding seven days during which the user was active at least once, and in the example shown in FIG. 3B, the user was active during five of the preceding seven days, so the second activity metric 362 has a value of five; and (c) finally, the third activity metric 364 is associated with a preceding time period of fourteen days, so the third activity metric 364 represents the number of days in the preceding fourteen days during which the user was active at least once, and in FIG. 3B, the third activity metric 364 has a value of seven; (7) since each activity metric 360, 362, 364 is a separate feature, the activity prediction module 245 combines the activity metrics into a single aggregated activity metric, and the aggregated activity metric is used as a feature, wherein (a) the activity prediction module 245 generates an aggregated activity metric by calculating a weighted sum of multiple activity metrics, with more weight given to activity metrics corresponding to shorter preceding time period, (b) the activity prediction module 245 generates an aggregated activity metric by transforming each individual activity metric into a percentage and extrapolating a trend; and (c) combining multiple activity metrics into an aggregated activity metric is advantageous because it can provide more predictive power than any individual activity metric; (8) the activity prediction module 245 uses the features to generate 315 a prediction of the user's activity during a future time interval; (9) the activity model 255 is a machine learning model trained by the activity learning module 250 using features extracted from activity data for past time intervals; (10) the prediction generated by the activity prediction module 245 may be a score represented as a scalar value; (11) in FIG. 3B, the prediction 268 is a measure of a likelihood or a probability that the user will be active at least once during the future time interval; and (12) the prediction may be a score representing the amount of activity the user is predicted to engage in during the future time interval; (13) the prediction is a binary value (e.g., a value of 1 if the user is predicted to be active during the future time interval and a value of 0 if the user is not predicted to be active); (14) if the prediction indicates that the user is likely to be active during the future time interval ( e.g., if the prediction exceeds a threshold value, or if the prediction has a binary value of 1 ), then the notification selection module 265 selects one or more notifications for the notification delivery module 280 to send 320 to the user prior to the future time interval. Ju further teaches in ¶¶ [0077]-[0091] with FIGS. 4A-B that (1) the online system 140 records 405 the user's interactions with notifications that were previously provided to the user; (2) the notification pacing module 260 generates 410 interaction metrics based on the recorded interactions; (3) interaction metrics, as referred to herein, are metrics that quantify the degree to which the user interacted with previous notifications; e.g., interaction metrics may include the percentage of notifications that a user viewed, the percentage of notifications for which the user viewed the associated action and/or content item, and the percentage of notifications for which the user performed an interaction with the associated content item; (3) an interaction metric may also be an interaction score that combines two or more types of interactions with associated content items; e.g., an interaction metric may be a weighted sum of the number of times the user viewed an associated content item, the number of times the user expressed a preference for ("liked") an associated content item, the number of times the user added a comment to an associated content item, and the number of times the user shared an associated content item; (4) the notification pacing module 260 uses the interaction metrics to generate 415 the number of notifications to send to the user prior to or during a future time interval (e.g., the following day); e.g., the notification pacing module 260 generates the number of notifications to send by combining the interaction metrics with a weighted sum to generate an aggregate interaction score and then maps the aggregate interaction score to an integer number of notifications; (5) the notification pacing module 260 enforces a hard limit on the generated number of notifications; i.e., the notification pacing module 260 does not generate a number of notifications that exceeds the notification limit; (6) the notification pacing module 260 adjusts the notification limit on a user-by-user basis so that users who interact more frequently with their notifications (e.g., as measured by the interaction metrics) or who are more active on the online system ( e.g., as measured by activity data collected by the activity prediction module 245) are assigned a higher notification limit; (7) if the notification pacing module 260 determines that at least one notification is to be sent to the user, the notification selection module 265 selects the determined number of notifications and the notification delivery module 280 sends 420 the notifications to the user either prior to or during the future time interval; (8) the notification selection module 265 generates candidate notifications 452; (9) for each candidate notification, the module 265 extracts one or more features from the notification to generate a feature vector and applies 454 the click-through rate model 270 to the feature vector to generate a predicted click-through rate 456 for the candidate notification; (10) features can be a value representing a content type (e.g., photo, link, text post) for the content item associated with the notification, the object or entity (e.g., group, brand page, user profile) to which the content item is posted, and the user taking the action associated with the notification (e.g., the affinity score between the user taking the action and the user receiving the notification may be used as a feature); (11) after generating the predicted CTR 456 for each candidate notification, the notification selection module 265 compares each predicted CTR 456 to a threshold CTR 460 associated with the user; (12) the notification selection module 265 then selects 458 one or more candidate notifications having a predicted CTR 456 that exceeds the threshold CTR 460; (12) if the number of candidate notifications 452 with predicted CTRs 456 exceeding the threshold CTR 460 is less than or equal to the notification limit, then the notification selection module 265 selects every candidate notification 452 whose predicted CTR 456 exceeds the threshold; (13) however, if the number of candidate notifications 452 with predicted CTRs 456 exceeding the threshold CTR 460 is greater than the notification limit, then the notification selection module 265 selects a number of notifications equal to the notification limit (e.g., by selecting the notifications with the highest predicted CTRs 456); (14) the notification selection module 265 generates 464 the threshold CTR 460 based on the user's interactions with past notifications 462; (15) the threshold CTR 460 may be calculated for notifications delivered to the user during a trailing time window (e.g., the preceding month), or it may be calculated over the entire history of the user's account on the online system 140; and (16) after the notification module 265 has selected 458 one or more notifications, the notification delivery module 280 sends 468 the selected notifications 466 to the user either prior to or during the future time interval so that they can be viewed by the user during the future time interval.
Kumar et al. (US 2014/0136951 A1, pub. date: 05/15/2014) discloses in ABSTRACT that (1) providing users with page previews during page loading events, such that the delay experienced before the display of page content is reduced; (2) the previews may include screenshots of the pages or of portions thereof, and may be generated periodically and cached by the system for delivery to user devices; (3) the process of generating and delivering the previews via the Internet or some other network may be implemented partly or wholly within an intermediary system that sits logically between the user devices and content servers; and (4) the process may be used with existing browsers without the need for any browser modifications, or may be used with a "preview-aware" browser that includes special program code for providing page previews. Kumar further discloses in ¶¶ [0017]-[0023] with FIG. 1 that (1) the intermediary system 30 may, for example, be or act as a proxy server, a partial rendering engine for specific browsers or device types, a CDN, an Internet Service Provider ("ISP") system, or a combination thereof; (2) the page prefetcher 40 is responsible for prefetching pages from various content sites 34 for purposes of generating page previews; (3) the pages that are prefetched may, e.g., be (a) pre-selected by administrators, (b) selected automatically based on page popularity data (as measured, e.g., based on page requests processed by the intermediary system), and/or (c) identified by predictively following links of pages being loaded by user devices; (4) for some or all of the pages selected for prefetching, the page prefetcher 40 may prefetch each page periodically at a regular interval, such as every 1 to 3 minutes, wherein this interval may be fixed, or may vary on a per-page or per-site basis based, e.g., on a measure of how frequently meaningful changes are made to the page or site content; (5) each time a page is prefetched, the preview generator 42 generates a preview of the prefetched page, and stores the preview in the cache 44 in place of the most recently generated preview; (6) the preview generator may generate and cache multiple previews of the same page, with each being tailored to a particular device or device characteristic (e.g., screen size, browser characteristics, touch screen versus non-touch screen, etc.); (7) the previews may include or consist of screenshots of the prefetched pages or portions thereof; (8) the previews may also include HTML code, including HTML image maps that enable users to select links depicted in the screenshots and access the linked content; (8) rather than generating a preview of a prefetched content page, the preview generator 42 may obtain a preview (e.g., an image or interstitial page) identified by the content site 34 as the desired preview for a content page from that content site 34; e.g., the current or full version of the content page may include meta data, custom markup tags, or other information that identifies the preview item that is to be used for the page, and the preview generator can obtain that preview item; (9) the preview item may be obtained proactively and stored in the preview cache 44 (e.g., prior to receiving a request for the content item from a user device 32), or reactively ( e.g., in response to a request, from a user device 32, for the content page); (10) configuration data to control the process of prefetching pages and generating page previews may include, e.g., a list of the sites or pages that are eligible for prefetching, data regarding prefetch intervals to be used for particular pages or sites, and data regarding the devices or device characteristics for which previews are to be generated; (11) using a page prefetcher 40, the intermediary system 30 may generate the previews from page content retrieved by the intermediary system 30 on behalf of the user devices; (12) the intermediary system 30 may include a content fetcher or request processor that retrieves requested content items on behalf of user devices 32 and provides non-preview versions to the user devices 32; (13) the intermediary system 30 may include a rendering engine or some other component with browser functionality to process retrieved content items and send processed versions to a user device 32; and (14) the intermediary system 30 may render preview content and non-preview versions of requested content, and transmit representations of the rendered content to the user device 32 for display such that little or no content processing is done on the user device 32. Kumar also discloses in ¶¶ [0024]-[0040] with FIG. 2 that (1) in event 1, the intermediary system 30 prefetches a page from a content site 34; (2) this prefetch event may occur according to a periodic schedule, or may be performed predictively based on another page requested by the user device 32; (3) the intermediary system 30 may be configured to service content requests from multiple user devices, and in such cases, the intermediary system 30 may obtain content and generate previews of the content in response to requests from a first user device, and then provide those previews to a second user device 32 at a subsequent time; (4) if retrieval of content and generation of previews is performed predictively, the intermediary system 30 may send a cookie corresponding to the user device 32 and content site 34 with the page request, and . In this way, the content site 34 may return a page that is personalized for the particular user, and a screenshot of the personalized page may be generated; (5) in event 2, the intermediary system 30 generates and caches a preview of the page, wherein if the page was prefetched without use of a cookie corresponding to the user device 32, the intermediary system 30 may subsequently deliver this preview to any user device that subsequently requests the page, and if prefetched using a cookie, the preview may be designated as being personal to the user device 32, or to a user or user account associated with the user device 32; (6) when generating the preview, the intermediary system 30 may generate a screenshot of the entire page, or may generate multiple screenshots, each of a different respective portion of the page; (7) to preserve active content (links and other selectable elements) on the page, the preview generator may also generate an image map for each screenshot; (8) each such image map specifies the coordinates within the screenshot of one or more hot spots, and specifies the target URL of each such hot spot; (9) to reduce the complexity of the image maps, the intermediary system 30 may, in some cases, only include hot spots of some of the links on the page, such as those that are selected the most frequently by users; (10) the intermediary system may, in generating a page preview, store some or all of the page's text in a non-image format; e.g., the intermediary system 30 may create a text overlay file that can be combined by the browser 50 with an image file to produce the page preview; (11) the intermediary system 30 may generate executable code or customized representations of content to facilitate the use of interactive controls and other objects while a preview is displayed; (12) a user may therefore be provided with some degree of interactivity, even though a substantially static preview is being displayed rather than a fully functional non-preview version of the requested content; (13) in event 3, the user device 32 subsequently requests the page; (14) in events 4 and 5, which may overlap in time (e.g., may be performed in parallel) or be performed in a different order than shown, the intermediary system 30 responds to the page request by (a) returning the cached page preview to the user device 32, and (b) retrieving the requested page from the content site 34 on behalf of the user device 32; (15) the process used to deliver the preview in event 4 may depend on whether the device's browser 50 supports the display of page previews; (16) if it does not, as in the case of a conventional browser, the intermediary system 30 may first return a special HTML file, referred to herein as an HTML preview file, that instructs the browser 50 to retrieve one or more cached screenshots (or other cached preview objects) from the intermediary system 30; (17) in event 6, which may overlap with event 5 and/or event 7, the browser 50 displays the page preview; (18) typically, the page preview is displayed noticeably faster than the actual page would be displayed if no previews were delivered; (19) there are a several reasons for this: (a) first, because the preview is already cached on the intermediary system 30, the round trip delay associated with retrieving the page from the content site 34 is avoided; (b)second, the additional round-trip delays associated with requesting any embedded objects from the content server 34 or a third party server (e.g., a CDN server) are typically avoided; and (c) third, depending upon the process used to generate the preview, the preview may be capable of being delivered and displayed more rapidly than the actual page; e.g., complex coding that ordinarily results in a browser 50 processing delay may be omitted from the preview, allowing it to be displayed more rapidly upon its arrival; (20) the speed at which the preview is delivered and displayed can be further increased by optimizing the previews for specific device types or form factors; (21) the intermediary system 30 may only deliver the above-the-fold screenshot, such that no below-the-fold content is included in the preview, which may be suitable or desirable where the user is unlikely to scroll down on the page during the preview-display stage; (22) the intermediary system 30 may determine whether to use this approach for a particular page based on one or more factors, such as (a) data regarding how frequently (and how quickly) users scroll down on the particular page, and (b) the estimated amount of time the preview will be displayed before it is replaced with the actual page; (23) in event 7, the intermediary system 30 delivers to the browser a non-preview version of the page based on the page content retrieved in event 5, wherein a non-preview version of the page may be a substantially current version of the page retrieved from the content site 34; (23) the intermediary system 30 may perform an analysis of differences between the substantially current version of the page and the preview version that was previously provided to the client device 32; (24) representations of differences between the substantially current version and the preview version may then be provided to the client device 32; e.g., one or more preview updates, such as replacement text, replacement images or portions of images, replacement byte ranges, and the like may be generated and sent to the client device 32; (25) the browser 50 can then display a non-preview version by applying the preview update(s) to the preview version, replacing one or more portions of the preview version with the preview update(s), overlaying the preview update(s) on the corresponding portion(s) of the preview version, etc.; (26) the non-preview version may be identical in format to the page retrieved in event 5, or may be a modified or partial version of it; (27) the intermediary system 30 may modify or optimize the retrieved page in various ways to generate the non-preview version; e.g., (a) the intermediary system 30 may reduce the resolutions of selected images on the page to enable them to load faster, especially for mobile devices; (b) the intermediary system 30 may generate and deliver a single file that fully represents the entire page, including embedded images or objects that would ordinarily be separately retrieved by the browser; and (c) the intermediary system 30 may only deliver certain portions of the page, such as portions that differ or were omitted from the preview; (28) thus, the non-preview version delivered in event 7 may differ in format from the page retrieved in event 5, and/or may be an incomplete representation of the actual page; (29) the non-preview version of the requested content may be delivered without a second request or follow-up request from the browser 50; (30) the network system may transmit content items and other data to the user device without first requiring a request from the user device; (31) as the non-preview version is loaded on the user device 32, it is maintained hidden by the browser; e.g., the non-preview version may be loaded into a separate frame buffer, or it may be rendered into a hidden "tab," browser window, or other content display element supported by the browser 50; (32) events 5 and 7 in FIG. 2 may overlap, such that the intermediary system 30 delivers portions of the non-preview version of the page while retrieving other portions; (33) the intermediary system 30 may only deliver certain portions of the actual page, such as those portions that differ (or differ meaningfully) from the preview; (34) in event 8, the browser 50 replaces the display of the preview with a display of the non-preview version based on the content received in event 7 (if the intermediary system 30 only delivers the portions that differ from the preview, the browser 50 may alternatively update the preview by replacing the relevant portions); e.g., if the non-preview version was loaded and rendered into a hidden tab, the hidden tab may be un-hidden or otherwise made visible, while the tab in which the preview was displayed may be hidden; (35) from the user's perspective, the transition from the preview to the actual (non-preview) page is typically similar in appearance to the transition that occurs when a conventional browser finishes loading a page, and thus, the user typically will not be aware that a transition from a preview to the actual page is occurring; (36) the intermediary system 30 generates previews of the page on a frequent basis (e.g., every few minutes); (37) the preview may include interactive objects, such as text boxes or other input controls, and users may interact with such objects prior to event 7 or 8; e.g., including a text box can allow a user to begin entering text in the text box; (38) when the user device 32 replaces the preview with the non-preview version in event 8, the user device 32 can copy the contents of the temporary preview version of the text box to the non-preview version so that the user does not lose any work, and so that the change to the non-preview appears to occur seamlessly or substantially seamlessly; (39) if the user is actively entering text in the text box, the user device 32 may direct input to the non-preview version of the text box when it is ready, and automatically place the cursor in the proper location of the non-preview version of the text box when it is displayed; (40) a preview-aware browser 50 may be configured to automatically copy the input from the preview version to the non-preview version prior to or during display of the non-preview version, such that it does so without any additional instructions or code from the intermediary system 30; (41) the intermediary system 30 may programmatically determine, at the time of a page request, whether to deliver a preview of the requested page; (42) tis determination may be based on a variety of factors, such as one or more of the following: (a) the connection speed between the user device 32 and the intermediary system 30, or between the content site 34 and the intermediary system 30, (b) the size and complexity of the requested page, as may be known to the intermediary system 30 based on previous accesses to the page, (c) the average delay (or most recent delay) encountered by the intermediary system 30 when retrieving this page, or when retrieving pages of the target site generally, and (d) the frequency with which the content of the page changes.
Huang et al. (US 11,049,133 B1, date of patent: 06/29/2021) discloses in ABSTRACT that (1) automated server-based content delivery; (2) determining campaign information for a content delivery campaign, the campaign information comprising a first allocation value for first content, and a second allocation value for second content; (3) determining first observed data comprising a first user response rate for the first content and a second user response rate for the second content; (4) determining an exponentiated gradient algorithm for the content delivery campaign; and (5) determining a reallocation amount to reallocate a portion of the first allocation value to the second allocation value using the exponentiated gradient algorithm based at least in part on the first observed data, wherein the reallocation amount maximizes an output of the exponentiated gradient algorithm. Huang further disclose in Col. 1, line 64 – Col. 4, line 56 that (1) content creators or content providers may desire to deliver content to particular users, types or groups of users, or other targeted users; (2) content creators or content providers may also desire to deliver certain content within a particular period or length of time; (3) to initiate delivery of content associated with a content campaign, target consumers, targeting criteria, flight time, and other content delivery parameters may be set; e.g., a campaign manager may manually set one or more content delivery parameters that may be used to deliver content over the course of a campaign; (4) in generating content for delivery, content creators or content providers may desire a particular user response or user interaction in response to consuming the content; e.g., a content creator may desire a user response or user interaction of reading or writing product reviews after consuming content, or another desired user response or user interaction; (5) due to the costs associated with content delivery, content creators or content providers may provide guidelines or delivery constraints on delivery of content to users; (6) delivery of content may be affected by a number of different parameters, such as cost of delivery, length of flight time of content, constraints on delivery (e.g., targeting constraints for users, etc.), distribution channels, and other parameters; (7) each parameter, however, may affect user interaction and/or a rate of user interaction; (8) determine budget allocation values that optimize objective functions of interest subject to one or more constraints being satisfied; e.g., a budget allocation constraint may indicate that mobile onside content cannot be assigned a budget greater than 60% of a total budget allocated to mobile content; (9) content creators may have certain goals for content, such as a goal of maximum user interaction, a goal of maximum user reach, or another goal; (10) accordingly, content creators or content providers may desire to maximize user interaction in response to consumption of content created, or otherwise provided, by the content creator or content provider; (11) further, over the course of a campaign, certain modifications or adjustments to one or more campaign content delivery parameters may result in increased user interaction; e.g., a certain distribution channel, such as mobile device content delivery, may be more effective at engaging users than another distribution channel, such as television content delivery; (12) manage a content delivery strategy for a content campaign, including automatically managing content delivery parameters such as budget allocation, frequency cap values, base bid values, and other parameters; (13) in the context of online content delivery, content may be delivered for presentation (e.g., rendering) in an available content slot; (14) presentation of the content in an available content slot may be referred to as serving an impression; (15) the terms "content slot" or "available content slot" may refer generally to a location, environment, or placeholder in which, or in connection with which, an impression of content may be served; (16) in a more specific context, these terms may refer to, e.g., a particular location on a web page or within an application at which an impression of content may be presented to and potentially consumed by a user; (17) a content campaign may be directed toward a target consumer, which may be a consumer within a certain demographic or certain geography, a consumer that has certain attributes (e.g., recent purchases or browsing history, etc.), a consumer that has specific preferences or characteristics, or other targeting criteria; (18) delivery of content to consumers may be affected by a number of parameters, including, e.g., a budget for delivery of the content, a frequency cap associated with the content campaign, and other parameters; (19) a total budget for content delivery may be allocated across one or more pieces of content associated with a content campaign, as well as across any number of distribution channels; (20) provide a framework for the application of data sciences and machine learning to inform, automate, and standardize decision making across content delivery processes; (21) certain aspects of content delivery campaigns may be automated to increase campaign performance, reduce manual management (e.g., campaign manager involvement), and reduce variability in outcomes; (22) optimization levers that are most frequently adjusted by campaign managers, as determined based at least in part on historical data, may be automatically tuned over a flight time of a campaign, so as to optimize user interaction with content associated with the campaign; e.g., budget allocations may be adjusted so as to shift budget from relatively lower performing content to relatively higher performing content and/or distribution channels, or specific sites may be targeted; (23) other content delivery parameters, such as frequency caps or based bids, may also be automatically adjusted; (24) content creators or content providers may desire to achieve maximum effectiveness of a content campaign; (25) effectiveness of a content campaign may be determined, e.g., by content campaign goals (e.g., a number of desired user interactions, such as purchases, click-throughs, new customer acquisition, increase in sales, certain click rates, etc.) and/or by determining whether a consumer presented with the content reacts in a desired manner (e.g., clicks on the content, buys the product, etc.); (26) campaign performance may also be measured or determined based on a return on content delivery budget (e.g., a ratio of user interactions attributed to presentation of the content to users to the content delivery budget, etc.), or by an on schedule indicator (e.g., ratio of budget consumed to expected budget consumed with a linear delivery profile, etc.); (27) to accomplish the goals of the content campaign, content creators or content providers may desire to spend a total budget allocated for the content campaign in a manner so as to maximize desired user interaction; (28) in certain instances, campaign goals may change over the flight time of a content campaign; e.g.. an initial goal of performance may change to a goal of delivery towards the end of a campaign, and account for changes in campaign goals by maximizing a current goal of the content campaign; (29) content delivery may be impacted by a number of parameters; e.g., the bid price may be a function of a base bid value, which may be a component of a bid calculated in real-time during an auction, a maximum bid value, which may be a multiple of a base bid, or other parameters, such as a frequency cap or a delivery pacing metric may be used to determine a bid; e.g., a frequency cap parameter may be set to a certain value, wherein the frequency cap may represent a maximum number of times a particular user may be presented with particular content in a time interval; (30) content campaign performance or effectiveness, as determined by quantifiable desired user interactions, may be increased or otherwise increased by manipulation of one or more factors or parameters used in a function or model that determines bid values for auctions to present the content; (31) optimize or maximize function output, or campaign performance, by manipulation of one or more parameters used in a function particular to a piece of content or a particular content campaign; e.g., (a) adjust budget allocation and/or adjust a base bid value or a frequency cap value to change a number of auctions won, or to improve a quality of auctions won; and (b) a frequency cap may be adjusted so as to funnel users through a sales funnel that may otherwise not move through the sales funnel due to insufficient contact between a content campaign and a user; (32) optimize parameter values or settings over the flight time, or a length of time a content campaign is active, of a content campaign by generating recommendations for parameter adjustments; (33) recommendations may be generated periodically; (34) to generate recommendations, analyze observed data, or actual data collected on user behavior or reactions to content, as well as content campaign performance, wherein the observed data may be used to generate a predictive model, and adjustments to one or more parameters in the predictive model may be tested to determine which adjustments, if any, are most likely to increase performance of the content campaign; (35) an iterative process may be completed until parameter settings converge to optimal settings and campaign performance is optimized; (36) for certain delivery parameters, such as budget allocation, optimal values may change over time, and thus, rather than reaching or converging to an optimal value, an ongoing iterative process may be performed as observed data becomes available so as to continually update and/or track an evolving set of parameters; (37) solicit basic attributes of a campaign including flight dates, product categories, campaign strategy (e.g., awareness vs. purchase), information about potential target audiences, and budget; and (38) once live campaign data is available, continuously reevaluate the previously generated recommendations and generate additional recommendations when a better strategy is identified; e.g., if one channel outperforms expectations, a recommendation to shift budget to the more effective channel may be generated.
Li et al. ("Predictive Edge Caching through Deep Mining of Sequential Patterns in User Content Retrievals", ARXIV ID: 2210.02657, Oct. 6, 2022, pp. 1-14) discloses in ABSTRACT of Page 1 that (1) edge caching plays an increasingly important role in boosting user content retrieval performance while reducing redundant network traffic; (2) at the network edge, content popularity can be extremely dynamic due to diverse user content retrieval behaviors and the low-degree of user multiplexing, and it’s challenging for the traditional reactive caching systems to keep up with the dynamic content popularity patterns; (3) propose a novel Predictive Edge Caching (PEC) system that predicts the future content popularity using fine-grained learning models that mine sequential patterns in user content retrieval behaviors, and opportunistically prefetches contents predicted to be popular in the near future using idle network bandwidth; (4) through extensive experiments driven by real content retrieval traces, demonstrate that PEC can adapt to highly dynamic content popularity at network edge, and significantly improve cache hit ratio and reduce user content retrieval latency over the state-of-art caching policies; (5) more broadly, the study demonstrates that edge caching performance can be boosted by deep mining of user content retrieval behaviors. Li further discloses in Section 1 with FIG. 1 of Pages 1-2 that (1) edge caching is a promising solution to simultaneously reduce user content retrieval latency and mitigate traffic congestion in core networks; (2) the key to achieve high caching gain is to accurately predict the content popularity in the near future; (3) compared with the traditional CDN servers, each edge cache node is equipped with smaller storage and serves a smaller user group, and as a result, the aggregate content popularity of users served by an edge cache node is less stationary, and more difficult to be accurately estimated by simple aggregate statistics of the past requests; (4) proactive caching enjoys the freedom of prefetching any content at any time with additional bandwidth cost; (5) content popularity estimation is critical for efficient proactive caching; (6) [34] gives the theoretically upper bound for proactive caching when content popularity is stationary; (6) periodical proactive cache updates, e.g. [26], can cope with non-stationary content popularity, and however, it cannot adapt to the content popularity variations between two updates; (7) propose a novel Predictive Edge Caching (PEC) system that predicts the future content popularity using fine-grained learning models that mine sequential patterns in user content retrieval behaviors, and opportunistically pre-fetches contents predicted to be popular in the near future to improve cache hit ratio and reduce content retrieval latency; (9) to address the diverse user content interests and content consumption behaviors, instead of using the aggregate content request statistics of all users, mine each individual user’s content request history and predict when and which content each user is likely to request the next using sequential machine learning models, and then aggregate the next-content predictions of all users to generate predictive caching scores reflecting the future content popularity; (10) contents predicted to be popular will be proactively prefetched into cache in the background using spare network bandwidth; (11) to closely keep track of dynamic content popularity, per-user next-content predictions, predictive caching score updates, and proactive content prefetches are all conducted in real-time; (12) the high-level structure of PEC is illustrated in Figure 1, and within this novel predictive edge caching framework, make the following contributions: (a) develop machine learning models to mine the user sequential viewing patterns, which show that n-gram and self-attention sequential models have complementary performance, and can be easily combined to generate accurate fusion prediction with use of simple, yet robust, statistical methods to predict the arrival time of the next request; (b) to guide online prefetching, develop models to aggregate per-user content request predictions into per-content predictive caching scores, and update them continuously as posterior probabilities over time; (c) design a hybrid caching system that prefetches contents with high predictive scores into the proactive portion and caches popular contents missed by the predictions into the reactive portion, wherein the sizes of the two portions are dynamically adjusted, and the content replacements in the two portions are orchestrated to maximize the caching gain; (d) develop a three-level strategy that controls the bandwidth consumption of proactive downloading to minimize its negative impact on the regular traffic; and (e) through extensive edge caching simulations driven by real-world data traces, demonstrate that, compared with the state-of-art reactive and the traditional periodical proactive caching policies, PEC can significantly improve the cache hit ratio and reduce user content retrieval latency with controlled bandwidth overhead. Li also discloses in Section 3 with FIGS. 2-5 of Pages 3-5 that (1) estimate the short-term content popularity on an edge cache node by predicting the next content that will be requested by each user served by the edge cache; (2) given the past content requests generated by user D, the model predicts a) which content user D will request next b) when the next request will be generated; (3) how a user sequentially consumes contents is highly dependent on the type of contents; (4) develop learning-based sequential models for the next-content prediction using n-gram model; (5) sequential models are widely used in Natural Language Processing; (6) adopt the simple, yet powerful, n-gram model to solve the problem, and more specifically, by assuming the next content only depends on the previous n − 1 contents, the probability of the next content can be estimated by the conditional probability; (7) empirical conditional probability is derived from the history data; (8) an illustration of 3-gram is shown in Fig.2; (9) caching is highly time-sensitive. not only need to place popular contents in the cache, but also should do it at the ‘right’ time; (9) other than the watched contents, the time a user spent on each content also tells a lot about the user’s content preference and watching habit; e.g., if a user often skips to another video within 10 minutes, it makes more sense to predict she will watch a short video instead of a long movie next; (10) to accurately predict the next content, it should not only consider the user’s past content sequence, but also the timestamps of those contents; (11) develop a customized time-aware self-attention sequential (TSAS) model for next-content prediction; (12) convert each user’s content request history into sequences of length n; (13) train a self-attention model using length-n sequences from all users; (14) as illustrated in Figure 3, to learn the self-attention weights, embed contents using an embedding matrix, where d is the dimension of the latent embedding space; (15) a content embedding vector is projected to the corresponding Key, Query and Value vectors using learnable projection matrices respectively; (16) all the time intervals are quantized and capped to be integers within [0, k], and then embedded using two matrices, one for Key, and the other for Value; (17) summarize the context of the first i − 1 requests as a weighted sum of the embedding value vectors of the requested contents and the time intervals between requests; (18) add non-linearity by feeding the output of the self-attention layer to a point-wise Feed-Forward Network (FFN) with dropout and layer normalization; (18) finally, the probability of content c for the i-th request is predicted as eqn. (3); (19) to combine the short-range and long-range sequential patterns captured by the n-gram and TSAS models, generate final prediction using model fusion; (20) combSum fusion achieved the best performance and it has ranking scores for the final output, which can be used as content caching scores; (21) the diagram of the fusion prediction system is shown in Fig. 4, and specifically, generate two top-n lists from the n-gram and TSAS models; (22) the two lists are merged, and for each candidate content c in the merged list, normalize its n-gram and TSAS scores from (1) and (3) using max-min normalization, respectively; (23) then rank all the contents based on their combined normalized scores, and put the top n contents into the fused top-n list; (24) the weight for each content is simply its combined normalized score shown in eqn. (4); (25) for the purpose of caching, other than predicting the next content, it is also important to predict when u will request the next content; (26) a user’s activities follow on-off pattern; (27) when a user is actively watching videos, after finishing content, she will generate the next content request, and so the next-request arrival time is simply adding the random variable of the time duration that D will watch the current content; (28) meanwhile, if the user leaves the video watching session after finishing the content, the next request will be generated when she becomes active again, then addition gap is the length of the user’s off-period, wherein the off-periods are very random, depending on lots of other factors outside of video watching; (29) the length of an off-period can be easily hours or even days, much longer than the time-scale of edge caching; (30) meanwhile, a user typically watches multiple videos within each on-period, so the inter-arrivals between adjacent requests in the complete trace are dominated by the inter-arrivals between two adjacent requests within the same on-period; (31) focus on predicting the interval till the next request within the same on-period; (32) if the next request does not arrive beyond the predicted arrival range, cancel the prediction and wait for the user to become active again; and (33) the next content and arrival time prediction with on-off pattern is illustrated in Fig.5. Li further teaches in Section 4 with FIGS. 6-7 of Pages 5-8 that (1) as soon as predicting the next content and its arrival range, assign predictive caching scores to quantify its potential caching gain, and this score should be time-sensitive; (2) if the predicted arrival range is still ahead, it is not immediately urgent to cache the content; (3) if the estimated lower bound for arrival has passed, but the midpoint of the range is still ahead, it becomes urgent to cache the content, update the uniform prior distribution and assign a predictive caching score proportional to the posterior density function; (4) if the time has passed the midpoint of the estimate range, gradually reduce the confidence about the predicted arrival; (5) the posterior density is not updated any more, and a fixed predictive score of 2is used, which is the posterior density when t reaches the midpoint, until the predicted arrival upper bound beyond which the prediction is concluded wrong, and the predictive caching score for the predicted content is set back to zero; (6) an example of score update is illustrated in Fig. 6, and meanwhile, whenever u requests a new content, generate a new prediction based on the newly requested content, the predictive caching score for the previously predicted content from u will be reset, and caching score for the newly predicted content will be calculated according to eqn. (5); (7) at any given time t, for each user in a set of active users, based on her most recent content request sequence, generate the top-n list of contents that u is mostly likely to request the next using the fusion model; (8) each content c in the top-n list has a prediction weight from eqn. (4); (9) the total weighted predictive caching score for any content in the combined top-n list of all the active users can be calculated as eqn. (6); (10) an user-content scores aggregation example is shown in Fig. 7, and if a content shows up in multiple users’ top-n lists, but the expected arrival range has not arrived yet, according to (5), the content still get zero predictive score; (11) to distinguish such a content from a content not showing up in any user’s top-n list, give them the second class caching priority, and use its nearest predicted arrival time as the secondary predictive caching score in eqn. (7), wherein the secondary caching score decreases with the shortest time interval till the expected arrival of any active user, following the Farthest-In-Future (FIF) caching replacement policy; (12) if the contents that are in the top-n next-content lists are not currently in the cache, one can proactively download them into the cache so that they can be directly served from the cache if they are indeed requested by a user so the predictive caching scores are the most suited for proactive caching to achieve high hit ratio and low latency; (13) meanwhile, we cannot solely depend on predictive scores to manage the whole cache because (a) first, our prediction models are designed for active users and active items, and the predictive scores are time-varying, and ss a result, at any time, only a portion of contents that are recently active have predictive scores, and sometimes they cannot even fill up the cache, such as during early morning; and (b) secondly, the sequential prediction models work on the per-user basis, and are not designed to capture the content interest similarity cross users; (14) need to resort to the conventional reactive caching algorithms to take advantage of the homogeneity of content interests of a user group; (15) present PEC, a hybrid caching system, that takes advantage of the complementary prediction power of predictive and reactive caching scores; (16) PEC partitions the cache into two portions, proactive portion and reactive portion, wherein the proactive portion is used to prefetch contents with high predictive caching scores, while the reactive portion stores contents without predictive scores and is updated reactively using any reactive caching algorithm; (17) Algorithm1 describes how our hybrid caching algorithm processes each new requested content c by user u at time t; (18) if c is either in the proactive or the reactive portion, it will be directly served from the cache and counted as a new cache hit, and otherwise, c will be downloaded from the server and stored in the reactive portion; (19) if the reactive portion is full, the content with the lowest reactive caching score, such as the LRU2 score, will be evicted from the reactive portion; (20) Since u has just generated a new content request, the top-n next-content list generated when u requested the previous content at t′ expires, and all predictive caching scores calculated for c will be reset; (21) then generate a new top-n list using the fusion model as the most recent content request, and update the predictive caching scores of all contents in the new list according to eqns. (5), (6) and (7); (22) algorithm 2 describes how the predictive caching scores are updated periodically over time, and how the proactive portion is refreshed through prefetching; (23) periodically update the predictive caching scores of all content in the top-n lists of all active users according to eqns. (5), (6) and (7); (24) whenever there is a chance for prefetching, prefetch the content with the highest scores but not in the cache (proactive nor reaction portion) into the proactive portion; (25) if needed, the content with the lowest score will be evicted from the proactive portion; (26) in PEC, the predictive scores are time-varying, the number of contents with predictive scores can be dynamic, and thus to avoid assigning too much storage for proactive caching when there are only a small number of contents can be prefetched, impose the dynamic partitioning mechanism; and (27) although proactive caching gives us more freedom to update the cache and boosts the caching performance by predicting the content popularity in the near future, it consumes extra bandwidth to prefetch content, and thus propose a three-level bandwidth overhead controlling strategy: (a) firstly, prefetching is only conducted in the background, and whenever a missed content is being downloaded from the server, the prefetching is banned; i.e., prefetching only utilizes idle bandwidth to improve caching performance without interfering with the regular content downloads; (b) secondly, after each user content request, if the link becomes idle, allow at most one content prefetching to control prefetching traffic; and (c) thirdly, to further limit the bandwidth overhead, introduce prefetching gap to limit the prefetching frequency, wherein prefetching gap is the minimum number of user content requests between two prefetchings; e.g., if K = 3, it means a new prefetching is allowed only after three new user content requests.
However, closest arts of records, as discussed above, singly or in combination
do not teach or suggest at least following features "determining a delivery interval for a content update provided to a user, wherein determining the delivery interval comprises: defining a plurality of delivery interval dimensions, each delivery interval dimension comprising a unique combination of one time cohort of two or more time cohorts and one user cohort of two or more user cohorts; determining a time cohort and a user cohort for the user; and selecting a predetermined delivery interval for one of the plurality of delivery interval dimensions matching the time cohort and the user cohort of the user as the delivery interval; determining a delivery content for the content update provided to the user, wherein determining the delivery content comprises: training a classification model to predict whether content will result in an impression; inputting, into the classification model, the content update; receiving, as output from the classification model, an impression score for the content update; and selecting one of a full update and a partial update as the delivery content from the impression score; and pushing the content update comprising the delivery content to a client device of the user at a frequency defined by the delivery interval" when combining with all other limitations of the claim as a whole.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HWEI-MIN LU whose telephone number is (313)446-4913. The examiner can normally be reached Mon - Fri: 9:00 AM - 6:00 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mariela D. Reyes can be reached at (571) 270-1006. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HWEI-MIN LU/Primary Examiner, Art Unit 2142