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 .
Response to Amendment
The Amendment filed 05/05/2026 has been entered. Claims 4, 10, and 17 have been canceled. Claims 1-3, 5-9, 11-16, and 18-20 are pending in the present Office Action.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-3, 4-9, 11-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over OneSignal, and further in view of Hotchkies et. al. (US 9886261 B1), hereinafter Hotchkies, and further in view of Bott et. al. (US 2015/0363244 A1), hereinafter referred to as Bott.
Regarding claim 1, OneSignal teaches:
A computer-implemented method for prioritizing notifications deliverable to one or more end
users using a notifications service server including a notifications service identifier and a notifications
service calculator; and a notifications service monitor including a notifications service collector; the computer-implemented method comprising: (see e.g., page [026], "Intelligent Delivery is a unique feature of OneSignal that optimizes notification delivery time based on when each user most frequently access your app or website and is the best way to optimize notification open rates.")
identifying, by the notifications service identifier, one or more end user notification receiving
devices; (see e.g., page [019], "There are two options for selecting which devices are eligible to receive
notifications.
Option Description
Send to Subscribed Users Sends to your default segment which you can set. Otherwise, this
defaults to all subscribed devices.
Send by Segment If you've set up Segments, you can both include and exclude them from
receiving the message.")
sending, via the notifications service server, a first batch of one or more notifications to the
one or more end user notification receiving devices; (see e.g., page [026], "With Intelligent Delivery,
each user will receive your notification within 24 hours of you initiating delivery. For example, you sent a
message at 7 PM and the user is most likely to open the app/site at 1 PM, the notification will be
delivered 18 hours later (at 1 PM the following day).")
monitoring, by the notifications service monitor, delivery status information relative to each
of the one or more notifications of the first batch; (see e.g., page [004], "Using the API, the View
Notification and View Notifications endpoints will return the "converted" stat which is how many clicked
the notification, "successful" which is how many delivered to FCM/APNS/HMS/etc. and "received" which
is how many devices received it {Confirmed Deliveries).")
collecting, via the notifications service collector, the delivery status information; (see e.g., page [004-005], "The Notification History API allows viewing the specific Player IDs that "clicked" and were "sent" the notification. [. .. } "clicked" data shows which devices clicked the push and is not limited to a sample size.")
and determining, via the notifications service calculator, an end user notification preference
score for each of the one or more end user notification receiving devices using the delivery status
information. (See e.g.: page [026], "our SOK tracks their Last Session and notes the hours in which these devices most commonly return. This is based on up to a 3 month rolling average of a user's past actions." And page [004-005], "The Notification History API allows viewing the specific Player IDs that "clicked" and were "sent" the notification. [. .. } "clicked" data shows which devices clicked the push and is not limited to a sample size.") We are interpreting the cited section's mention of tracking user actions as a method to obtain a kind of "score" that is elsewhere used to prioritize notifications.
OneSignal fails to expressly teach:
the delivery status information that includes a first response time associated with each of the one or more end user notification receiving devices
prioritizing, based on the determining of the end user notification preference score, each of the one or more end user notification receiving devices in a descending order of the end user notification preference score: and
Determining that a second notification, to be sent to the one or more end user notification receiving devices, is one of a high priority notification or a low priority notification, wherein
In a case where the second notification is the high priority notification, sending the second notification to each of the one or more end user notification receiving devices based on the prioritizing of each of the one or more end user notification receiving devices, and
In a case where the second notification is the low priority notification, sending the second notification to each of the one or more end user notification receiving devices irrespective of the end user notification preference score.
However, Hotchkies teaches:
prioritizing, based on the determining of the end user notification preference score, each of the one or more end user notification receiving devices in a descending order of the end user notification preference score: (see e.g., page [002], paragraph [0013], “For example, the distribution control module 120 may sort the distribution priority values 138 in descending order, such that the greatest distribution priority value 138 is associated with a first sequence 208 number.”)
OneSignal and Hotchkies are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of optimizing and minimizing network traffic. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of OneSignal to incorporate the teachings of Hotchkies such that the messages as taught by OneSignal in order to solve the issue of the infeasibility of simultaneously sending data to increasingly large groups of devices. (see e.g., column [02], lines [12-22])
The combination of OneSignal in view of Hotchkies fails to expressly teach:
the delivery status information that includes a first response time associated with each of the one or more end user notification receiving devices
prioritizing, based on the determining of the end user notification preference score, each of the one or more end user notification receiving devices in a descending order of the end user notification preference score: and
Determining that a second notification, to be sent to the one or more end user notification receiving devices, is one of a high priority notification or a low priority notification, wherein
In a case where the second notification is the high priority notification, sending the second notification to each of the one or more end user notification receiving devices based on the prioritizing of each of the one or more end user notification receiving devices, and
In a case where the second notification is the low priority notification, sending the second notification to each of the one or more end user notification receiving devices irrespective of the end user notification preference score.
However, Bott teaches:
the delivery status information that includes a first response time associated with each of the one or more end user notification receiving devices (see e.g., page [020], paragraph [0225], “The response can be stored in the cache 285 (e.g., also referred as the local cache) as a cache entry. In addition to the response to a request, the cached entry can include response metadata having additional information regarding caching of the response. The metadata may be generated by the metadata generator 203 and can include, for example, timing data such as the access time of the cache entry or creation time of the cache entry. Metadata can include additional information, such as any information suited for use in determining whether the response stored as the cached entry is used to satisfy the subsequent response. For example, metadata information can further include, request timing history (e.g., including request time, request start time, request end time), hash of the request and/or response, time intervals or changes in time intervals, etc.”) Bott describes response information being stored in a local cache, and metadata including when the cache entry was created (i.e., when the response was created).
Determining that a second notification, to be sent to the one or more end user notification receiving devices, is one of a high priority notification or a low priority notification, wherein (see e.g., page [072], paragraph [0429], “and then applying one or more tests to determine whether the new or changed data should be sent to the mobile device (step 1526 followed by sub-flow “B”, which is shown in more detail in FIG. 14B) or suppressed, i.e., not sent to the mobile device (step 1524 followed by sub-flow “A”, which is shown in more detail in FIG 14A.)”) Note that 14A and 14B are both typos, both the flow charts available and the later descriptions indicate that 16A and 16B are the continuations describing subflow A and Subflow B respectively. Subflows A and B are being considered low and high priority.
In a case where the second notification is the high priority notification, sending the second notification to each of the one or more end user notification receiving devices based on the prioritizing of each of the one or more end user notification receiving devices, and (see e.g., page [072], paragraph [0431-0434], “FIG. 16B depicts a flow chart illustrating sub-flow “B” in more detail. In the embodiment illustrated in FIG. 16B, other events may trigger the selection process. For example, detection of an activity state of an application on the mobile device for which traffic is directed to or from (step 1608) may trigger a selection process,”)
In a case where the second notification is the low priority notification, sending the second notification to each of the one or more end user notification receiving devices irrespective of the end user notification preference score. (see e.g., page [072], paragraph [0433], “FIG. 16A depicts a flow chart illustrating sub-flow “A” in more detail. In the embodiment illustrated in FIG. 16A, data to be suppressed may be held for a period of time (step 1602) or until there is additional data to be sent (step 1604) before transmitting the new or changed data (step 1606.)”) The notification, if taking this path, will be sent either based on a time period, or when the queue is full. Hence, it is irrespective of an end user notification preference score.
(see e.g., sheets 28-31 of 34, fig. 15-16B, see images below, showing a flow chart with the following elements: Determining if data to be sent to a mobile device is high priority. If it is not, it gets forwarded to fig. 16A. If it is, it gets sent to the mobile device at step 1526. Emphasis added on relevant paths)
PNG
media_image1.png
664
914
media_image1.png
Greyscale
(see e.g., sheet 29 of 34, fig. 16A, see image below, showing a flow chart that shows what happens if a notification is found to be low priority (among other things). Specifically, that the notification either waits for a batch to fill up or for a time period to elapse before sending the data without consideration of priority.)
PNG
media_image2.png
354
478
media_image2.png
Greyscale
OneSignal and Bott are considered to be analogous art to the claimed invention because they are in the same field as the claimed invention of prioritizing notifications. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of OneSignal in view of Hotchkies to incorporate the teachings of Bott such that notifications are parsed to determine if they are low or high priority, then correspondingly handled as taught by Bott. Doing so would allow for optimization of notification network traffic. (Bott: Page [01], paragraph [008])
Regarding claim 2, OneSignal teaches:
The computer-implemented method of Claim 1, wherein each of the one or more end user notification receiving devices comprise a separate end user notification preference score for each of one or more defined timeslots. (See e.g., page [026], "our SOK tracks their Last Session and notes the hours in which these
devices most commonly return. This is based on up to a 3 month rolling average of a user's past
actions.")
Regarding claim 3, OneSignal teaches:
The computer-implemented method of Claim 2, wherein the end user notification preference score is selected from the group consisting of: a probability of a message relative to a respective one of the one or more notifications reaching a respective one of the one or more end user notification receiving devices and a probability of the message relative to a respective one of the one or more notifications being opened by a respective one of the one or more end users.
See, e.g., "our SDK tracks their Last Session and notes the hours in which these devices most
commonly return. This is based on up to a 3 month rolling average of a user's past actions" reads on "A
probability "(most commonly) "of a message relative to a respective" [notification] "reaching a
respective" [end user device] ("notes the hours in which these devices most commonly return").
(see also e.g., page 4, paragraphs 8-end, “Using the API, the View Notification and View Notifications endpoints will return the “converted” stat which is how many clicked the notification, “successful” which is how many delivered to FCM/APNS/HMS/etc. and “received” which is how many devices received it (Confirmed Deliveries).
The Notification History API allows viewing the specific Player IDs that “clicked” and were “sent” the notification. ‘sent’ data is limited to notifications delivered to 1000+ devices. If targeting under 1000 devices […] you can view the devices that were sent the message using the View Notification endpoint. ‘clicked’ data shows which devices clicked the push and is not limited to a sample size.”) Given that the SDK tracks both statistics in the same context and uses at least one of them in their existing calculation, it would be obvious to allow for a choice between the options. It would be as simple as substituting one number for another, and having some argument that informs the SDK on which value one would like to use.
Regarding claim 5, OneSignal teaches:
The computer-implemented method of Claim 1, further comprising sending, via the notifications service server, at least one additional batch of one or more notifications to the one or more end user notification receiving devices during one or more defined timeslots, wherein each of the one or more notifications of the at least one additional batch is sent to the one or more end user notification receiving devices at timed intervals during at least one of the one or more defined timeslots based on the first response time of each of the one or more end users. (OneSignal, page [026], "each user will receive your notification within 24 hours of you initiating delivery. For example, you sent a message at 7 PM and the user is most likely to open the app/site at 1 PM, the notification will be delivered 18 hours later.")
Regarding claim 6, OneSignal teaches:
The computer-implemented method of Claim 5, further comprising redetermining, via the notifications service calculator, the end user notification preference score for each of the one or more end user notification receiving devices based on a second response time of each of the one or more end users to the at least one additional batch of the one or more notifications. OneSignal discloses (see e.g., page [026], "our SOK tracks their Last Session and notes the hours in which these devices most commonly return. This is based on up to a 3 month rolling average of a user's past actions.")
Regarding claim 7, OneSignal teaches:
The computer-implemented method of Claim 5, wherein the sending of the at least one additional batch of the one or more notifications comprises scheduling, via the notifications service server, at least one batch job configured to send at least one of the first batch of the one or more notifications or the at least one additional batch of the one or more notifications at regular intervals. (See e.g., page [025], "You can schedule a notification up to 30 days in advance. The OneSignal Dashboard detects timezone according to your Operating Systems time. Selecting Begin sending at a particular time will allow you to set when the notifications will start to be sent. That time is displayed on the bottom right circled in red in the image. Notifications will be delivered to users based on the Per-User Optimization selection.")
Regarding claim 8, OneSignal teaches:
A computer program product for reducing computing resources by prioritizing notifications
deliverable to one or more end users, the computer program product comprising a computer readable
storage medium having program instructions embodied therewith, the program instructions
executable by a processor to cause the processor to perform: the method of claim 1. Accordingly, claim 8 is rejected as being unpatentable over OneSignal in view of Hotchkiew and further in view of Bott for the same reasons presented with respect to claim 1.
Claims 9 and 11-13 recites substantially the same limitations as claims 2 and 5-7 respectively, applied to the computer program product of claim 8. Therefore, claims 9 and 11-13 are rejected as being unpatentable over OneSignal in view of Hotchkiew and further in view of Bott for the same reasons provided regarding claims 2 and 5-7.
Regarding claim 14, OneSignal teaches:
A computing system comprising: a processor; a network module coupled to the processor to
enable communication over a network; a computer-readable storage device coupled to the processor;
a notifications service server coupled to the processor and the network module, the notifications
service server including a notifications service identifier and a notifications service calculator; a
notifications service monitor coupled to the processor, the notifications service monitor including a
notifications service collector; program instructions stored on the computer-readable storage device
for execution by the processor via a memory, wherein the execution of the program instructions by the processor configures a computing device to perform: the method of claim 1. Accordingly, claim 8 is rejected as being unpatentable over OneSignal in view of Hotchkies and further in view of Bott for the same reasons presented with respect to claim 1.
Claims 15-16 and 18-20 recite substantially the same limitations as claims 2-3 and 5-7 respectively, applied to the computing system of claim 14. Therefore, claims 15-16 and 18-20 are rejected as being unpatentable over OneSignal in view of Hotchkiew and further in view of Bott for the same reasons provided regarding claims 2-3 and 5-7.
Response to Arguments
The Remarks on the typographical error is noted, and the related rejection in this action will be corrected.
Applicant’s arguments with respect to claims 1, 8, and 14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Connor Imiola Blackburn whose telephone number is (571)272-6547. The examiner can normally be reached M-Th 7-5.
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, Kevin Young can be reached at (571) 270 - 3180. 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.
/C.I.B./ Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights