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 .
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 on 11/18/2025 has been entered.
Response to Arguments
Applicant's arguments filed 11/18/2025 have been fully considered but they are not persuasive. The applicant’s arguments regarding the first written description issue fail to address the issue. The applicant argues that the Examiner misinterprets the role of Figure 13 but fails to explain what “protocol stack” they have disclosed for communication between the broker system as a whole and the publisher/subscriber devices. The applicant is claiming that they invented a protocol stack yet the applicant fails to explain where they have disclosed the protocol stack claimed. The applicant argues that the 3GPP environment and the control planes’s functions provide sufficient context for one skilled in the art to understand the protocols comprising this interface stack, but provides no evidence for this assertion. 2161.01(I) of the MPEP is explicit that claiming a function without disclosing how the function is performed, is cause for a written description rejection. The applicant has not attempted to explain how the functions of the control plane are performed and instead argues that someone skilled could figure it out despite a lack of evidence for this conclusion. Regarding the pub-sub layer the applicant argues that the specification describes the functions performed by it but, again, describing a function does not necessarily meet written description if it is not clear how the function is performed, from a technical perspective, from reading the written description. The applicant argues that the applicant provides “the necessary linking disclosure” regarding the functions, but as pointed out in the rejection, the disclosure does not coherently describe the functions performed or how they operate.
Regarding the second written description issue, the applicant does not address the substance of the rejection. The rejection shows how the 3GPP documentation relied upon in the disclosure does not provide support for the claimed subject matter. The applicant does not address the specifics of the rejection. The applicant is now trying to state that the invention is suggested by other 3GPP documentation despite not originally disclosing such and not incorporating any of this documentation by reference.
Regarding the 112b rejection, the applicant fails to explain how the specification discloses embodiments, other than that shown in Figure 13, that allows for a single protocol stack for communication between the over broker system and the end devices. It would be helpful if the applicant explained what embodiment they are claiming if they are not covering Figure 13.
Regarding the argument that Walker does not teach the step of allocating communication resources for use by a user plane, the applicant ignores the breadth of the disclosure. This limitation is disclosed as covering allocating a sidelink connection. This is exactly what the server is doing when it allocates the communication information for the channel between the clients that form the publisher and the subscriber. The applicant has not disclosed any technology for allocating resources that is patentable over Walker.
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-7 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.
Written Description Issue #1
Claim 1 features the following limitation:
circuitry programmed to:
communicate with the one or more publisher devices using a first protocol stack;
communicate with the plurality of subscriber devices using the first protocol stack; and
broker the data distribution between the publisher device and the at least one subscriber device, including: participating in a control plane established between the publisher device and the broker system and between the at least one subscriber device and the broker system using the first protocol stack,
There are two problems with the applicant’s limitation. First, the applicant did not disclose a single protocol stack that is used for control plane communication. Second, the applicant did not disclose how the functions of the Pub-sub application layer are actually performed in order to broker by participating in a control plane using a first protocol stack in the manner claimed.
The first problem with the applicant’s claim is that the applicant did describe participating in a control plane using a single “first protocol stack” as claimed. The paragraph beginning at the final line of page 25 of the applicant’s disclosure describes Figure 13 as illustrating a block diagram of the “control plane protocol stack”. Figure 10 and the corresponding disclosure show the broker as covering all of relay 50, gNB 51, 5GC 52, and MEC 53. As illustrated in Figure 13, each of the four devices that make up the broker implements its own protocol stack that is unique to that specific device for implementing communication and control plane functions between the MEC cloud (which is disclosed as holding registration information for the publishers and the subscribers) and the UEs which embody the publisher and subscribers. The applicant does not disclose any embodiment where only one of the disclosed protocol stacks is used.
The second problem with the disclosure is that the applicant does not describe how the control plane is implemented according to control plane stack. The following is disclosed about the control plane from page 25, line 32-page 26, line 25:
Fig. 13 schematically illustrates in block diagram an embodiment of a control plane protocol stack.
The control plane is in charge of management such as registration of publisher and subscriber UEs, mapping between publisher and subscriber(s), resource allocation for sidelink and so on.
The pub-sub protocol is terminated at UE and at MEC (cloud) in the application layer. However,
some of pub-sub functions relies on network functions like resource management, QoS management, security and so on. Therefore, the pub-sub layer needs to request the necessity functions to 3GPP protocols such as core network (5GC) and radio access (NR, LTE).
Thus, a network-based API ("Application Programming Interface") in 5GC is proposed, which also
applies to other embodiments of the present disclosure.
The control plane of network-based API with 3GPP access relay (broker device 50) and UEs (31/32(32a, 32b)) is shown in Fig. 13 (see also 3GPP TS 23.501 V15.4.0 (2018-12), 8.2; 3GPP TS 29.500 V16.4.0 (2020-06), 5.1; 3GPP TS 38.300
V15.7.0 (2019-09), 4.4). Basically, Fig. 13 is a consolidated figure of different interfaces below:
" between 5G core network node and external API (MEC) protocol stack;
" between RAN node and core node protocol stack;
" between UE and gNB (NAS: between UE and core network); and
" between UE and external (broker).
The 5G core network supports service-based architecture. An application can request the service via application interface (API) to 3GPP core network. The pub-sub protocol generates the message and parameters and describes it with a common format (e.g. JSON ("Java Script Object Notation")). The20 description of message and parameter is sent from MEC to 5GC with HTTP2 protocol and other low layer protocols.
The new pub-sub APIs for pub-sub model are proposed. One APIs implementation is between MEC and 5GC via HTTP2. The other APIs implementation is between UE and MEC (pre-configuration or via user plane).
This is not a coherent disclosure of a “protocol stack”. The applicant references a “pub-sub protocol” that is implemented at the application layer between the relay 50 and MEC 53, via communication through gNB 51 and 5GC 52. The applicant provides no description of this “pub-sub protocol”. The applicant states that this “pub-sub layer” needs to request necessary functions of 3GPP protocols, but the applicant does not disclose what 3GPP protocols they are referring to. The applicant states that a network-based API in the 5GC device 52 is “proposed”.
It is not clear what the concept of the “control plane of the network-based API with 3GPP access relay (broker device 50) and UEs” is supposed to cover. The network based API is supposed to define the communication which defines the control plane so it is not clear what the applicant is referring to by stating that the “control plane” is part of the “network-based API”. The applicant then, in parenthesis, cites three 3GPP documents but does not explain how these documents relate to any of the control plane, protocol stack, or “network-based API”.
Figure 13 is then described as a “consolidated figure of different interfaces” and lists the interfaces shown in Figure 13. The applicant then states that “the pub-sub protocol generates the message and parameters and describes it with a common format (JSON)” but provides no description of what message and parameters they are referring to. The applicant further states that “the description of message and parameter is sent from MEC to 5GC with HTTP2 protocol and other low layer protocols”, but there is no description of what “the description of” message has to do with the actually message generated by the pub-sub protocol and how sending a message from the MEC 53 to 5GC 52 has anything to do with any of a control plane, protocol stack, or “network-based API”.
The paragraph beginning on line 22 of page 26 states that “the new pub-sub APIs for pub-sub model are proposed” but there is not discussion of any “new” pub-sub APIs previously or how they are “proposed”. This statement is incoherent in the context of what is disclosed previously. This paragraph then references an API between MEC and 5GC and “other APIs implementation” but there is no description of either of these different types of APIs so this statement too is incoherent in the context of what is previously disclosed.
The applicant is claiming the function of using a protocol stack but the applicant’s description of the claimed “first protocol stack” is not coherent. Section 2161.01(I) of the MPEP states when an application is claiming the performance of a function without describing how the function is performed, a written description rejection should be made. In this case the applicant does not provide a coherent description of how the communication and participate in a control plane using the claimed first protocol stack.
Written Description Issue #2
Claim 1 features the following limitation:
providing the publisher device with information that allows the publisher device and the at least one subscriber device to establish the user plane using a second stack that is different from the first protocol stack and participate in the user plane using the allocated communication resources.
The applicant did not describe how to establish a user plane established between the publisher device and the subscriber device using a “second stack” because the applicant did not describe the details of the applicant’s “second protocol stack”. Figure 8 is described as illustrating an embodiment of the user plane protocol stack. The applicant states that they reuse the existing sidelink communication of 3GPP TS 23.303 V13.3.0 (2016-04), 5.1.2.1 but the protocol stack shown in Figure 8 differs from the protocol stack show in section 5.1.2.1 of the 23.303 document. The applicant has added an SDAP layer between the IP and PDCP layers and the applicant uses their specific pub-sub application at the application layer to implement the user plane.
It is not clear how SDAP would be incorporated into the protocol stack shown in 5.1.2.1 of the 23.303 document. There is no description of how SDAP (Service Data Adaptation Protocol) would be implemented between the IP layer and the PDCP (packet data convergence protocol) layer and no evidence on record that such a feature would be so well known as to omit a description of. The applicant does not even use the term SDAP in their disclosure aside from showing it to be part of their user plane protocol stack in Figure 8.
On line 9 of page 23, the applicant describes the pub sub layer as a “new protocol” layer. One reading the disclosure would expect a detailed description of such a “new protocol layer” but the applicant does not provide a description of such a layer. As such the applicant fails to provide any description of the “new” protocol layer that is part of their claimed “second protocol stack” and thus is claiming a function that they do not describe how to implement.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential elements, such omission amounting to a gap between the elements. See MPEP § 2172.01. The omitted elements are: the applicant claiming using a single first protocol stack for communicating between the brokers and publishers and subscribers and for implementing the control plane. However, Figures 10 and 13 of the disclosure show that multiple protocol stacks are implemented in a codependent manner by four different devices, respectively, to perform the claimed communication and control plane. Therefore, a single protocol stack cannot be used without the other protocol stacks being used to implement the applicant’s invention.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-7 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Application Publication Number 2019/0028414 by Walker et al.
As to claim 1, Walker teaches a broker system (server 102) in an internet-of-things network (paragraph 55, the breadth of the description of the devices used covers IoT devices) that based on a publisher-subscriber method for data distribution between one or more publisher devices and a plurality of subscriber devices (clients 104 and 106) where a publisher device of the one or more publisher devices is registered as a publisher for a data category at the broker system in the internet-of-things network and at least one subscriber device of the plurality of subscriber devices is registered as a subscriber for the data category at the broker system in the internet-of-things network (paragraph 110 and 111), the broker system comprising: circuitry programmed to: communicate with the one or more publisher devices using a first protocol stack (paragraphs 110 and 111); communicate with the plurality of subscriber devices using the first protocol stack (paragraphs 110 and 111); and broker the data distribution between the publisher device and the at least one subscriber device, including: participating in a control plane established between the publisher device and the broker system and between the at least one subscriber device and the broker system using the first protocol stack (paragraphs 115 and 120), allocating communication resources for use by a user plane between the publisher and the at least one subscriber device (paragraph 115, the server allocates message types, which are considered communication resources, between the publishing and subscribing clients), and providing the publisher device with information that allows the publisher device and the at least one subscriber device to establish the user plane (ref. no. 1016 in Figure 10 and ref. no. 606 in Figure 6) using a second stack that is different from the first protocol stack (paragraphs 118-120, the message types used between the different clients 104 and 106 are using a different protocol stack as the message types consider different connections between the clients themselves, see paragraph 93, that do not use the server or communicate using the same types of connections) and participate in the user plane using the allocated communication resources (the subscribers communicate using the allocated message types).
As to claim 2, see Figure 6.
As to claim 3, see Figure 6 and Figure 10 and corresponding disclosure.
As to claim 4, see paragraphs 110 and 111.
As to claim 5, see paragraphs 90 and 120 which describe user plane 606 and 1016.
As to claim 6, see Figure 6.
As to claim 7, the mapping shows the direct path as ref. no. 606 and 1016.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS B BLAIR whose telephone number is (571)272-3893. The examiner can normally be reached Monday-Friday 9am-5pm.
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, Glenton Burgess can be reached at 571-272-3949. 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.
/DOUGLAS B BLAIR/Primary Examiner, Art Unit 2454