DETAILED ACTION
This Office action is in response to Applicant's amendment and request for
reconsideration filed on April 27, 2026.
Claims 1-20 are pending.
Response to Arguments
Applicant's arguments, with respect to the 35 U.S.C. 112(a) rejection based on lack of written description have been fully considered but they are not persuasive.
With respect to claims 1, 10, and 19, Applicant states that “[a]s amended, the claim does not require that the service be implemented by fxManager and the Policy Manager, nor does it require the DNS-specific functionality criticized in the Office Action” (see pp. 13), to which the Examiner respectfully disagrees. As amended, the claim still requires a “name service resolution service”, i.e., "receiving, at a name resolution service executing within the software-defined network and communicating over a virtual fabric, a request associated with the fxDeviceApp… ”, etc.. Furthermore, a person having ordinary skill in the art would understand the “name resolution service” is in reference to the DNS Server 1150 (see Fig. 11) of Applicant’s specification, as the DNS Server is the only service or element mentioned that would be capable of performing name resolution.
However, the DNS Server 1150, appears to only be used to resolve the initial FQDN of the fxManager upon boot-up of the fxDevice (see Fig. 11, and ¶0074, also see “Secure Boot”, ¶0104). Thus, Applicant’s specification fails to adequately describe the specific features of:
“receiving at a name resolution service (i.e., DNS Server 1150) executing within the software-defined network and communicating over a virtual fabric, a request associated with the fxDeviceApp;
retrieving, by the name resolution service (i.e., DNS Server 1150) from the application manager, deployment information identifying live and active instances associated with the fxDeviceApp and associated zones;
selecting, by the name resolution service (i.e., DNS Server 1150), an active instance based on the deployment information and a zone of a requester in accordance with administrator polices enforced by a policy manager; and
returning, by the name resolution service (i.e., DNS Server 1150), information identifying the selected active instance to the requester within the software-defined network in a message format compatible with the messaging of the virtual fabric.”
Moreover, although applicant is free to be his or her own lexicographer, where applicant acts as his or her own lexicographer to specifically define a term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999).
In this case, however, the specification not only does not redefine the term “name resolution service”, but the term “name resolution service” doesn’t even appear anywhere in Applicant’s specification. As such, a person having ordinary skill in the art would understand the term, as is customarily known in the art (see for example, “name resolution”, Newton's Telecom Dictionary, 26th edition, Flatiron Publishing Inc., 2011, p. 780), as referring to a service that resolves names (e.g., FQDN) to network addresses (i.e., IP addresses), i.e., DNS Server 1150 of Applicant’s specification.
Similar to claim 1, as per claims 4/13, even assuming “the specification expressly identifies Policy Manager 428g as responsible for execution and implementation of administrator-set policies and further disclosing zoning and deployment context” (see pp. 17 of Applicant’s Remarks), the specification still fails to show the integration of the policy manager with a name resolution service, to support the limitation of “selecting, by the name resolution service (i.e., DNS Server 1150), an active instance (see claim 1) … wherein selecting the active instance comprises applying zone specific policies enforced by the policy manager based on deployment context” (see claim 4).
Similar to claim 1, as per claims 5/14, even assuming “the specification repeatedly describes fxManager as the lifecycle manager for fxApps and further explains that it performs application provisioning , de-provisioning, repository handling, inventory, and accounting of live and active software instances” (see Remarks, pp. 18), the specification still fails to show the integration of the name resolution service (i.e., DNS Server 1150) using state information to identifying the active instance, i.e., “wherein the application manager comprises fxManager and maintains state information used by the name resolution service to identify the active instance.”
Similar to claim 1, as per claims 6/15, even assuming “the specification supports use of load and status information in managing the distributed system (see Remarks pp. 18)”, the specification still fails to show the use of load and status information by the name resolution service (i.e., DNS Server 1150) as currently claimed (i.e., “….selecting, by the name resolution service (i.e., DNS Server 1150), an active instance (see claim 1) … wherein selecting the active instance is based on health or load information associated with the active instance” (see claim 4).
Similar to claim 1, as per claims 7/16, even assuming “[t]he specification discloses that applications may expose APIs to be used by other applications and describes client application and server application roles in which the client makes requests and the server serves the requests” (see pp. 19 of Applicant’s remarks), Applicant’s specification still fails to describe “…receiving, at a name resolution service (i.e., DNS Server 1150) executing within the software-defined network and communicating over a virtual fabric” (see claim 1) “…wherein the request is received through an application-layer interface and the information identifying the selected active instance is returned through the application-layer interface” (see claim 7).
Similar to claim 1, as per claims 8/17, even assuming “[t]he specification describes intra-app messaging between corresponding application instances in different fxDevices, inter-app messaging governed by administrator policy, and zoned deployment” (see pp. 19 of Applicant’s remarks), Applicant’s specification still fails to describe “…receiving, at a name resolution service (i.e., DNS Server 1150) executing within the software-defined network and communicating over a virtual fabric” (see claim 1) “…wherein the request originates from a second fxDeviceApp executing in a different zone of the distributed software-defined network” (see claim 8).
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.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
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 of carrying out his invention.
Claims 1-20 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.
As noted in MPEP §2161.01: “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed.”
In this case, as per claim 1, the following claimed computer functions were not described in the specification in such a way (e.g., including steps/procedure for performing the claimed computer function) as to reasonably convey to one skilled in the relevant art that the inventor at the time the application was filed, had possession of the claimed invention:
“receiving at a name resolution service executing within the software-defined network and communicating over a virtual fabric, a request associated with the fxDeviceApp;
retrieving, by the name resolution service from the application manager, deployment information identifying live and active instances associated with the fxDeviceApp and associated zones;
selecting, by the name resolution service, an active instance based on the deployment information and a zone of a requester in accordance with administrator polices enforced by a policy manager; and
returning, by the name resolution service, information identifying the selected active instance to the requester within the software-defined network in a message format compatible with the messaging of the virtual fabric.”
Even though Applicant’s specification, see pg. 41 (¶0104) and pg. 64 (see “No. 53”), vaguely mentions the use a name resolution service (i.e., DNS), pp. 41 and pp. 64, do not support the particular functions of the DNS as recited in the claims.
As per claims 4-8, similar to claim 1, and for reasons noted in the ‘Response to Arguments’ section above, none of the functions performed by the name resolution service (i.e., DNS) recited in claims 4-8 are described in the specification in such a way (e.g., including steps/procedure for performing the claimed computer function, see MPEP §2161.01) 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.
Claims 10, 13-17, and 19 recite substantially identical subject matter as claims 1 and 4-8 and are therefore 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, for the same reasons as noted above.
Claims not specifically addressed are rejected under 35 U.S.C. 112(a) based on their dependency to one or more claims mentioned above.
Allowable Subject Matter
Claims 1-20, though rejected under 35 U.S.C. §112(a), are allowed over the prior art.
The following is an examiner’s statement of reasons for allowance:
For reasons already noted in previous correspondences, the prior art is not seen to teach or render obvious to one of ordinary skill in the art, before the earliest effective filing date of the claimed invention, in the specific combinations and manner recited within the claims, the features of:
“…executing, on a first network element, an fxDeviceApp wherein service metadata associated with the fxDeviceApp is registered with an application manager;
receiving, at a name resolution service executing within the software-defined network and communicating over a virtual fabric, a request associated with the fxDeviceApp;
retrieving, by the name resolution service from the application manager, deployment information identifying live and active instances associated with the fxDeviceApp and associated zones;
selecting, by the name resolution service, an active instance based on the deployment information and a zone of a requester in accordance with administrator policies enforced by a policy manager; and
returning, by the name resolution service, information identifying the selected active instance to the requester within the software-defined network in a message format compatible with messaging of the virtual fabric.”
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRENDAN HIGA whose telephone number is (571)272-5823. The examiner can normally be reached Monday - Friday 8:30 AM - 5:00 PM.
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, James Hwang can be reached at 571-272-4036. 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.
/BRENDAN Y HIGA/Primary Examiner, Art Unit 2447
Prosecution Insights