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 .
Response to Amendment
2. Applicant's arguments and amendments, filed on 3/16/2026 has been entered and carefully considered. Claims 1-15, 22-27 are pending.
Claim Rejections - 35 USC § 103
5. 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 of this title, 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.
6. Claims 1-15 and 22-27 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Seed et al. (U.S. PGPub 2015/0033312) in view of OneM2M (TS-0001-V1.13.1 Document Name: Functional Architecture) further in view of Sundaresan et al. (U.S. PGPub 2017/0063826).
As per claims 1, 8 and 15
Seed teaches apparatus comprising at least one processor and memory, the memory storing executable instructions that, when executed by the at least one processor, implement a service layer Iot device of a communications network and cause the service layer Iot device to perform operations (Seed see para 0046, 0064, as shown in fig. 1. a M2M service layer instance 121 or 123 of a service layer session manager residing on gateway 114 or server 118, as shown in fig. 5 E2E M2M service layer session manager 145 with a session credential function 147, an E2E M2M session context and history function 161, an E2E M2M session routing function 162, an E2E M2M session establishment and teardown function 163, an E2E M2M session policy function 164, an E2E M2M session configuration and discovery function 165, an E2E M2M session data management function 166, and a session state 151) comprising:
receiving a request comprising a policy associated with a target internet-of-things (IoT) device, wherein the policy indicates at least one condition for triggering management of a flow of service layer messages to the target IoT device;(Seed see para 0078, 0103, as shown in fig. 5 E2E M2M service layer session policy function 164. Session policy function 164 supports session policy configuration, management, and sharing with intelligent service layer session communication between session endpoints with session routing policies, E2E M2M service layer session store-and-forward policies session context policies that determine the context to collect, how to interpret context, how to factor context into decision making, as shown in fig. 11B step 343, based on a targeted session endpoint AE 302 , SMG CSF on CSE 306 determines next hop is CSE 304, step 344, based on sessionID and targeted session endpoint AE 302, SMG CSF on CSE 306 finds session policy defining store-and-forward scheduling policy that defines at step 345, based on policy, CSE 306 stores request until off-peak hours and then forwards it to CSE 304 during off-peak hours);
Seed does explicitly teach but OneM2M teaches determining a service schedule of the target IoT device based on the policy, wherein the service schedule indicates whether the target IoT device is available to receive service layer messages; (See pages 23-25, 111-112, OneM2M teaches For the delivery of communication, ability to select appropriate communication path to use at any given time in line with provisioned CMDH policies and with CMDH-related parameters set by the Originator of requests, and when needed and allowed, how long to buffer communication requests so that they can be forwarded at a later time. This policy-driven use of communication resources allows an M2M Service Provider to control which Originators of requests are allowed to consume communication resources at certain times.)
determining, based on the service schedule, to trigger management of the flow of service layer messages to the target IoT device; (See pages 23-25, 111, OneM2M teaches Ability to grant access to data from remote CSEs and AEs based on defined access control policies, and trigger data processing based on data access.)
It would have been obvious to one of ordinary skill in the art to before the effective filling date of the claimed invention to combine the teaching of OneM2M with the teaching of Seed, because OneM2M teaches an end-to-end oneM2M functionality making the overall invention more robust and efficient. (OneM2M – page 12)
Seed and OneM2M fail to exclusively teach but Sundaresan teaches managing, based on the trigger determination and the policy, the flow of service layer messages to the target IoT device.
In a similar field of endeavor Sundaresan teaches managing, based on the trigger determination and the policy, the flow of service layer messages to the target IoT device (Sundaresan, see para 0096-0098, block 315-328 of fig. 3A, processing logic determines parameters for each request for data that will be made to a data feed in the next time period block, sends the requests for data to each of the data sources identified in the scheduled data feed entries using the determined parameters, receives the data from the various data feeds, store , convert a data format of the data from a first format in which it was received to a second format understandable to an endpoint device and sends the received data to the devices identified in the scheduled data feeds).
It would have been obvious to one of ordinary skill in the art to before the effective filling date of the claimed invention to combine the teaching of Seed and OneM2M with the teaching of Sundaresan, as doing so would provide an efficient method for supporting service layer data feed service with improved management function for data updates from data feeds of multiple data sources by the data feed service that increase capabilities of end-point devices as well as conserve bandwidth of networking and processing resources by coordinating data feed entries, developing schedules to queue data feed jobs at pre-defined intervals, transforming the data feed jobs with static and dynamic parameters into data requests and delivering the data to one or more endpoint devices (Sundaresan see para 0018).
As per claims 2 and 9
Seed, OneM2M, and Sundaresan teach the apparatus recited in claim 1, wherein the executable instructions further cause the service layer Iot device to perform operations comprising: sending, based on the trigger determination, to one or more other service layer entities located remotely on the communications network, a message requesting the one or more other service layer entities to participate in managing the flow of service layer messages to the target Iot device (Sundaresan, see para 0044, 0109, 110, WAN accessible services 130 can include a rules engine 112 that applies one or more rules to determine actions and generate messages and/or commands to implement the determined actions based on received events, Data requestors 402 send instructions to the feed service engine 401 to deliver data from data feeds of data sources 460 to end-point devices 435, the feed service engine 401 is connected with a rules engine 412 and deliver feed data to the rules engine 412 to trigger a command, a climate control system that uses a sensor to provide temperature readings from different zones may leverage the feed service engine 401 to retrieve weather data from a data source 460 on the Internet for outside temperature readings. By coordinating local data providers, devices 436) and remote data providers, a push feed 461, or a pull feed 462, the feed service engine 401 can provide a substitute to a local sensor. For example, the feed service engine 401 can update an external temperature parameter in a device 435 via a weather data provider from the Internet rather than local sensors that can be costly or prone to interruptions in service).
It would have been obvious to one of ordinary skill in the art to before the effective filling date of the claimed invention to combine the teaching of Seed with the teaching of Sundaresan, and the motivation to combine the teaching will be the same as claims 1, 8 and 15.
As per claims 3 and 10
Seed, OneM2M, and Sundaresan teach the apparatus recited in claim 1,
wherein managing the flow of service layer messages to the target Iot device comprises one or more of: disabling one or more subscriptions of the target Iot device to resources hosted on the service layer Iot device and one or more other service layer entities located remotely on the communications network (Seed see para 0106, step 376, SMG CSF on CSE 304 deletes its locally hosted & session&; resource and all child resources. The SMG CSF also deletes any local session state such as security credentials and identifiers allocated to the session, at step 377, SMG CSF on CSE 304 returns a positive response to the session termination DELETE request to the SMG CSF on CSE 306) ; disabling one or more announced resources of the target Iot device hosted on the service layer Iot device and one or more other service layer entities located remotely on the communications network; filtering results of one or more discover requests to remove results pointing to one or more resources of the target Iot device; removing the target Iot device from one or more group resources; or - 45 -WO 2020/149963PCT/US2019/065419 adjusting a rate of sending or forwarding of service layer messages to the target Iot device.
As per claims 4 and 11
Seed, OneM2M, and Sundaresan teach the apparatus recited in claim 1, yet fails to wherein the instructions, when executed by the at least one processor, further cause the service layer Iot device to perform operations comprising monitoring context information associated with the target Iot device, wherein the context information associated with the target Iot device comprises one or more of:
information indicating a level of battery power of the target Iot device; information indicating a signal strength of communications received from the target Iot device; information comprising a service schedule of the target Iot device (Sundaresan, see para 0051, 055, Feed scheduler 203 collect feed request, generate and store a new data feed entry including a data source 260 from which to receive data, an endpoint device 235 to send received data to, a schedule of when to send the received data to the endpoint device 235, a data feed description, a feed identifier, a data source 260 identifier, an endpoint device 235 identifier, a property feed type, a property feed subtype, a feed event, feed parameters, feed job metadata, feed event represents the schedule that indicates a frequency or an interval for sending updated feed data from a data source 260 to a device 235, represented by interval point pairs including an interval length and a point during the interval to trigger the data feed job, feed scheduler 203 interface with a device management service to collect the one or more attributes or properties of an end-point device 235 associated with a data feed entry, properties such as a device type, data formats readable by the device, a device location, a device time zone, device settings, a device power state, feed scheduler 203 synchronize feed schedules, as represented in the data feed entries with the device management system); information indicating a level of congestion of the communications network; or information indicating a fault condition associated with connectivity of the target Iot device to the communications network;
It would have been obvious to one of ordinary skill in the art to before the effective filling date of the claimed invention to combine the teaching of Seed with the teaching of Sundaresan, and the motivation to combine the teaching will be the same as claims 1, 8 and 15.
As per claims 5 and 12
Seed, OneM2M, and Sundaresan teach the apparatus recited in claim 4, wherein determining to trigger management of the flow of service layer messages to the target Iot device comprises: comparing the monitored context information to one or more conditions; and determining to trigger management of the flow of service layer messages to the target Iot device when the one or more conditions are met (Sundaresan, see para 0094-0095, block 312 processing logic determines one or more data feed entries that are scheduled to provide data in a next time period based on the query at block 310 measures a time T in minutes passed between the current time and a reference point date and time, the processing logic may calculate whether the current minute when it performs a publish operation is a proper time for publishing a feed job for a particular data feed entry into a job queue);
It would have been obvious to one of ordinary skill in the art to before the effective filling date of the claimed invention to combine the teaching of Seed with the teaching of Sundaresan, and the motivation to combine the teaching will be the same as claims 1 and 8.
As per claims 6 and 13
Seed, OneM2M, and Sundaresan teach the apparatus recited in claim 5, wherein the one or more conditions comprise one or more of:
the level of battery power of the target Iot device has met a threshold value; the signal strength of communications received from the target Iot device has met a threshold value; the service schedule of the target Iot device indicates that the target Iot device is unavailable on the communications network (Sundaresan, see para 0094-0095, block 312 processing logic determines one or more data feed entries that are scheduled to provide data in a next time period based on the query at block 310 measures a time T in minutes passed between the current time and a reference point date and time, the processing logic may calculate whether the current minute when it performs a publish operation is a proper time for publishing a feed job for a particular data feed entry into a job queue).
As per claims 7 and 14
Seed, OneM2M, and Sundaresan teach the apparatus recited in claim 1, wherein the executable instructions further cause the service layer Iot device to perform operations comprising: - 46 -WO 2020/149963PCT/US2019/065419 receiving, from the target Iot device, a request to trigger management of the flow of service layer messages to the target Iot device; and managing, based on the received request and other information of the policy, the flow of service layer messages to the target Iot device (Sundaresan see para 0044, 0045, 0100, WAN accessible services 130 can include a rules engine 112. Rules engine 112 applies one or more rules to determine actions and generate messages and/or commands to implement the determined actions based on received events, Data requestors 402 send instructions to the feed service engine 401 to deliver data from data feeds of data sources 460 to end-point devices 435, the feed service engine 401 is connected with a rules engine 412 and deliver feed data to the rules engine 412 to trigger a command for the end-point device 435, the rules engine 412 determine values to assign to parameters and/or a setting of the end-point device 435 based on logical rules of the rules engine 412, and then may send controls to implement the determined values for the parameters and/or settings to the end-point device 435).
It would have been obvious to one of ordinary skill in the art to before the effective filling date of the claimed invention to combine the teaching of Seed with the teaching of Sundaresan, and the motivation to combine the teaching will be the same as claims 1 and 8.
As per claims 22, 24 and 26
Seed, OneM2M, and Sundaresan teach apparatus of claim 1, wherein the service layer Iot device supports service capabilities through a set of Application Programming Interfaces (APIs) (Seed see para 0004 an M2M service layer can support Application Programming Interfaces (APIs) providing applications and devices access to a collection of M2M centric capabilities supported by the service layer including security, charging, data management, device management, discovery, provisioning, and connectivity management, these capabilities are made available to applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer).
As per claims 23, 25 and 27
Seed, OneM2M, and Sundaresan teach apparatus of claim 22, wherein functions of the service layer Iot device are defined based at least in part on one of ETSI and oneM2M (Seed see para 0098, as shown in fig. 9 illustrates a oneM2M embodiment of a session manager, oneM2M has definitions of capabilities supported by the oneM2M service layer, such as capability service functions CSFs, such as CSF 270, the oneM2M service layer is referred to as a capability services Iot device CSE).
Response to Arguments
Applicant's arguments filed 3/16/2026 have been fully considered but they are not persuasive.
Applicant Argues: “Seed, OneM2M, and Sundaresan, alone or in combination, fail to teach or suggest "determining a service schedule of the target IoT device based on the policy, wherein the service schedule indicates whether the target IoT device is available to receive service layer messages" as recited by claims 1, 8, and 15. The Office Action acknowledges that Seed fails to teach this feature of claim 1. Nonetheless, the Office Action asserts that this is taught by OneM2M. Applicant respectfully is agrees. OneM2M fails to disclose this limitation because the CMDH policies and/or CMDH- related parameters are not used to determine a service schedule that indicates whether a target IoT device is available to receive service layer messages. Instead, the CMDH policies are used to describe "details for the usage of the specific Underlying Network(s)." (See page 24). The CMDH-related parameters are "delivery handling parameters" that are "specific to each request for communication" such as an "acceptable expiration time for delivery." (See pages 23-24). Neither of these are used to determine the service schedule as claimed because neither indicates whether the target IoT device is available to receive service layer messages. Sundaresan has not been alleged to teach this claimed limitation and Sundaresan does not disclose a service schedule that indicates whether a target IoT device is available to receive service layer messages.”
Examiner’s response: Examiner respectfully disagrees and points to page 24 and 111 which teaches the schedule resource is used to tell when the IOT device or application is available to send or receive messages. It works by listing servicing time periods in the scheduleElement field. If there is no schedule, the device is considered always available. The Hosting CSE checks the current time against the schedule before sending request or notifications. This helps save battery and network resources on constrained devices. If outside the allowed window, delivery may be deferred, retried, or dropped depending on policies like CMDH and request expiration, while absence of schedule the target is always available. Therefore, the limitation is taught by the previously applied prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
1.Wang et all, U.S. Patent App 20160344841, teaches Context-aware and proximity-aware service layer connectivity management may leverage context information and connectivity service policies to dynamically determine and adjust appropriate service layer connectivity for machine-to-machine or Internet of things entities.
THIS ACTION IS MADE FINAL. 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 NINOS DONABED whose telephone number is (571)272-8757. The examiner can normally be reached Monday - Friday 8:00pm - 4:00pm.
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, John Follansbee can be reached at (571) 272-3964. 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.
/NINOS DONABED/Primary Patent Examiner, Art Unit 2444