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 Arguments
Applicant’s arguments filed 06/04/2026 have been fully considered.
Prior Art
Applicant argues the prior art fails to teach or suggest “adding the meta data to a data packet, wherein the meta data comprises the one or more attributes, and wherein the meta data comprises a user status of one or more target devices, and wherein 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 the selected VAS until a later time”.
However, Knas discloses the limitations in e.g. (col. 4:25-50). Knas discloses the use of beacon technology where metadata is added to a packet and where the meta data includes attributes comprising a status of the user such as an identifier, and a section and aisle of the store where the user is located. The information is used to determining types of advertisements to insert into a data flow to such as special offers or products in the particular aisle (Knas col. 4:1-67, col. 5:1-55). Accordingly, applicant’s arguments cannot be held persuasive in this regard.
Rejections under 35 USC 112
Applicant’s claims (claim 1 and 14) recite a receiving step and a receiving function respectively. Couched within the receiving step/function is language describing a M2M service layer entity. The claims have been rejected for lack of clarity in that it is unclear whether the recited steps/functions incorporate steps, functions, and/or structural elements of the M2M service layer entity, or alternatively whether the claims are limited to merely receiving meta data.
During prosecution history, applicant has argued, for example, with regards to apparatus claim 14, that applicant the claims limit the claim scope to “a single apparatus receiving meta data” while simultaneously 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” (Remarks of 2/9/2026, pg. 8). The claims remain obfuscated for the reasons presented below with respect to the rejections under 35 USC § 112.
Claim Rejections - 35 USC § 112
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-7, 9-12, 14-15, 17-19, and 21-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 the method merely requires the step of receiving meta data, or alternatively, whether “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” imparts an additional step in the method as performed by the M2M service layer entity.
Claim 14 recites similar language and are addressed by similar rationale. For example, claim 14 is drawn to an apparatus comprising one or more processors which perform a receiving function of: “receive 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 receiving function is merely descriptive of elements beyond the scope of the claimed apparatus and merely requires the function of receiving data. 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, 8, 10-15, 17, and 19-25 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’”) in view of US 10,757,672 to Knas.
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, receiving 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).
3GPP fails to teach but Knas teaches:: adding the meta data to a data packet, wherein the meta data comprises the one or more attributes, and wherein the meta data comprises a user status of one or more target devices, and wherein 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 the selected VAS until a later time (col. 4:1-67, col. 5:1-55, meta data includes attributes comprising a status of the user such as an identifier, and a section and aisle of the store where the user is located. The information is used to determining types of advertisements to insert into a data flow to such as special offers or products in the particular aisle).
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).
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 25 is addressed by similar rationale as claim 1.
Claim 5, 18 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP, Swetina, and Knas 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, and Knas 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.
CONCLUSION
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 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