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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed 2/9/2026 has been entered.
Response to Arguments
Applicant’s arguments filed 2/09/2026 have been fully considered.
In response to the previous rejections for lack of clarity, Applicant has amended exemplary claim 1 as follows: "and wherein the second network domain is an Internet domain."
Applicant’s amendments are intended to clarifying the previous “obtaining” step such that is read as a single receiving step. (Remarks of 2/9/2026, pg. 8: “In response to the rejection, Applicant has amended claim 1 herein to recite, in part: "receiving meta data, from an M2M service layer entity deployed in a second network domain outside of the first network domain, wherein the second network domain is outside of the transport network domain of the operator" (emphasis added). Applicant therefore respectfully submits that the amended element is clear, in that it describes a network entity receiving meta data from another entity”.) Applicant has amended apparatus claim 14 in a similar manner to clarify that the claim encompasses a single apparatus which merely receives data from another entity.
Applicant argues the prior art fails to teach or suggest the recited features beyond the “receiving” step. For example, with regards to exemplary claim 1, applicant argues the prior art fails to teach or suggest “wherein the second network domain is an Internet domain” because the prior art element “PCRF” is not deployed in an internet domain (Remarks of 2/9/2026, pg. 9-10). Applicant’s arguments are not persuasive in this regard as applicant has amended the claim in order to limit the claim scope to a single network entity while arguing that the scope of the claim should extend beyond the single network entity.
Likewise, with regards to apparatus claim 14, applicant has amended the claim in order to limit the claim scope to “a single apparatus receiving meta data” (Remarks of 2/9/2026, pg. 8) while arguing that the claim scope should be extended to cover various network elements and/or functions disparate from the single apparatus, i.e. the “M2M service layer entity” deployed “in an internet domain”.
Applicant argues the prior art fails to teach “wherein the second network domain is an Internet domain”. Applicant’s arguments are not persuasive as one of ordinary skill in the art would understand that 3GPP technology allows mobile subscribers data access via the internet and that he various 3GPP nodes are internet nodes, processing both uplink and downlink traffic to the internet as discussed in the 3GPP standards document and as illustrated in at least fig. 6.1.2.1.1-1.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-2, 4-12, 14-19, and 21-24 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites: “receiving meta data, from an M2M service layer entity deployed in a second network domain outside of the first network domain, wherein the second network domain is outside of the transport network domain of the operator, and wherein the second network domain is an Internet domain". Applicant’s specification is devoid of support for such features. Namely, applicant’s specification fails to describe in such a way as to reasonably convey to one skilled in the relevant art how a step of data reception (i.e. “receiving meta data”) would comprise any function or step to affect the positioning and source of the data, e.g. for the source of the data to be positioned in a certain domain “outside of the transport network domain of the operator, and wherein the second network domain is an Internet domain”. Claim 14 is addressed by similar rationale.
Claims 23 recites “transmitting, to the M2M service layer entity deployed in the second network domain outside of the first network domain, an indication that the one or more VASs are available to process downlink traffic received from the M2M service layer entity”. The specification is devoid a description of such a transmission step with the specification only describing “the service layer may have been pre-provisioned with information about which VASs are available” (see applicant’s specification ¶ 79). Claim 24 recites similar language and is addressed by similar rationale.
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim(s) 1-2, 4-15, 17-22 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Regarding claim 1, applicant' s recitation of “receiving meta data, from an M2M service layer entity deployed in a second network domain outside of the first network domain, wherein the second network domain is outside of the transport network domain of the operator, and wherein the second network domain is an Internet domain" would have been unclear to one of ordinary skill in the art. It is unclear whether and how the language following the receiving step modifies the obtaining step and how or what that modification is, or alternatively, whether the language is merely non-functionally descriptive of the obtaining step. It is further unclear whether the method requires a transmission step enacted by the M2M service layer entity of the second network domain followed by a reception step (i.e. receiving metadata) or whether the claim merely requires a data reception step. To overcome the rejections, applicant should clarify whether the method is intended to be a method enacted by a single party, or whether the method requires steps performed by multiple parties.
The remaining independent claims recite similar language and are addressed by similar rationale. For example, claim 14 is drawn to an apparatus which performs a receiving step of : “receiving meta data, from an M2M service layer entity deployed in a second network domain outside of the first network domain, wherein the second network domain is outside of the transport network domain of the operator, and wherein the second network domain is an Internet domain”. It is unclear whether the apparatus includes any structural or functional elements of M2M service layer entity or, alternatively, whether the language following the obtaining function is merely descriptive of elements beyond the scope of the claimed apparatus. Dependent claims not addressed are rejected for incorporating the deficiencies of their respective parent claims.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-2, 4, 10-15, 17, and 19-24 are rejected under 35 U.S.C. 103 as being unpatentable over “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture Enhancement for Flexible Mobile Service Steering (Release 13)”, hereinafter “3GPP” in view of “Toward a Standardized Common M2M Service Layer Platform: Introduction to oneM2M” to Swetina et al (hereinafter “Swetina’”).
Regarding claim 1,
3GPP teaches a method for a Machine to Machine (M2M) service supporting service capabilities through a set of Application Programming Interfaces (APIs), the method comprising:
deploying, in a first network domain, a plurality of value added services (VAS) with a traffic steering function, wherein the first network domain is outside of a transport network domain of an operator (4.1, 5.1, 5.1, 6.1.1.1.1-6.1.1.1.3.1, value added services deployed)
provisioning a policy provision for the plurality of VASs (4.1, 5.1, 5.1, 6.1.1.1.1-6.1.1.1.3.1, policy provisioning and addition of traffic steering); wherein the policy comprises an indication that at least one selected VAS of the plurality of VASs is based on one or more attributes associated with an addressed resource (4.1, 5.1, 5.1, 6.1.1.1.1-6.1.1.1.3.1, policy provisioning and addition of traffic steering related information according to attributes associated with addressed resources);
receiving meta data, from a service layer entity deployed in a second network domain outside of the first network domain, wherein the second network domain is outside of the transport network domain of the operator, and wherein the second network domain is an internet domain (5.1.1, 6.1.1.1, 6.1.1.1, 6.1.3, 6.1.2.1.1, 6.1.2.1.3.3, 6.1.4.1.5.1, 6.1.4.1.6.2, fig. 6.1.4.1.1-1, obtaining metadata from PCRF/PCEF of another domain; PCEF is internet node processing both uplink and downlink traffic from the internet see fig. 6.1.2.1.1-1);
adding meta data to a data packet based on the policy, wherein the meta data comprises the one or more attributes (6.1.1.1.1, 6.1.2.1.3.3, 6.1.4.1.5.1, 6.1.4.1.6.2, 6.1.1.1.1, metadata added to packets for traffic steering purposes where metadata comprises attributes of addressed resources); and
sending the data packet to the traffic steering function, wherein the meta data is used by the traffic steering function for steering the data packet through the selected VAS (section 6.1.1.1.1, 6.1.2.1.3.3, 6.1.4.1.5.1, 6.1.4.1.6.2, 6.1.1.1.1, 6.1.1.1.3.2, packet including metadata allows traffic steering to network services).
3GPP fails to teach but Swetina teaches the service layer entity is a M2M service layer entity (pg. 20-21, M2M service entity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the teachings of Swetina. The motivation to do so is that the teachings of Swetina would have been advantageous in terms of facilitating system extension, support for new services, and interoperability between systems as well as to facilitate smart grids and smart city infrastructure (Swetina, abstract, introduction, pg. 20-23).
Regarding claim 2, 15,
3GPP teaches:
wherein the at least one selected VAS comprises a first VAS and a second VAS, and wherein the one or more attributes includes a sequence in which the first VAS and the second VAS process the data the selected VAS to process the second data packet (6.1.1.1.1, 6.1.1.1.3.1; see also section 6.2.1.3: "The proposed solution provisions a traffic steering policy (TSP) by referencing to a set of pre-configured steering rules (uplink, downlink or both) each one identifying a set of service function(s) including their order". The traffic steering policy is mapped to service chain specific identifiers to route the traffic to the set of VAS- 3GPP, 6.1.4.1.1).
Regarding claim 10,
3GPP teaches:
wherein the policy provision is associated with one or more attributes of traffic (6.1.1.1.1, 6.1.1.1.3.1).
Regarding claim 11,
3GPP teaches:
wherein a policy provisioned by the policy provision indicates one or more attributes of addressed resource for determining if data should be processed by a particular VAS in a particular order (6.1.1.1.1, 6.1.1.1.3.1, policy provisioned determines that a particular service should processes the data initially).
Claim 14 is addressed by similar rationale as claim 1.
Regarding claim 21-22,
3GPP teaches: wherein the first network domain corresponds to an IP network domain of an operator; wherein the traffic steering function is deployed in an IP network domain of an operator (see fig. 6.1.1.1.1-1, 6.1.1.1.1-2, 6.1.4.1.1-1).
Regarding claim 4, 17,
3GPP fails to teach but Swetina teaches:
wherein the one or more attributes include a reference of the selected VAS or a type of a Create, Retrieve, Update, and Delete (CRUD) operation (pg. 22, CRUD commands). Motivation to include Swetina is the same as presented above.
Regarding claim 12, 19,
3GPP fails to teach but Swetina teaches:
wherein the M2M service is provided as a middleware service for IoT services, the middleware service being a service layer located on top of network protocol stacks (pg. 20-22, 25). Motivation to include Swetina is the same as presented above.
Regarding claim 13, 20,
3GPP fails to teach but Swetina teaches:
wherein the service layer is defined according to ETSI/oneM2M standard (pg. 20-22, 25). Motivation to include Swetina is the same as presented above.
Regarding claim 23-24,
3GPP teaches:
transmitting, to the M2M service layer entity deployed in the second network domain outside of the first network domain, an indication that the one or more VASs are available to process downlink traffic received from the M2M service layer entity (3GPP, section 6.1.4.1.1-6.1.4.1.3, transmission to PCEF/PCRF application detection information including application start/stop).
Claim 5, 18 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP and Swetina in view of US 20030181203 to Cheshire.
Regarding claim 5, 18,
3GPP fails to teach wherein the meta data includes one or more security keys and one or more security algorithm types used by the particular VAS to decrypt and re-encrypt the data packet. However, Cheshire teaches: wherein the meta data includes one or more security keys and one or more security algorithm types to decrypt and re-encrypt the data packet (¶ 27).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the teachings of Brown. The motivation to do so is that the teachings of Cheshire would have been advantageous in terms of providing network security (Cheshire, ¶ 27).
Claim 7, 9 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP Swetina in view of US 20160173634 to Newton.
Regarding claim 9,
3GPP fails to teach: wherein the meta data includes one or more network conditions for determining if traffic should be compressed, re-encoded, encrypted, buffered or cached by the particular VAS.
However, Newton teaches wherein the meta data includes one or more network conditions for determining if traffic should be compressed, re-encoded, encrypted, buffered or cached (¶ 30-35).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the teachings of Newton. The motivation to do so is that the teachings of Newton would have been advantageous in terms of enforcing caching policy (Newton, ¶ 30-35).
Regarding claim 7,
3GPP fails to teach: wherein the meta data includes a sleep schedule associated with one or more addressed devices, wherein the sleep schedule is associated with determining if data should be cached by the particular VAS and a duration of time associated with caching the data.
However, Newton teaches wherein the meta data includes a sleep schedule associated with one or more addressed devices, wherein the sleep schedule is associated with determining if data should be cached by the particular VAS and a duration of time associated with caching the data (¶ 30-35, meta data including caching policy specifying duration of time associated with caching). Motivation to include Newton is the same as presented above.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over 3GPP and Swetina in view of US 10,757,672 to Knas.
Regarding claim 8,
3GPP fails to teach: wherein the meta data includes a user status of one or more target devices and the user status is associated with determining one or more types of advertisements to be inserted in a flow or if a software download should be buffered in a selected VAS until a later time. However, Knas teaches: wherein the meta data includes a user status of one or more target devices and the user status is associated with determining one or more types of advertisements to be inserted in a flow or if a software download should be buffered in a selected VAS until a later time (col. 4:25-50).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the teachings of Knas. The motivation to do so is that the teachings of Knas would have been advantageous in terms of facilitating the provisioning of advertisement content (Knas, col. 4:25-50).
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RYAN J JAKOVAC whose telephone number is (571)270-5003. The examiner can normally be reached on 8-4 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar A. Louie can be reached on 572-270-1684. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RYAN J JAKOVAC/Primary Examiner, Art Unit 2445
Prosecution Insights