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 .
Claim status
Claims 1-20 presented for the examination and remain pending in the application.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 12,348,585 B2, (hereinafter Patent ‘585) in view of Schoppmeier U.S. Pub. No. 2017/0374490 A1, (hereinafter Schoppmeier). Although the claims at issue are not identical, they are not patentably distinct from each other because the Patent ‘585claims 1-18 recite all of the limitations of instant application claims 1-20 except that for the term “wherein the representation is operable for transmission using an Internet of Things (loT) transfer Protocol”.
However, Schoppmeier teaches “wherein the representation is operable for transmission using an Internet of Things (loT) transfer Protocol” (Schoppmeier teaches in para. [0019] client device 104 can be a refrigerator, an HVAC system, a microwave, toaster, or any energy consuming device capable of having power consumption measured thereat or operating other sensors within an IoT home network, for example. The client devices 102-106 can also be controllers, or other energy consuming devices,…Also, see para. [0015]-[0016], [0018], [0026], [0035], [0037]-[0038]).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time of invention, to include a system of any energy consuming device capable of having power consumption measured thereat or operating other sensors within an IoT home network of Schoppmeier’s invention into Patent ‘585 invention in order to the protocol data can thus be controlled, updated, and mapped for translating various communication back and forth between servers and client devices, other network devices and the client devices and among these client devices, which can be in the home/entity. The processor is functionally connected to communication platform and can facilitate operations on data for multiplexing/demultiplexing, such as effecting direct and inverse fast Fourier transforms, selection of modulation rates, selection of data packet formats, inter-packet times, and so on. The display interface can also facilitate data entry, which can cause access equipment and/or software to receive external commands. The mux/demux unit can facilitate manipulation of signal in time and frequency space.
See the table below which shows the comparison between the instant application limitations of claims 1-20 and the Patent ‘585 limitations of claims 1-20. Note that here the bolded limitation of the instant application 19/226,882 is addressed by the secondary prior art of record Schoppmeier above.
Instant Application 19/226,882
Patent Application 12,348,585 B2
Claim 1. A sending node that is operable to provide a representation of at least one resource, wherein the resource comprises a sensor measurement, and wherein the representation is operable for transmission using an Internet of Things (loT) transfer Protocol, the sending node comprising processing circuitry configured to:
Claim 1. A sending node, the sending node comprising processing circuitry configured to perform a method comprising: obtaining a first representation of a first sensor measurement generated at a point in time, wherein the first representation of the first sensor measurement (i.e., note that here the term sensor measurement is one of the resource) was generated according to a data model, and the first representation of the first sensor measurement comprises: a first sensor value for the first sensor measurement, and a first time value that represents the point in time at which the first sensor measurement was generated; obtaining the first time value from the first representation of the first sensor measurement; and including the first time value that represents the point in time at which the first sensor measurement was generated, or a first derived time value derived using the first time value that represents the point in time at which the first sensor measurement was generated, in the timestamp field of the header of the first RTP data packet; and sending the generated first RTP packet to a receiving node.
generate a representation of the resource according to a data model;
wherein the first representation of the first sensor measurement (i.e., note that here the term sensor measurement is one of the resource) was generated according to a data model,
generate a Real-time Transport Protocol (RTP) data packet, wherein the RTP data packet comprises the generated representation of the resource; and
after obtaining the first representation of the first sensor measurement, generating a first Real-time Transport Protocol (RTP) data packet using the first sensor value for the first sensor measurement and the first time value for the first sensor measurement, wherein the RTP data packet comprises a header and a payload, the header comprising a timestamp field, and generating the first RTP data packet comprises: obtaining the first sensor value from the first representation of the first sensor measurement; including the obtained first sensor value in the payload of the first RTP packet;
send the generated RTP packet to a receiving node.
and sending the generated first RTP packet to a receiving node.
Claim 2. The sending node of claim 1, wherein the data model comprises Sensor Measurement Links, SenML, and wherein the representation of the resource according to the data model comprises a SenML Record.
Claim 2. The sending node of claim 1, wherein the data model comprises Sensor Measurement Links (SenML), the first representation of the first sensor measurement is a first SenML Record, the first representation of the first sensor measurement further comprises first unit information associated with the first sensor value, the first unit information indicating a unit of measurement for the first sensor value, and generating the RTP packet further comprise obtaining the first unit information from the first representation and including the obtained first unit information in the RTP packet.
Claim 3. The sending node of claim 1, wherein the processing circuitry is further configured to generate an RTP data packet, wherein the RTP data packet comprises the generated representation of the resource, by: adding at least a part of the generated representation of the resource to a payload of the RTP data packet.
Claim 3. The sending node of claim 1, wherein the processing circuitry is further configured to generate an RTP data packet, wherein the RTP data packet comprises the generated representation of the resource, by: adding at least a part of the generated representation of the resource to a payload of the RTP data packet.
Claim 4. The sending node of claim 1, wherein the processing circuitry is further configured to generate an RTP data packet, wherein the RTP data packet comprises the generated representation of the resource, by: mapping information from at least one field in the representation to a header field of the RTP data packet.
Claim 4. The sending node of claim 3, wherein the method further comprises obtaining a second representation of a second sensor measurement, wherein the second representation of the second sensor measurement was generated according to the data model, and the second representation of the second sensor measurement comprises: a second sensor value for the second sensor measurement and a second time value, and generating the first RTP data packet further comprises including in the payload of the first RTP packet the second sensor value and a third time value. Further, claim 15. The receiving node of claim 10, wherein the processing circuitry is further configured to map information from at least one header field of the RTP data packet to a field in the representation by: mapping information from a Synchronization Source (SSRC) field of the RTP data packet to a name field of the representation.
Claim 5. The sending node of claim 4, wherein the processing circuitry is further configured to map information from at least one field in the representation to a header field of the RTP data packet by: mapping information from a time field of the representation to a timestamp field of the RTP data packet.
Claim 6. including the obtained second time value, or a second derived time value derived using the obtained second time value, in a timestamp field of the RTP data packet; and further, claim 15. The receiving node of claim 10, wherein the processing circuitry is further configured to map information from at least one header field of the RTP data packet to a field in the representation by: mapping information from a Synchronization Source (SSRC) field of the RTP data packet to a name field of the representation.
Claim 6. The sending node of claim 5, wherein the processing circuitry is further configured to map information from a time field of the representation to a timestamp field of the RTP data packet by setting a value of the timestamp field of the RTP data packet to be the value of the time field of the representation.
generating a second RTP data packet using the second sensor value for the second sensor measurement and the second time value for the second sensor measurement, wherein generating the second RTP data packet comprises: obtaining the second sensor value from the second representation of the second sensor measurement; including the obtained second sensor value in the RTP packet; obtaining the second time value from the second representation of the second sensor measurement; including the obtained second time value, or a second derived time value derived using the obtained second time value, in a timestamp field of the RTP data packet; and including in the second RTP packet an indicator indicating that the second sensor measurement is the last of a pack of sensor measurements; and sending the second RTP packet to the receiving node.
Claim 7. The sending node of claim 5, wherein the processing circuitry is further configured to generate a plurality of representations of the resource according to the data model, the plurality of representations comprising a representation pack, and wherein the processing circuitry is further configured to map information from a time field of the representation to a timestamp field of the RTP data packet by: setting a value of the timestamp field of the RTP data packet to be the value of the time field of a first representation of the representation pack.
Claim 13. The receiving node of claim 10, wherein the representation is one of a plurality of representations of the resource according to the data model, the plurality of representations comprising a representation pack, and wherein the processing circuitry is further configured to map information from a timestamp field of the RTP data packet to a time field of the representation by: setting a value of the time field of a first representation of the representation pack to be the value of the timestamp field of the RTP data packet.
Claim 8. The sending node of claim 7, wherein the processing circuitry is further configured to set the time field for other representations in the representation pack to indicate a time difference from the value of the timestamp field of the RTP data packet.
Partial claim 6 including the obtained second time value, or a second derived time value derived using the obtained second time value, in a timestamp field of the RTP data packet; and including in the second RTP packet an indicator indicating that the second sensor measurement is the last of a pack of sensor measurements; and sending the second RTP packet to the receiving node.
Claim 9. The sending node of claim 1, wherein the processing circuitry is further configured to generate a plurality of representations of the resource according to the data model, the plurality of representations comprising a representation pack; wherein the processing circuitry is further configured to generate a plurality of RTP data packets, wherein each RTP data packet comprises a generated representation; and wherein the processing circuitry is further configured to set a marker bit of the RTP data packet comprising at least one of the first or last representations of the representation pack.
Claim 9. The sending node of claim 1, wherein the processing circuitry is further configured to generate a plurality of representations of the resource according to the data model, the plurality of representations comprising a representation pack; wherein the processing circuitry is further configured to generate a plurality of RTP data packets, wherein each RTP data packet comprises a generated representation; and wherein the processing circuitry is further configured to set a marker bit of the RTP data packet comprising at least one of the first or last representations of the representation pack.
Claim 10. The sending node of claim 4, wherein the processing circuitry is further configured to map information from at least one field in the representation to a header field of the RTP data packet by: mapping information from a name field of the representation to a Synchronization Source, SSRC, field of the RTP data packet.
Claim 15. The receiving node of claim 10, wherein the processing circuitry is further configured to map information from at least one header field of the RTP data packet to a field in the representation by: mapping information from a Synchronization Source (SSRC) field of the RTP data packet to a name field of the representation.
Regarding claims 11 and 20.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of independent claim 1 apples to independent claims 11 and 20.
Regarding claim 12.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 2 apples to dependent claim 12.
Regarding claim 13.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 3 apples to dependent claim 13.
Regarding claim 14.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 4 apples to dependent claim 14.
Regarding claim 15.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 6 apples to dependent claim 15.
Regarding claim 16.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 8 apples to dependent claim 16.
Regarding claim 17.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 7 apples to dependent claim 17.
Regarding claim 18.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 9 apples to dependent claim 18.
Regarding claim 19.
Similarly, the above potential non-statutory double patenting ground of rejection analysis of dependent claim 10 apples to dependent claim 19.
Claim Rejections - 35 USC § 103
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 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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-6, 11, 13-16, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ojala U.S. Pub. No. 2017/0284839 A1, (hereinafter Ojala) in view of Schoppmeier U.S. Pub. No. 2017/0374490 A1, (hereinafter Schoppmeier) further in view of Begen et al. U.S. Pub. No. 2011/0289538 A1, (hereinafter Begen).
Regarding claim 1.
Ojala teaches a sending node that is operable to provide a representation of at least one resource (Ojala teaches in Fig. 1A and para. [0106]), wherein the resource comprises a sensor measurement (Ojala teaches in Para. [0060] the sensor nodes in the network may operate as reference sensor nodes so that the environmental measurements of the first sensor node 102 (in FIG. 1A) (i.e., the sending node) is being compared to a plurality of reference environmental measurements generated by a corresponding plurality of reference sensor nodes), the sending node comprising processing circuitry configured to: generate a representation of the resource according to a data model (Ojala teaches in para. [0057] a data element representing a sensor signal generated from detecting a corresponding physical event. An environmental measurement may be in the form of a set of digital samples representing the signal sampled at a given sample rate, or in the form of a signal level…);
generate a Real-time Transport Protocol (RTP) data packet, wherein the RTP data packet comprises the generated representation of the resource (Ojala teaches in Para. [0064] a first sensor node performs a measurement of an environmental parameter to generate a first environmental measurement in a sparse representation. A sparse representation of a second environmental measurement is received from a second sensor node in a request to establish a communications link with the first sensor node and further Ojala teaches in Para. [0081] the sparse signal transformed into the compressed domain is transmitted to the sensor node network manager..., the transform coefficients may be quantized and packetized in for example JavaScript Object Notation (JSON) data structure in real-time protocol (RTP) payload). Ojala does not explicitly teach a sending node wherein the representation is operable for transmission using an Internet of Things (loT) transfer Protocol.
However, Schoppmeier teaches a sending node wherein the representation is operable for transmission using an Internet of Things (loT) transfer Protocol (Schoppmeier teaches in para. [0019] client device 104 can be a refrigerator, an HVAC system, a microwave, toaster, or any energy consuming device capable of having power consumption measured thereat or operating other sensors within an IoT home network, for example. The client devices 102-106 can also be controllers, or other energy consuming devices,…Also, see para. [0015]-[0016], [0018], [0026], [0035], [0037]-[0038]).
Therefore, Ojala and Schoppmeier are analogues arts and they are in the same field of endeavor as they both are directed to the sensor nodes in the network may operate as reference sensor nodes so that the environmental measurements of the first sensor node 102 (in FIG. 1A) (i.e., the sending node) and using energy consuming device capable of having power consumption measured thereat or operating other sensors within an IoT home network.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of using energy consuming device capable of having power consumption measured thereat or operating other sensors within an IoT home network ([0019]) as taught, by Schoppmeier into the teachings of Ojala invention. One would have been motivated to do so in order to the protocol data can thus be controlled, updated, and mapped for translating various communication back and forth between servers and client devices, other network devices and the client devices and among these client devices, which can be in the home/entity. The processor is functionally connected to communication platform and can facilitate operations on data for multiplexing/demultiplexing, such as effecting direct and inverse fast Fourier transforms, selection of modulation rates, selection of data packet formats, inter-packet times, and so on. The display interface can also facilitate data entry, which can cause access equipment and/or software to receive external commands. The mux/demux unit can facilitate manipulation of signal in time and frequency space.
Ojala in view of Schoppmeier does not explicitly teach send the generated RTP packet to a receiving node.
However, Begen teaches send the generated RTP packet to a receiving node (Begen teaches in Para. [0026] the server 106 (i.e., receiving node) is configured to receive the RTP encapsulated streams generated by the encapsulator 104, and further comprises logic (e.g., software, hardware, or a combination of both) that provides retransmitted packets (e.g., RTP-encapsulated) responsive to retransmission requests from the customer premises 114, processes RTCP reports from the customer premises 114 (e.g., via RTCP analysis logic 118)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of using the system of generating TRP and mapping and generating both the packet sequence number and the timestamp (Fig. 5 and [0073]) as taught, by Begen into the teachings of Ojala in view of Schoppmeier invention. One would have been motivated to do so in order to the system enable for converting a bit pattern from fields of a source stream packet into a bit pattern representing the fundamental identifying characteristics in the packets of the output stream by the RP (i.e., receive and process) system, thus enabling generation of the output stream with the same fundamental characteristics from the same source stream.
Regarding claims 11 and 20.
Claims 11 and 20 incorporate substantively all the limitation of claim 1 in a receiving node and a method form and are rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Regarding claim 3.
Ojala in view of Begen teaches wherein the processing circuitry is further configured to generate an RTP data packet, wherein the RTP data packet comprises the generated representation of the resource, by: adding at least a part of the generated representation of the resource to a payload of the RTP data packet (Ojala teaches in Para. [0081] the sparse signal transformed into the compressed domain is transmitted to the sensor node network manager..., the transform coefficients may be quantized and packetized in for example JavaScript Object Notation (JSON) data structure in real-time protocol (RTP) payload and also Para. [0203] teaches RTP payload. Further Begen teaches in Para. [0076] each RP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp. Actually, if all the RP systems 110 receive the same first packet, by default they use that packet as the seed and produce identical RTP streams).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of using the RTP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp ([0076]) as taught, by Begen including into the teachings of Ojala in view of Schoppmeier invention. One would have been motivated to do so in order to the system for performing rating and quality measurement for digital broadcast viewers in a communication environment in an efficient manner.
Regarding claim 4.
Begen further teaches wherein the processing circuitry is further configured to generate an RTP data packet, wherein the RTP data packet comprises the generated representation of the resource, by: mapping information from at least one field in the representation to a header field of the RTP data packet (Begen teaches in para. [0017] also builds a mapping stream, the latter describing which transport stream packets correspond to which RTP packets based on a correlation of identifying information or stream parameters from the RTP headers and the transport layer of, for instance,…, where the mapping stream is used to enable local, coordinated RTP stream generation and subsequent RTCP reports (as well as facilitate packet-level repair, retransmission, etc.), such as over an IP connection and further, Begen teaches in Par. [0078] the PCR/PTS/DTS values of different source stream packet flows generated by different source video encoders will be different. One or more of the techniques described herein are directed to coordinating the RTP streams produced by different RP systems 110 from the same source stream and further teaches in Para. [0076] each RP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp. Actually, if all the RP systems 110 receive the same first packet, by default they use that packet as the seed and produce identical RTP streams).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of using the RTP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp ([0076]) as taught, by Begen including into the teachings of Ojala in view of Schoppmeier invention. One would have been motivated to do so in order to the information is used as input to the second mapping function to determine the timestamps for the successive packets. (Begen. Para. [0072]).
Regarding claim 5.
Ojala in view of Begen further teaches wherein the processing circuitry is further configured to map information from at least one field in the representation to a header field of the RTP data packet by: mapping information from a time field of the representation to a field of the RTP data packet (Ojala teaches in Para. [0081] the sparse signal transformed into the compressed domain is transmitted to the sensor node network manager..., the transform coefficients may be quantized and packetized in for example JavaScript Object Notation (JSON) data structure in real-time protocol (RTP) payload and also Para. [0203] teaches RTP payload. Further Begen teaches in Para. [0076] each RP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp and Begen further teaches in para. [0076] each RP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp. Actually, if all the RP systems 110 receive the same first packet, by default they use that packet as the seed and produce identical RTP streams).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of using the RTP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp ([0076]) as taught, by Begen including into the teachings of Ojala in view of Schoppmeier invention. One would have been motivated to do so in order to the information is used as input to the second mapping function to determine the timestamps for the successive packets. (Begen. Para. [0072]).
Regarding claim 6.
Ojala in view of Begen further teaches wherein the processing circuitry is further configured to map information from a time field of the representation to a timestamp field of the RTP data packet by setting a value of the timestamp field of the RTP data packet to be the value of the time field of the representation (Ojala teaches in Para. [0081] the sparse signal transformed into the compressed domain is transmitted to the sensor node network manager..., the transform coefficients may be quantized and packetized in for example JavaScript Object Notation (JSON) data structure in real-time protocol (RTP) payload and also Para. [0203] teaches RTP payload. Further Begen teaches in Para. [0076] each RP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp and Begen further teaches in para. [0076] each RP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp. Actually, if all the RP systems 110 receive the same first packet, by default they use that packet as the seed and produce identical RTP streams).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of using the RTP system 110 uses the same packet as a "seed" for the mapping functions to generate the same RTP timestamp ([0076]) as taught, by Begen including into the teachings of Ojala in view of Schoppmeier invention. One would have been motivated to do so in order to the information is used as input to the second mapping function to determine the timestamps for the successive packets. (Begen. Para. [0072]).
Regarding claim 9.
Ojala in view of Begen teaches wherein the processing circuitry is further configured to generate a plurality of representations of the resource according to the data model, the plurality of representations comprising a representation pack (Ojala teaches in Para. [0076] the data representation in a given transform domain is sparse in such a manner that the input signal can be later reconstructed using only a subset of the original data);
wherein the processing circuitry is further configured to generate a plurality of RTP data packets, wherein each RTP data packet comprises a generated representation (Begen teaches in Para. [0047] data structure for the mapping stream is provided by the mapping logic 214, and may include (e.g., on a per-RTP encapsulated packet basis) all or a subset of parameters such as RTP sequence number, RTP timestamp, length of the RTP header, entire RTP header, number of cells and corresponding identifier of the cells); and
wherein the processing circuitry is further configured to set a marker bit of the RTP data packet comprising at least one of the first or last representations of the representation pack (Ojala teaches in Para. [0081] each transform coefficient may be scalar quantized and further entropy coded to lower the bit stream size and further teaches in Para. [0076] the data representation in a given transform domain is sparse in such a manner that the input signal can be later reconstructed using only a subset of the original data and Begen further teaches in Para. [0047]-[0048] RTP timestamp, length of the RTP header, entire RTP header, number of cells and corresponding identifier of the cells. The mapping logic 214 builds the data structure as the encapsulation logic 212 encapsulates the MPEG-2TS (MPTS or SPTS) and subsequent reception of all or a portion of the full header enables the RTCP logic 116 to build the entire RTP stream, hence enabling the derivation of RTCP reports).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of including RTP header ([0047]-[0048]) as taught, by Begen into the teachings of Ojala in view of Schoppmeier invention. One would have been motivated to do so in order to a sequence number incremented for each packet to ensure that the continuity of the stream detected from a packet loss.
Regarding claim 13.
Claim 13 incorporates substantively all the limitation of claim 3 in a receiving node and a method form and is rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Regarding claim 14.
Claim 14 incorporates substantively all the limitation of claim 4 in a receiving node and a method form and is rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Regarding claim 15.
Claim 15 incorporates substantively all the limitation of claim 6 in a receiving node and a method form and is rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Regarding claim 16.
Claim 16 incorporates substantively all the limitation of claim 5 in a receiving node and a method form and is rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Regarding claim 18.
Claim 18 incorporates substantively all the limitation of claim 9 in a receiving node and a method form and is rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Ojala in view of Schoppmeier further in view of Begen and further in view of Jeuk et al. U.S. Pub. No. 2018/0255152 A1, (hereinafter Jeuk).
Regarding claim 2. Ojala in view of Schoppmeier further in view of Begen teaches the sending node of claim 1.
Ojala in view of Schoppmeier further in view of Begen does not explicitly teach wherein the data model comprises Sensor Measurement Links, SenML, and wherein the representation of the resource according to the data model comprises a SenML Record.
However, Jeuk teaches wherein the data model comprises Sensor Measurement Links, SenML, and wherein the representation of the resource according to the data model comprises a SenML Record (Jeuk teaches in para. [0041] the fixed context headers 486, 488, 490, 492 include information (e.g., instructions for requesting data, the requested data, etc.) written in Sensor Markup Language (SenML). SenML allows, for example, data gathered by IoT devices to be carried in a variety of protocols. The syntax of SenML includes name, time, value).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of the system of using Sensor Markup Language (SenML) ([0041]) as taught, by Jeuk into the teachings of Ojala in view of Schoppmeier further in view of Begen invention. One would have been motivated to do so in order to the gateway device sends the service function chain packet, which is modified to include that data obtained from the one or more network connected devices, along the service function chain.
Regarding claim 12.
Claim 12 incorporate substantively all the limitation of claim 2 in a receiving node and a method form and are rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ojala in view of Schoppmeier further in view of Begen and further in view of Agarwal et al. U.S. Pub. No. 2018/0041934 A1, (hereinafter Agarwal).
Regarding claim 10. Ojala in view of Schoppmeier further in view of Begen the sending node of claim 4.
Ojala in view of Schoppmeier further in view of Begen does not explicitly teach wherein the processing circuitry is further configured to map information from at least one field in the representation to a header field of the RTP data packet by: mapping information from a name field of the representation to a Synchronization Source, SSRC, field of the RTP data packet.
However, Agarwal teaches wherein the processing circuitry is further configured to map information from at least one field in the representation to a header field of the RTP data packet by: mapping information from a name field of the representation to a Synchronization Source, SSRC, field of the RTP data packet (Agarwal teaches in Para. [0170] (CSRC) source indicator or list identifies the contributing sources for the payload contained in the packet and SSRC (Synchronization Source Indicator) identifies all sources that were mixed together create a packet the coordinating server may add CSRC in the RTP packet to the core network. Also, see Para. [0291]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of using the system of managing the payload contained in the packet and SSRC (Synchronization Source Indicator) ([0170]) as taught, by Agarwal into the teachings of Ojala in view of Schoppmeier further in view of Begen invention. One would have been motivated to do so in order to create a packet and allows the correct source indication at the receiver in an efficient manner.
Regarding claim 19.
Claim 19 incorporates substantively all the limitation of claim 10 in a receiving node and a method form and is rejected under the same rationale. Furthermore, regarding the limitation of the receiving node, the prior art of record Ojala teaches in the [Abstract] and para. [0018].
Allowable Subject Matter
Claims 7, 8, 16 and 17 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. However, an updated search will need to be performed after the next response from Applicant.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU SHITAYEWOLDETSADIK whose telephone number is (571)270-7142. The examiner can normally be reached M-F.
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, Emmanuel Moise can be reached at 5712723865. 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.
/BERHANU SHITAYEWOLDETSADIK/Primary Examiner, Art Unit 2455
Prosecution Insights