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 .
Claim Rejections - 35 USC § 102
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 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by OneSignal et al (“Documentation”).
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 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 DescriptionSend 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 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.” 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.
Regarding claim 2, OneSignal teaches:
The 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 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.”)
Regarding claim 3, OneSignal teaches:
The method of Claim 2, wherein the end user notification preference score includes at least one 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 or 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”).
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: (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 DescriptionSend 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 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.” 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.
Regarding claim 9, OneSignal teaches:
The computer program product of Claim 8, 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 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.”)
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 execution of the instructions by the processor configures the computing device to perform a deliverable end user notifications prioritization to conserve computing resources 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 DescriptionSend 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 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.” 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.
Regarding claim 15, OneSignal teaches:
The computing system of Claim 14, 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 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.”)
Regarding claim 16, OneSignal teaches:
The computing system of Claim 15, wherein the end user notification preference score includes at least one 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 or 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”).
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.
Claims 4-7, 10-13, and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over OneSignal et al., in view of Araújo et al.
Regarding claim 4, OneSignal does not explicitly teach:
The method of Claim 1, wherein the delivery status information includes a first response time by each of the one or more end users during one or more defined timeslots.
OneSignal does collect adjacent information that one of ordinary skill in the art before the effective filing date of the claimed invention could use to find a first response time (OneSignal, [026], “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.”, page [005], “"clicked" data shows which devices clicked the push and is not limited to a sample size.”)
Araújo, in the field of notification analysis, does teach using a first response time by each of the one or more end users during one or more defined timeslots to find when users are most likely to respond (See e.g., page [003], “The second model corresponds to the time of the email opening”, page [003], “Two classification models were used to determine whether a campaign was successful or not, based on the open rates. The classification models are based on (i) the names of campaigns, (ii) recipients and senders, (iii) the content of the message, (iv) the number of emails sent, (v) the number of emails delivered, and (vi) the number of open emails.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to try to combine the described method by OneSignal, which tracks each individual user’s last time opening the app or website to determine when it would be best to send to that user, with Araújo’s method using the time the user responded to a notification to predict when the best time to send a notification to a group. This replacement would be both incredibly simple to try, with a reasonable expectation of success, as the difference between OneSignal’s disclosure and the claimed invention is equivalent to replacing one diagnostic criteria with another. One of ordinary skill in the art would expect similar results between both variations of the method before the effective filing date of the claimed invention, and would try this combination in order to attempt to “enhance subscriber open rates and click-through rates” (Araújo, page [002])
Regarding claim 5, OneSignal teaches:
The method of Claim 4, 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 are sent to the one or more additional 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 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 using at least one additional response time of each of the one or more end users to the at least one additional batch of one or more notifications. OneSignal discloses (see e.g., page [026], “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.”)
Regarding claim 7, OneSignal teaches:
The method of Claim 5, wherein the sending further 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 10, OneSignal does not explicitly teach:
The computer program product of Claim 8, wherein the delivery status information includes a first response time by each of the one or more end users during one or more defined timeslots.
OneSignal does collect adjacent information that one of ordinary skill in the art before the effective filing date of the claimed invention could use to find a first response time (OneSignal, [026], “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.”, page [005], “"clicked" data shows which devices clicked the push and is not limited to a sample size.”)
Araújo, in the field of notification analysis, does teach using a first response time by each of the one or more end users during one or more defined timeslots to find when users are most likely to respond (See e.g., page [003], “The second model corresponds to the time of the email opening”, page [003], “Two classification models were used to determine whether a campaign was successful or not, based on the open rates. The classification models are based on (i) the names of campaigns, (ii) recipients and senders, (iii) the content of the message, (iv) the number of emails sent, (v) the number of emails delivered, and (vi) the number of open emails.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to try to combine the described product by OneSignal, which tracks each individual user’s last time opening the app or website to determine when it would be best to send to that user, with Araújo’s method using the time the user responded to a notification to predict when the best time to send a notification to a group. This replacement would be both incredibly simple to try, with a reasonable expectation of success, as the difference between OneSignal’s disclosure and the claimed invention is equivalent to replacing one diagnostic criteria with another. One of ordinary skill in the art would expect similar results between both variations of the method before the effective filing date of the claimed invention, and would try this combination in order to attempt to “enhance subscriber open rates and click-through rates” (Araújo, page [002])
Regarding claim 11, OneSignal teaches:
The computer program product of Claim 10, 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 are sent to the one or more additional 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 12, OneSignal teaches:
The computer program product of Claim 11, 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 using at least one additional response time of each of the one or more end users to the at least one additional batch of one or more notifications. OneSignal discloses (see e.g., page [026], “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.”)
Regarding claim 13, OneSignal teaches:
The computer program product of Claim 11, wherein the sending further 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 17, OneSignal does not explicitly teach:
The computing system of Claim 14, wherein the delivery status information includes a first response time by each of the one or more end users during one or more defined timeslots.
OneSignal does collect adjacent information that one of ordinary skill in the art before the effective filing date of the claimed invention could use to find a first response time (OneSignal, [026], “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.”, page [005], “"clicked" data shows which devices clicked the push and is not limited to a sample size.”)
Araújo, in the field of notification analysis, does teach using a first response time by each of the one or more end users during one or more defined timeslots to find when users are most likely to respond (See e.g., page [003], “The second model corresponds to the time of the email opening”, page [003], “Two classification models were used to determine whether a campaign was successful or not, based on the open rates. The classification models are based on (i) the names of campaigns, (ii) recipients and senders, (iii) the content of the message, (iv) the number of emails sent, (v) the number of emails delivered, and (vi) the number of open emails.”).
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to try to combine the described system by OneSignal, which tracks each individual user’s last time opening the app or website to determine when it would be best to send to that user, with Araújo’s method using the time the user responded to a notification to predict when the best time to send a notification to a group. This replacement would be both incredibly simple to try, with a reasonable expectation of success, as the difference between OneSignal’s disclosure and the claimed invention is equivalent to replacing one diagnostic criteria with another. One of ordinary skill in the art would expect similar results between both variations of the method before the effective filing date of the claimed invention, and would try this combination in order to attempt to “enhance subscriber open rates and click-through rates” (Araújo, page [002])
Regarding claim 18, OneSignal teaches:
The computing system of Claim 17, 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 are sent to the one or more additional 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 19, OneSignal teaches:
The computing system of Claim 18, 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 using at least one additional response time of each of the one or more end users to the at least one additional batch of one or more notifications. OneSignal discloses (see e.g., page [026], “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.”)
Regarding claim 20, OneSignal teaches:
The computing system of Claim 18, wherein the sending further 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.”)
Conclusion
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 6:30-4:30.
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 Paten t 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