DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This Office Action is in response to the submission filed 2025-10-21 (herein referred to as the Reply) where claim(s) 1-15, 19, 21, 25-27 are pending for consideration.
35 USC §112(f) - Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
The identified claim limitation(s) is/are:
Claim(s) 9
a group of radio devices
generic holder: a group of radio devices
functional language: ...
35 USC §112(b) – Claim Rejections
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) is/are rejected under 35 U.S.C. 112(b) for not particularly pointing out and distinctly claiming the subject matter of the invention.
Claim(s) 1, 19, 21 and 2-15, 25-27
The claim(s) recite variants of:
performance management (PM) event
It is unclear what is the exact technical meaning that the phrase “PM” imparts on the word “event” (i.e., what makes an event particularly a PM-type event?)
This unclarity is also echoed in written opinion of related case PCT/EP2020/073320 where the claims are effectively the same. The writer of the written opinion is also confused as to what exactly a “PM event” is. The Examiner looked to several places for context and guidance but is still confused:
3GPP TS documents do not define a “PM event.” For example, Examiner looked at disclosed citation 3GPP document TS 32.425, version 16.5.0 (from IDS submitted 2023-02-20) but found no clear definition of “PM event.” In fact, the phrase “PM event” is not in the document at all. There are a variety of events disclosed in TS 32.425, version 16.5.0 – e.g., a discrete event registration, measured event, etc. It is unclear if “PM event” is intended to encompass all these events and what particularly makes them “PM”?
The Specification gives examples of what a “PM event” is but the lexicon and name conventions do not match any 3GPP definition:
[0112] The device 100 comprises one or more instances of an EventAgentLM in which the PM buffers to be monitored by the PM buffer status monitoring unit 104 are comprised. According to the invention, each instance of the EventAgentLM is (e.g. autonomously and/or independently) responsible for the detection of a high load and/or overload state (also denoted as high load and/or overload condition). After detecting a high load and/or overload condition, each instance of the EventAgentLM (e.g. autonomously and/or independently) automatically reduces an observability level of PM events according to preconfigured settings. Each instance of the EventAgentLM is (e.g. autonomously and/or independently) responsible also for informing the configuration part of the network node (e.g. eNB) that the reduced observability mode is active.
It appears the “PM event” corresponds or is related to “EventAgentLM.” The Examiner has found no instant “EventAgentLM” in the 3GPP website or general google search. It is unclear where this term originated from. Since the Examiner can not find 3GPP definition or use of this term, he can assume it is potentially the Applicant’s own lexicon.
Similar terms that cannot be readily understood is also at para. 0114-0118 – basically all the components of FIG. 3 (e.g., LmMonCntMapPT, EventAgentNODE ) where the Examiner could not find these terms in any 3GPP documents and therefore does not understand what they are. Consequently, they give no further context as to what a “PM event” or “PM buffer” is.
The Specification gives examples of what a “PM event” can comprise but not a clear definition since the examples themselves also use “PM” or other adjectives adjective without further clarification:
[0020] A PM event may also be denoted as, or may be represented by, PM traffic. A PM event may comprise, or may be associated with, a PM counter. For example, the stepping of a PM counter may depend on a target observation level. If the target observation level refers to counters and events (e.g., is “COUNTER AND EVENT”), all counters will be stepped. If the target observation level relates to KPI (e.g., is “KPI”), only KPI-related counters will be stepped.
[0021] A PM event may comprise at least one of an Evolved Packet System (EPS) event and a 5G System (5GS) event. Alternatively or in addition, the PM counter may comprise at least one of an EPS counter and a 5GS counter. Alternatively or in addition, a PM event may relate to a mission critical service (MCS).
In this case, what is a “PM” counter or “EPS” event or “5G” event? In the paragraphs above, examples are given what an PM even can comprise, but the examples also unclear for similar reasons as they simply rely upon an adjective being added to the word “event” where it is unclear as to what is the exact technical meaning of the adjective.
Dependent claims do not cure the deficiencies of the base/intervening claims as discussed herein and are therefore rejected for at least the same reasons.
Claim(s) 1, 19, 21 and 2-15, 25-27
The claim(s) recite variants of:
performance management (PM) buffer
It is unclear what is the exact technical meaning that the phrase “PM” imparts on the word “buffer” (i.e., what makes an buffer particularly a PM-type buffer?)
This unclarity is also echoed in written opinion of related case PCT/EP2020/073320 where the claims are effectively the same. The writer of the written opinion is also confused as to what exactly a “PM buffer” is. The Examiner looked to several places for context and guidance but is still confused:
3GPP TS documents do not define a “PM buffer.” For example, Examiner looked at disclosed citation 3GPP document TS 32.425, version 16.5.0 (from IDS submitted 2023-02-20) but found no clear definition of “PM buffer.” In fact, the phrase “buffer” is not in the document at all.
The Specification lacks a definition. It appears the “PM buffer” corresponds or is related to “EventAgentLM.” The Examiner has found no instant “EventAgentLM” in the 3GPP website or general google search. It is unclear where this term originated from. Since the Examiner can not find a 3GPP definition or use of this term, he can assume it is potentially the Applicant’s own lexicon.
Similar terms that cannot be readily understood is also at para. 0114-0118 – basically all the components of FIG. 3 (e.g., LmMonCntMapPT, EventAgentNODE ) where the Examiner could not find these terms in any 3GPP documents and therefore does not understand what they are. Consequently, they give no further context as to what a “PM event” or “PM buffer” is.
Dependent claims do not cure the deficiencies of the base/intervening claims as discussed herein and are therefore rejected for at least the same reasons.
Response to Arguments
The following arguments in the Reply have been fully considered and are persuasive:
USC112(f):
With regards to “cell load module” and “central load module,” the applicant has argued on the record that these terms inherently include structure of software.
The following arguments in the Reply have been fully considered but they are not persuasive:
USC112:
With regards to “radio devices” the Reply argues that “Clearly, a radio device is thus simply any device capable of transmitting or receiving radio signals” but this is not identifying structure but simply describing functionality. What is the structure of this device that is capable of doing these things? A “radio device” is generic enough to cover sub-components of an antenna array, an entire antenna array, a DSP processor, an network node, an entire phone, etc.…such that it is unclear as to what the specific structure the term “radio device” inherently includes.
The Reply provides para. 0075 as an example of structures: a portable station, a MTC, an IOT device, UE, table computer, vehicle, etc. Para. 0075 recites different structures…so which structure is the Applicant saying is the structure?
In summary, “radio device” is generic phase describing all the device type of para. 0075. This is literally the definition of 112(f) – a claimed generic phrase without reciting specific structure and relying upon the Specification to provide exemplary examples of that generic phrase. If the Applicant does not want 112(f) invoked, replace the generic term “radio device” with a specific structure (e.g., a mobile phone).
112(b)
“PM Event”
The Examiner disagrees one skilled in the art would readily understand the definition of a “PM event” in light of the Specification. The Reply offers para. 0020 and 0021 (using US publication citation):
[0020] A PM event may also be denoted as, or may be represented by, PM traffic. A PM event may comprise, or may be associated with, a PM counter. For example, the stepping of a PM counter may depend on a target observation level. If the target observation level refers to counters and events (e.g., is “COUNTER AND EVENT”), all counters will be stepped. If the target observation level relates to KPI (e.g., is “KPI”), only KPI-related counters will be stepped.
[0021] A PM event may comprise at least one of an Evolved Packet System (EPS) event and a 5G System (5GS) event. Alternatively or in addition, the PM counter may comprise at least one of an EPS counter and a 5GS counter. Alternatively or in addition, a PM event may relate to a mission critical service (MCS).
As iterated in the rejections, a major issue is that the Specification fails to give a clear definition of what a “PM event” but rather gives optional, exemplary examples. Using para. 0020 a PM event “may be” presented by PM traffic – due to the language “may be” we don’t if a PM event is PM traffic or not, nor do we know the criteria in which PM traffic will definitely be an PM event.
The problem with the Specification is that it is written without clear definition with “may” and “may be” such that one skilled in the art would not know the definition of a “PM event,” but rather simply identify a few disclosed potential scenario which it possible could – that is not a clear definition.
Further the Specification fails to substantiate the Reply’s alleged definition that PM event “clearly refers to an event related to the monitoring of network performance of a network node.” Looking at para. 0021, a PM event can comprise an EPS event. An EPS is not a network node but is rather system of backhaul, network architecture, not a particular network node. Similar comments apply to “5GS event” where a 5GS is not a network node. Consequently, the Reply’s own alleged definition does not fit at least one example in the provide in the Specification. Accordingly, it appears the Applicant is having trouble defining it as well; if the Applicant own example demonstrates it is difficult to define what a PM event in in view of the Specification, how can one skilled in the art do so?
“PM buffer”
The Reply purports that “buffer” is a well understood term in the art. The Examiner agrees. The rejection applied to the term “PM buffer” was primarily due to the adjective “performance buffer” where it is unclear what is the exact technical meaning that the phrase “PM” imparts on the word “buffer” (i.e., what makes a buffer particularly a PM-type buffer?)
The Reply alleges the definition of “PM buffer simply is referring to a region in memory used for performance monitoring, such as storing PM events” but in view of the rejection of “PM event” as discussed herein, the definition relies upon a term/phrase that is unclear. The Examiner believes if the Applicant is able to persuade the definiteness of the terms “PM” and “PM event” that the term “PM buffer” will by consequence also become definite and therefore recommends efforts be concentrated in the “PM Event” rejection(s).
Conclusion
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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDRE TACDIRAN whose telephone number is 571-272-1717. The examiner can normally be reached on M-TH, 10-5PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Rutkowski can be reached on 571-270-1215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
/ANDRE TACDIRAN/
Primary Examiner, Art Unit 2415
Prosecution Insights