DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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.
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-37 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.
Regarding claims 1, 10, 18, and 26 recite “to identify,” “to cause,” “to transfer,” to be performed” and it is not clear whether applicant intends to perform the actions or only intended to perform the actions. The broadest reasonable interpretation does not require the actions to be performed.
Regarding claim 1, recites “circuitry to identify...and to cause ” It is not clear if applicant intends to claim the circuitry only or only the steps. The circuitry does not actually perform the steps, and it is not clear how it could, since normally circuits execute instructions stored in memory that do certain things.
Regarding claims 2, 4, 5, 6, 9, 11, 19, 21, 23, 24, 27, 24, recites variations of “perform an API” and it is not clear how an API can be performed, as it is normally called or executed. It is not clear what perform means as an API is a collection of functions in a library, and performing a library does not make sense. And it is not clear what is considered performance?
Regarding claims 2-9, recite similar limitations, for example, “is to be deallocated” in claim 3, “to perform” in claim 2, 5 and 7, etc. which also make unclear whether these actions are taken place or merely intended to. The broadest reasonable interpretation does not require the step to be performed.
Regarding claims 11-17, recite similar problems, as it is not clear whether the steps are being performed or merely intended to, for example “is to be transferred” claim 12, 15, “is to deploy” claim 16, etc.
Claim 19-25, recite similar problems, as it is not clear whether the steps are being performed or merely intended to, for example “to perform” claim 21, “is to call the API” claim 23, etc.
Regarding claim 26, recites “to cause” and “to transfer” and it is not clear if those actions are being performed or merely intended to.
Claim 27-35, and 37, recite similar problems, as it is not clear whether the steps are being performed or merely intended to, for example “is to be called” claim 30, “is to be transferred” claim 33, “is further to be used” claim 34, “is to be transferred” claim 35, “is to cause the function to be performed,” claim 37, etc.
Regarding claim 36, is rejected based on dependency to claim 1 above, and is rejected for the same reasons.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-37 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Regarding claim 1, this part of the eligibility analysis evaluates whether the claim falls within any statutory category. MPEP §2106.03. The claim recites system; thus, the claim is directed to a machine which is one of the statutory categories of invention.
Step 2A Prong 1: This part of the eligibility analysis evaluates whether the claim recites a judicial exception. As explained in MPEP 2106.04(II) and the October 2019 Update, a claim “recites” a judicial exception when the judicial exception is “set forth” or “described” in the claim.
The limitations “identify a function from a library of a different data transport protocol to cause a buffer to be deallocated into a pool from which the buffer was allocated” as drafted, recite functions that, under its broadest reasonable interpretation, covers functions that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the functions through observation, evaluation, judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas. See MPEP §2106.04(a)(2). Accordingly, claim 1 recites a judicial exception (i.e. an abstract idea).
Step 2A, Prong 2, This part of the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by (a) identifying whether there are any additional elements recited in the claim beyond the judicial exception, and (b) evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. 2019 PEG Section III(A)(2), 84 Fed. Reg. at 54-55.
In this case, this judicial exception is not integrated into a practical application. The claim recites the following additional elements “one or more processors, circuitry, in response to an API call from a wireless network computing resource (i) of a first layer of a network protocol stack and (ii) that uses a data transport protocol” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic processor or generic computer components to perform the judicial exception. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
The claim includes additional elements of insignificant extra solution activity “corresponding to the API call” “associated with a second later of the network protocol” “cause the function to be performed by a different wireless network computing resource of the second layer, where the buffer was selected allocated to transfer information between the wireless network computing resource using the data transport protocol and the different wireless network computing resource using the different data transport protocol.”
The “corresponding to the API call” “associated with a second later of the network protocol” “cause the function to be performed” step is not a practical application because it fails to meaningfully limit the claim because it does not require any particular application of the recited “cause the function to be performed” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f).
Step 2B, This part of the eligibility analysis evaluates whether the claim as a whole amounts to significantly more than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim. MPEP 2106.05.
As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of the “one or more processors, circuitry, in response to an API call, from a wireless network computing resource (i) of a first layer of a network protocol stack and (ii) that uses a data transport protocol” are merely a generic computer or generic computer components to apply the judicial exception which cannot provide an inventive concept. The claims include additional elements “cause the function to be performed by a different wireless network computing resource, where the buffer was selected allocated to transfer information between the wireless network computing resource using the data transport protocol and the different wireless network computing resource using the different data transport protocol.”
The “corresponding to the API call” “associated with a second later of the network protocol” “cause the function to be performed” step is not significantly more than the abstract idea and fails inventive concept because it fails to meaningfully limit the claim because it does not require any particular application of the recited “cause” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept.
Accordingly, the claim does not appear to be patent eligible under 35 USC 101.
Regarding claim 2 is a dependent claim rejected for the same reasons as claim 1. Furthermore, the claims include additional elements “wherein the processing circuitry is to, in response to the API call, cause a transport layer to map commands between computing resources.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Regarding claim 3, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein the circuitry is to, in response to the API call, decrement a reference counter initialized as part of allocation of the buffer, wherein the reference counter is used to indicate when the buffer is to be deallocated.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Regarding claim 4, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein the circuity are to, in response to the API call, use at least a mapping between APIs of different data transport protocols.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Regarding claim 5, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein circuitry is to, in response to the API call, cause the wireless network computing resource to perform one or more operations associated with a plurality of information transmission types associated with the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because it does not require any particular application of the recited “performing” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. See MPEP 2106.05(f).
Regarding claim 6, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein the API is based at least on information identifying an information transmission type associated with the wireless network computing resource or the different wireless network computing resource” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Regarding claim 7, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein the circuitry is to, in response to the API call, cause the wireless network computing resource to perform an operation related to a first information transmission type based at least on a corresponding operation related to a second information transmission type.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because it does not require any particular application of the recited “performing” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. See MPEP 2106.05(f).
Regarding claim 8, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein: the wireless network computing resource and the different wireless network computing resources are associated with a 5G-NR network protocol stack that includes the first layer, the second layer, and a third layer, a first 5G-NR computing resource of the wireless network computing resource and the different wireless network is associated with the first layer, a second 5G-NR computing resource of the wireless network computing resource and the different wireless network is associated with the second layer, the API is associated with the third layer; and the third layer is located between the first and second layers” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Regarding claim 9, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “the circuitry is further to transfer information between the first layer and the second layer corresponding to a 5G-NR network protocol, wherein the wireless network computing resources requests an operation associated with a first information transmission type, and the circuitry is further to, in response to the API call, the different wireless network computing resource to perform an operation associated with a second transmission type.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, is merely data gathering which the court have identified as well understood, routine, and conventual activity. See MPEP 2106.05(d).
Regarding claim 10, is an independent system claim which corresponds with claim 1 and is rejected for the same reasons as claim 1. In particular, the claim recites two additional elements “memory to store instructions that, as a result of execution by one or more processors.” The memory and a processor are recited at a high-level of generality (i.e., as a generic processor performing a generic processor, and generic memory) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional element does not integrate the abstract idea into a practical application, nor recite significantly more than the abstract idea. The claim is directed to an abstract idea.
Regarding claim 11, is a dependent claim rejected for the same reasons as claim 10. Furthermore, claims include additional elements “wherein performance of the API is based at least on transport protocol associated with the wireless network computing resource or the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because it does not require any particular application of the recited “performance” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. See MPEP 2106.05(f).
Claim 12, is a dependent claim rejected for the same reasons as claim 10. Furthermore, claims include additional elements “wherein: the information is to be transferred between the first layer and the second layer of a 5G-NR network protocol stack, and the first layer and second layer are each associated with a different transport protocol.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, is merely data gathering which the court have identified as well understood, routine, and conventual activity. See MPEP 2106.05(d).
Claim 13, is a dependent claim rejected for the same reasons as claim 10. Furthermore, claims include additional elements “wherein an application associated with the wireless network computing resource calls the API and does not have information regarding any transport protocol supported by the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 14, is a dependent claim rejected for the same reasons as claim 10. Furthermore, claims include additional elements “wherein the API is embedded within another API.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 15, is a dependent claim rejected for the same reasons as claim 10. Furthermore, claims include additional elements “wherein the information is to be transferred using an application that causes calls from one layer associated with one transport protocol to perform operations in the second layer associated with a second transport protocol.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, is merely data gathering which the court have identified as well understood, routine, and conventual activity. See MPEP 2106.05(d).
Claim 16, is a dependent claim rejected for the same reasons as claim 10. Furthermore, claims include additional elements “further comprising: a network orchestrator configured to identify one or more transport profiles supported by one of the wireless network computing resource, and the network orchestrator is to deploy the different wireless network computing resource with the wireless network computing resource configured with a transport profile supported by the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 17, is a dependent claim rejected for the same reasons as claim 10. Furthermore, claims include additional elements “wherein at least one of the wireless network computing resource and the different wireless network computing resource is a virtual device.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 18, is an independent medium claim rejected for the same reasons as claim 1. In particular, the claim recites additional element “a non-transitory machine-readable medium having stored thereon one or more instructions, which if performed by one or more processors.” The storage medium and one or more processors are recited at a high-level of generality (i.e., as a generic medium, and generic processor) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional element does not integrate the abstract idea into a practical application, nor recite significantly more than the abstract idea. The claim is directed to an abstract idea.
Claim 19, is a dependent claim rejected for the same reasons as claim 18. Furthermore, claims include additional elements “teaches wherein of the API call is based at least on a transport configuration associated with the wireless network computing resources and the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 20, is a dependent claim rejected for the same reasons as claim 18. Furthermore, claims include additional elements “wherein: the information is to be transferred between the first layer and the second layer of a 5G-NR network protocol stack using a third layer between the first and second layers that is based, at least on multiple transport protocols.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, is merely data gathering which the court have identified as well understood, routine, and conventual activity. See MPEP 2106.05(d).
Claim 21, is a dependent claim rejected for the same reasons as claim 18. Furthermore, claims include additional elements “wherein the one or more processors are further to, in response to an API call, cause the function to be performed by the different wireless network computing resource without information associated with a transmission type associated with one of wireless network computing resource and the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because it does not require any particular application of the recited “performance” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. See MPEP 2106.05(f).
Claim 22, is a dependent claim rejected for the same reasons as claim 18. Furthermore, claims include additional elements “wherein the one or more processors are one or more graphics processing units (GPUs).” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 23, is a dependent claim rejected for the same reasons as claim 18. Furthermore, claims include additional elements “wherein: one of the wireless network computing resource is to call the API, the one or more processors are further to, in response to the API call causes, at least in part, the one 5G-NR computing resource to transfer information to the different wireless network computing resource that supports a different transport protocol without modification to the wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, is merely data gathering which the court have identified as well understood, routine, and conventual activity. See MPEP 2106.05(d).
Claim 24, is a dependent claim rejected for the same reasons as claim 18. Furthermore, claims include additional elements “wherein: the memory selected is an allocated buffer; and the one or more processors are further to, in response to the API call, cause the wireless network computing resource to decrement a reference counter associated with the allocated buffer and
deselect the allocated buffer based on the decremented reference counter holding a value of zero.” The additional elements do not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are recognized as well-understood, routine, and conventional activity of storing and retrieving information in memory. See MPEP 2106.05(d)(II)(iv).
Claim 25, is a dependent claim rejected for the same reasons as claim 18. Furthermore, claims include additional elements “wherein one of the wireless network computing resource and the different wireless network computing resource has been configured with a transport profile supported by a second of the wireless network computing resource and the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 26, is a method claim corresponding to processor claim 1, and is rejected for the same reasons.
Claim 27, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “wherein of the API call is based at least on a transport profile associated with one of the wireless network computing resource and the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because it does not require any particular application of the recited “performance” and is at best the equivalent of merely adding the words “apply it” to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. See MPEP 2106.05(f).
Claim 28, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “further comprising identifying one or more transport profiles supported by one or more of the wireless network computing resource and the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 29, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “further comprising: configuring one 5G-NR computing resource of the wireless network computing resource and the different wireless network computing resource with transport profiles supported by the one 5G-NR computing resource, and deploying the configured one 5G-NR computing resource with a second 5G-NR computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 30, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “wherein the API is to be called by one 5G-NR computing resource of the wireless network computing resource and the different wireless network computing resource that was deployed with a second 5G-NR computing resource of the wireless network computing resource and the different wireless network computing resource, wherein the second 5G-NR computing resource was configured with one or more transport profiles.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 31, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “further comprising transferring the information using an application that maps the API to an operation related to a transport protocol.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 32, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “wherein the API is embedded within another API.”
This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 33, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “wherein: the information is to be transferred between two layers of a 5G-NR network protocol stack, wherein each layer is associated with a different transport protocol, and the API is located in a third layer.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 34, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “wherein: the API call causes one or more 5G-NR computing resources to decrement a reference counter; the reference counter is associated with the buffer; and the buffer selected is further to be used as part of a zero copy buffer method.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 35, is a dependent claim rejected for the same reasons as claim 26. Furthermore, claims include additional elements “wherein the information includes different messages each associated with a different information transmission type, and the information is to be transferred between the wireless network computing resource and the different wireless network computing resource using one data transport protocol. This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because it is merely data input and output is consider well understood, routine, and conventual activity. See MPEP 2106.05(g).
Claim 36, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein one of the wireless network computing resource and the different wireless network computing resource uses a Peripheral Component Interconnect Express (PCIe) data transport protocol, and the different wireless network computing resource uses a User Datagram Protocol (UDP) data transport protocol, the API call is made by an application agnostic to a type of data transport protocol used by the wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Claim 37, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements ” wherein the different wireless network computing resource was, prior to the API call, configured according to a profile corresponding to the different data transport protocol selected from a plurality of data transport protocols supported by the different wireless network computing resource.” This additional element does not amount to a practical application, nor recite significantly more than a judicial exception, because the additional elements are merely instructions to implement an abstract idea on a computer. MPEP 2106.04(d).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/ patents/apply/applying-online/eterminal-disclaimer
Claims 1-9, 11-17, 19-25, 27-33, 35, and 37 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1, 3-9, 11-17, 19-23, 25, 27-22, and 35 of copending Application No. 17/720205 in view of Riddoch et al. (U.S. PG PUB 2007/0183418).
Regarding claim 1, 10, 18, and 26, Application No. 17/720205, claim 1, 10, 18, and 26 teaches all the limitations of claim 1, 10, 18, and 26, except to cause a buffer to be deallocated into a pool from which the buffer was allocated. However, Riddoch teaches to cause a buffer to be deallocated into a pool from which the buffer was allocated (see ¶[0143] “After processing the packet data in these buffers, the host may release the buffers back into a pool for eventually re-writing into the receive queue for re-use by different incoming packet data”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Application No. 17/720205 by adapting Riddoch in order provide existing connections to be reconfigured on a resource-by-resource basis (see ¶ [0086] of Riddoch).
Regarding claim 2, Application No. 17/720205 teaches all the limitations of the claim except wherein the circuitry is to perform, in response to the API call, the API by using a transport layer to map commands between computing resources. However, Riddoch teaches wherein the circuitry is to perform, in response to the API call, the API by using a transport layer to map commands between computing resources (see ¶[0083] “The NIC 1116 has a bus interface controller (BIC) 1235, a resource configuration unit (RCU) 1236 and a bus mapping table 1237. The resource configuration unit processes communications received from the computer that provide instructions on the allocation, re-allocation and de-allocation of resources on the NIC 1116, and configures the resources in accordance with such instructions.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Application No. 17/720205 by adapting Riddoch in order provide existing connections to be reconfigured on a resource-by-resource basis (see ¶ [0086] of Riddoch).
Regarding claim 3, Application No. 17/720205 teaches all the limitations of the claim except wherein the circuitry is to, in response to the API call, decrement a reference counter initialized as part of allocation of the buffer, wherein the reference counter is used to indicate when the buffer is to be deallocated. However, Riddoch teaches wherein the circuitry is to, in response to the API call, decrement a reference counter initialized as part of allocation of the buffer, wherein the reference counter is used to indicate when the buffer is to be deallocated (see ¶[0031] “In step 712, the kernel decrements its count of the number of memberships in the specified multicast group at the specified local interface, and in step 714, it determines whether any memberships remain” see ¶ [0123] “The NIC 1116 then transfers the received data packet into host memory 1122 beginning at that address. If the packet is a multicast packet, then the NIC 1116 maintains a count of the number of transfers to host memory that remain for the received data packet. When this count reaches zero, the NIC can release its own buffer for the packet.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Application No. 17/720205 by adapting Riddoch in order provide existing connections to be reconfigured on a resource-by-resource basis (see ¶ [0086] of Riddoch).
Regarding claim 24, Application No. 17/720205 teaches all the limitations of the claim except the one or more processors are further to, in response to the API call, causes the wireless network computing resource to decrement a reference counter associated with the allocated buffer, and if the decremented reference counter holds a value of zero, the allocated buffer is deselected.
However, Riddoch teaches the one or more processors are further to, in response to the API call, causes the wireless network computing resource to decrement a reference counter associated with the allocated buffer (see ¶[0031] “In step 712, the kernel decrements its count of the number of memberships in the specified multicast group at the specified local interface, and in step 714, it determines whether any memberships remain.”); and if the decremented reference counter holds a value of zero, the allocated buffer is deselected (see ¶ [0123] “The NIC 1116 then transfers the received data packet into host memory 1122 beginning at that address. If the packet is a multicast packet, then the NIC 1116 maintains a count of the number of transfers to host memory that remain for the received data packet. When this count reaches zero, the NIC can release its own buffer for the packet.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Application No. 17/720205 by adapting Riddoch in order provide existing connections to be reconfigured on a resource-by-resource basis (see ¶ [0086] of Riddoch).
Claim 37, Application No. 17/720205 teaches all the limitations of the claim except wherein the circuitry is further to cause the function to be performed by the different wireless network computing resource to deallocate the buffer.
However, Riddoch teaches wherein the circuitry is further to cause the function to be performed by the different wireless network computing resource to deallocate the buffer (see ¶[0143] “In step 1948, assuming no serious error has been detected, the host 1114 processes the newly received packet data, including protocol processing. This may require chaining together several receive data buffers in sequence as designated by consecutive receive queue entries. The host 1114 knows the starting buffer and offset of the packet from the buffer descriptor in the receive queue pointed to by the host centric receive queue read pointer, and knows the end of the packet either from the receive packet byte count identified in the receive completion event or from the copy of the device centric receive queue read pointer that might be included in the receive completion event. After processing the packet data in these buffers, the host may release the buffers back into a pool for eventually re-writing into the receive queue for re-use by different incoming packet data.”).
Claims 4-9, 11-17, 19-23, 25, 27-33, 35 of current application are substantially the same or identical to claims 4-9, 11-17, 19-23, 25, 27-33, and 35, respectively, and are rejected.
This is a provisional nonstatutory double patenting rejection.
Claim 34 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 2, 24, and 34 of copending Application No. 17/720205 in view of Lym et al. (U.S. PG PUB 2005/0097245).
Regarding claim 34, Application No. 17/720205 teaches all the limitations of the claim except performance of the API causes one or more 5G-NR computing resources to decrement a reference counter; the reference counter is associated with the storage selected.
However, Lym teaches the API call causes one or more 5G-NR computing resources to decrement a reference counter (see ¶0223] “The isochronous API then ends the broadcast, deallocates the appropriate resources, if no other connections are present, detaches buffers from the plug and closes the plug. A flowchart illustrating the process followed by the isochronous API in response to an end broadcast transmission request from an application is illustrated in FIG. 13. This end broadcast transmission process starts at the step 430. At the step 432, the broadcast is then ended by calling the function BroadcastTransmitOff, as defined in Table XXII below, which decrements the broadcast connection counter (BCC) on the output plug control register (oPCR), determines if any other connections are present at the step 434, and if no other connections are present, then deallocates the isochronous bandwidth and channel associated with the plug, at the step 436”); the reference counter is associated with the storage selected (see ¶[0261] “After it is determined that there are other connections present, at the step 604, or after isochronous bandwidth and channel are deallocated, at the step 606, then, the buffers are detached from the plug, at the step 608, by calling the function DetachBufferFromPlug”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Application No. 17/720205 by adapting Lym in order to keep track of information.
Claim 36 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 17/720205 in view of Kim et al. (U.S. PG PUB 2022/0030531).
Co-pending Application No. 17/720205 teaches all the limitations of the claim except wherein one of the plurality of 5G-NR computing resources uses a Peripheral Component Interconnect Express (PCIe) data transport protocol; the API call is made by an application agnostic to a type of data transport protocol used by the wireless network computing resource. However, Kim teaches wherein one of the plurality of 5G-NR computing resources uses a Peripheral Component Interconnect Express (PCIe) data transport protocol (see ¶ [0068] “The inter-processor interface may be implemented as, for example, a universal asynchronous receiver/transmitter (UART) (e.g., a high speed-UART (HS-UART)) or a peripheral component interconnect bus express (PCIe), but the type of interface is not limited thereto”) and another of the plurality of fifth 5G-NR computing resources uses a User Datagram Protocol (UDP) information transmission type (see ¶[0081] “According to an embodiment, the electronic device 101 may perform Internet communication associated with the server 108 using the Internet protocol 312 (e.g., a transmission control protocol (TCP), a user datagram protocol (UDP), or an internet protocol (IP)). For example, the Internet protocol 312 may be performed in a main processor (e.g., the main processor 121 of FIG. 1) included in the electronic device 101.”);
the API call is made by an application agnostic to a type of data transport protocol used by the wireless network computing resource (see ¶ [0081] “According to an embodiment, the electronic device 101 may perform Internet communication associated with the server 108 using the Internet protocol 312 (e.g., a transmission control protocol (TCP), a user datagram protocol (UDP), or an internet protocol (IP)). For example, the Internet protocol 312 may be performed in a main processor (e.g., the main processor 121 of FIG. 1) included in the electronic device 101.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of co-pending application 17/720205 and Kim to improve the quality or speed of communication with 5G (see ¶ [0075] of Kim).
This is a provisional nonstatutory double patenting rejection.
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.
Claim(s) 1, 2, 3, 5, 6, 7, 10, 11, 18, 19, 26, 35, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) in view of Figaro et al. (U.S. PG PUB 2006/0106934).
Regarding claim 1, Riddoch teaches one or more processors comprising: circuitry, in response to an application programming interface (API) call from a wireless network computing resource (see ¶ [0009] “In order to control and/or communicate with the network interface device an application running on the computer may issue API (application programming interface) calls. Some API calls may be handled by the transport libraries that have been provided to support the network interface device.”);
(i) of a first layer of a network protocol stack (see ¶ [0009] “FIG. 1 illustrates one implementation in which user level protocol stacks are incorporated. In this architecture the TCP (and other) protocols are implemented twice: as denoted TCP1 and TCP2. I”) and (ii) that uses a data transport protocol (see ¶[0155] “This flowchart covers only the TCP and UDP transport level protocols; other embodiments can support other protocols, including but not limited to SCTP, RTP, ICMP and IGMP.”);
to cause a buffer to be deallocated into a pool from which the buffer was allocated (see ¶[0143] “After processing the packet data in these buffers, the host may release the buffers back into a pool for eventually re-writing into the receive queue for re-use by different incoming packet data.”);
where the buffer was allocated to transfer information between the wireless network computing resource using the data transport protocol and the different wireless network computing resource using the different data transport protocol (see ¶[0022] “Most data packets on a typical network are unicast packets. A unicast data packet is transmitted from a sender to a single destination endpoint. (The term "endpoint" is used herein in the sense of communications protocols, to denote the entity on one end of a transport layer connection. An "endpoint" is not precluded from forwarding a data packet on to yet further destinations.)” and see ¶[0149] “It can be seen that each entry contains up to five fields for identifying a particular TCP or UDP endpoint in the host subsystem 1114 (protocol (TCP or UDP), source IP address, source port number, destination IP address, destination port number), plus one for the associated receive queue ID. The queue ID field points to the entry in the receive queue descriptor table 1541 (FIG. 15), into which an incoming packet should be delivered when the endpoint data specified in the entry matches that of the header of the incoming packet.”).
Riddoch does not expressly, however, Figaro teaches identify a function, corresponding to the API call from a library of a different data transport protocol associated with a second layer of the network protocol stack (see ¶[0056] “To implement such transport layer (e.g., including, but not limited to, TCP, UDP or Raw IP) message flow, P1 initializes a socket with the destination network address of VR2 and other relevant information (Step 606). For example, P1 uses a socket API (e.g., open_socket) and loads the information into the message 320. Illustratively, the message 320 contains a destination network address of the destination VR (VR2), a destination port number of the receiving process (P2), a source network address of the source VR (VR1), a source port number of the sending process (P1) and any "payload" data (e.g., control traffic information). In Step 608, P1 passes the message 320 to its client socket library 315.”)
cause the function to be performed by a different wireless network computing resource of the second layer (see ¶[0047] “To that end, the routing protocol is configured on the interface to acquire (discover) network and layer 2 (MAC) addresses of neighboring routers (adjacencies) connected to that interface. Examples of protocols used to acquire layer 2 MAC addresses and layer 3 network addresses are the well-known address resolution protocol (ARP) and interior gateway protocols (IGP), respectively. The network addresses acquired by the IGP "routing" protocols are used to construct an adjacency table, whereas the network and MAC addresses are associated with forwarding information needed to build a FIB, such as global FIB 275. Examples of IGP routing protocols include link-state routing protocols, such as the well-known Intermediate-System-to-Intermediate-System (IS-IS) and, illustratively, the OSPF protocols.”)
Hence, it would have been obvious to one or ordinary skill in the art before the effective filing date to modify the teachings of Riddoch by adapting Figaro that enables services on different VRs executing on the same physical router to communicate without utilizing or substantially consuming communication resources, such as a network protocol stack and physical interfaces, of the physical router (see ¶[0016] of Figaro).
Regarding claim 2, Riddoch teaches wherein the processing circuitry is to cause a transport layer to map commands between computing resources (see ¶[0083] “The NIC 1116 has a bus interface controller (BIC) 1235, a resource configuration unit (RCU) 1236 and a bus mapping table 1237. The resource configuration unit processes communications received from the computer that provide instructions on the allocation, re-allocation and de-allocation of resources on the NIC 1116, and configures the resources in accordance with such instructions.”).
Regarding claim 3, Riddoch teaches wherein the circuitry is to, in response to the API call, decrement a reference counter initialized as part of allocation of the buffer, wherein the reference counter is used to indicate when the buffer is to be deallocated (see ¶[0123] “The NIC 1116 then transfers the received data packet into host memory 1122 beginning at that address. If the packet is a multicast packet, then the NIC 1116 maintains a count of the number of transfers to host memory that remain for the received data packet. When this count reaches zero, the NIC can release its own buffer for the packet.” and see ¶ [0092] “To achieve this the application using the resource calls a de-allocation routine in the user level transport library 1223. The de-allocation routine calls the kernel driver 1225, which instructs the RCU to de-allocate the resource by disabling it, clearing its status and deleting its row in the table 1237.”).
Regarding claim 5, Riddoch teaches wherein performing the API causes the wireless network computing resource to perform one or more operations associated with a plurality of information transmission types associated with the different wireless network computing resource (see ¶[0016] “The send process behaves similarly except that there is usually one path of execution. The application calls the operating system API (e.g. using a send( ) call) with data to be transmitted (Step vi). This call copies data into a kernel data buffer and invokes TCP send processing. Here protocol is applied and fully formed TCP/IP packets are enqueued with the interface driver for transmission.”).
Regarding claim 6, Riddoch teaches wherein the API is based at least on information identifying an information transmission type associated with the wireless network computing resource or the different wireless network computing resource (see ¶ [0023] “In addition to unicast data packet transmission, many network protocols including IP also support broadcast data packet transmission. Broadcast packets are far less frequent than unicast packets, and are intended to be received by all host interfaces connected to the network.”).
Regarding claim 7, Riddoch teaches wherein performing the API is to cause the wireless network computing resource to perform an operation related to a first information transmission type based at least on a corresponding operation related to a second information transmission type (see ¶ [0155] “FIG. 5. This flowchart covers only the TCP and UDP transport level protocols; other embodiments can support other protocols, including but not limited to SCTP, RTP, ICMP and IGMP.” See ¶[0006] “In particular, an application wishing to transmit a data packet using TCP/IP calls the operating system API (e.g. using a send( ) call) with data to be transmitted. This call causes a context switch to invoke kernel routines to copy the data into a kernel data buffer and perform TCP send processing.”).
Regarding claim 10, is a system claim corresponding to processor claim 1, and is rejected for the same reasons. In addition, Riddoch teaches memory to store instructions that, as a result of execution by one or more processors (see ¶ [0075] to ¶ [0077] computer system with memory).
Regarding claim 11, Riddoch teaches wherein performance of the API is based at least on transport protocol associated with the wireless network computing resource or the different wireless network computing resource (see ¶ [0023] “In addition to unicast data packet transmission, many network protocols including IP also support broadcast data packet transmission. Broadcast packets are far less frequent than unicast packets, and are intended to be received by all host interfaces connected to the network.”).
Regarding claim 18, is a medium claim corresponding to processor claim 1, and is rejected for the same reasons. In addition, Riddoch teaches a non-transitory machine-readable medium having stored thereon one or more instructions, which if performed by one or more processors (see ¶ [0075] to ¶ [0077] computer system with memory).
Regarding claim 19, Riddoch teaches wherein performance of the API is based at least on a transport configuration associated with the wireless network computing resources and the different wireless network computing resource (see ¶ [0023] “In addition to unicast data packet transmission, many network protocols including IP also support broadcast data packet transmission. Broadcast packets are far less frequent than unicast packets, and are intended to be received by all host interfaces connected to the network.”).
Regarding claim 24, Riddoch teaches wherein: the memory selected is an allocated buffer (see ¶[0123] “The NIC 1116 then uses the buffer ID of the current receive data buffer as another index into buffer descriptor table 1510 to retrieve the buffer descriptor for the buffer into which the current receive data is to be written.”); and
the one or more processors are further to, in response to the API call:
cause the wireless network computing resource to decrement a reference counter associated with the allocated buffer (see ¶[0031] “In step 712, the kernel decrements its count of the number of memberships in the specified multicast group at the specified local interface, and in step 714, it determines whether any memberships remain.”);
deselect the allocated buffer based on the decremented reference counter holding a value of zero (see ¶ [0123] “The NIC 1116 then transfers the received data packet into host memory 1122 beginning at that address. If the packet is a multicast packet, then the NIC 1116 maintains a count of the number of transfers to host memory that remain for the received data packet. When this count reaches zero, the NIC can release its own buffer for the packet.”).
Regarding claim 26, is a method claim corresponding to processor claim 1, and is rejected for the same reasons.
Regarding claim 35, Riddoch teaches wherein the information includes different messages each associated with a different information transmission type (see ¶[0149] “It can be seen that each entry contains up to five fields for identifying a particular TCP or UDP endpoint in the host subsystem 1114 (protocol (TCP or UDP), source IP address, source port number, destination IP address, destination port number), plus one for the associated receive queue ID. The queue ID field points to the entry in the receive queue descriptor table 1541 (FIG. 15), into which an incoming packet should be delivered when the endpoint data specified in the entry matches that of the header of the incoming packet.”);
and the information is to be transferred between the wireless network computing resource and the different wireless network computing resource using one data transport protocol (see ¶ [0149] “It can be seen that each entry contains up to five fields for identifying a particular TCP or UDP endpoint in the host subsystem 1114 (protocol (TCP or UDP), source IP address, source port number, destination IP address, destination port number), plus one for the associated receive queue ID. The queue ID field points to the entry in the receive queue descriptor table 1541 (FIG. 15), into which an incoming packet should be delivered when the endpoint data specified in the entry matches that of the header of the incoming packet.”).
Regarding Claim 37, Riddoch teaches wherein the different wireless network computing resource was, prior to the API call, configured according to a profile corresponding to the different data transport protocol selected from a plurality of data transport protocols supported by the different wireless network computing resource (see ¶[0083] “The resource configuration unit processes communications received from the computer that provide instructions on the allocation, re-allocation and de-allocation of resources on the NIC 1116, and configures the resources in accordance with such instructions.”).
Claim(s) 8, 9, 12, 15, 17, 20, and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 1, 10, 18, and 26 above, further in view of Chunduri et al. (U.S. PG PUB 2021/0076299).
Regarding claim 8, Riddoch and Figaro do not expressly disclose, however, Chunduri teaches wherein: the wireless network computing resource and the different wireless network computing resources are associated with a 5G-NR network protocol stack that includes a first layer, a second layer, and a third layer (see ¶[0094] “The packet 1000 includes open systems interconnection (OSI) model layer one (L1) data 1009 and layer two (L2) data 1008” and “The packet 1000 also includes IP addresses 1007 (layer three information), TCP/UDP information 1002 (layer four information), and application layer information 1001 (e.g., the payload/layer seven)”);
a first 5G-NR computing resource of the wireless network computing resource and the different wireless network is associated with the first layer (see ¶[0094] “The packet 1000 includes open systems interconnection (OSI) model layer one (L1) data 1009 and layer two (L2) data 1008”);
a second 5G-NR computing resource of the wireless network computing resource and the different wireless network is associated with the second layer (see ¶[0094] “The packet 1000 includes open systems interconnection (OSI) model layer one (L1) data 1009 and layer two (L2) data 1008’);
the API is associated with the third layer; and the third layer is located between the first and second layers (see ¶ [0094] “The packet 1000 also includes IP addresses 1007 (layer three information), TCP/UDP information 1002 (layer four information), and application layer information 1001 (e.g., the payload/layer seven)”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Chunduri to manage handovers between 5G network cells in order to reduce handover signaling traffic (see ¶ [0002] of Chunduri).
Regarding claim 9, Riddoch and Figaro do not expressly disclose, however, Chunduri teaches wherein: the circuitry is further to transfer information between the first layer and the second layer corresponding to a 5G-NR network protocol, wherein the wireless network computing resources requests an operation associated with a first information transmission type (see ¶[0069] “FIG. 3 is a schematic diagram that illustrates an example data plane based mechanism for buffering packets in a network 300 during a handover. Network 300 is an example implementation of network 100 and/or 200. Network 300 includes a UE 301, a UPF 341, and a 5G virtualized control plane 331, which may be substantially similar to UE 101, UPF 141, and 5G virtualized control plane 131, respectively. The UE 301 communicates with network 300 via a source gNB 312 and a destination gNB 311, which may be substantially similar to gNB 111. Further, the UE 301 communicates with a correspondent node 353, which may be another UE, a server in a cloud (e.g., enterprise cloud 152), or other computing device capable of communicating data over the Internet. Network 300 may be implemented as an example of network 200. Specifically, the embodiments disclosed with respect to network 300 can be used alone or in combination with the embodiments of network 200.”);
and the circuitry is further to, in response to the API call, cause the different wireless network computing resource to perform an operation associated with a second information transmission type (see ¶[0064] “The current gNB 211 or 212 can also update a checksum as desired, for example when the next header is a transmission control protocol (TCP)/user datagram protocol (UDP) header. The correct UDP port range is selected based on quality of service class identifier (QCI). Further, the QCI may be employed by a policy based routing (PBR) function for selecting the correct path/slice across N3. The selected UDP port may be kept as metadata for increasing the entropy for load balancing. The path identifier (ID) may be maintained as part of a path instruction.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Chunduri to manage handovers between 5G network cells in order to reduce handover signaling traffic (see ¶ [0002] of Chunduri).
Regarding claim 12, Riddoch and Figaro do not expressly disclose, however, Chunduri teaches wherein: the information is to be transferred between the first layer and the second layer of a 5G-NR network protocol stack (see ¶[0094] “see ¶[0094] “The packet 1000 includes open systems interconnection (OSI) model layer one (L1) data 1009 and layer two (L2) data 1008”);
and the first layer and second layer are each associated with a different transport protocol (see ¶ [0064] “The current gNB 211 or 212 can also update a checksum as desired, for example when the next header is a transmission control protocol (TCP)/user datagram protocol (UDP) header. The correct UDP port range is selected based on quality of service class identifier (QCI). Further, the QCI may be employed by a policy based routing (PBR) function for selecting the correct path/slice across N3. The selected UDP port may be kept as metadata for increasing the entropy for load balancing. The path identifier (ID) may be maintained as part of a path instruction.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Chunduri to manage handovers between 5G network cells in order to reduce handover signaling traffic (see ¶ [0002] of Chunduri).
Regarding claim 15, Riddoch and Figaro do not expressly disclose, however, Chunduri teaches wherein the information is to be transferred using an application that causes calls from one layer associated with one transport protocol to perform operations in a second layer associated with the second transport protocol (see ¶[0069] “FIG. 3 is a schematic diagram that illustrates an example data plane based mechanism for buffering packets in a network 300 during a handover. Network 300 is an example implementation of network 100 and/or 200. Network 300 includes a UE 301, a UPF 341, and a 5G virtualized control plane 331, which may be substantially similar to UE 101, UPF 141, and 5G virtualized control plane 131, respectively. The UE 301 communicates with network 300 via a source gNB 312 and a destination gNB 311, which may be substantially similar to gNB 111. Further, the UE 301 communicates with a correspondent node 353, which may be another UE, a server in a cloud (e.g., enterprise cloud 152), or other computing device capable of communicating data over the Internet. Network 300 may be implemented as an example of network 200. Specifically, the embodiments disclosed with respect to network 300 can be used alone or in combination with the embodiments of network 200.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Chunduri to manage handovers between 5G network cells in order to reduce handover signaling traffic (see ¶ [0002] of Chunduri).
Regarding claim 17, Riddoch and Figaro do not expressly disclose, however, Chunduri teaches wherein at least one of the wireless network computing resource and the different wireless network computing resource is a virtual device (see ¶[0060] “An enterprise cloud 152 may include various virtual machines or other servers configured to host services that respond to requests for data from the UE 101. For purposes of discussion, a node that communicates with a UE 101 may be referred to as a correspondent node. A correspondent node for the UE 101 may reside in an enterprise cloud 152 as a virtual machine, a dedicated server, etc. In some cases, a correspondent node may also be a different UE 101 connected to a different access network, for example via a gNB 111.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Chunduri to manage handovers between 5G network cells in order to reduce handover signaling traffic (see ¶ [0002] of Chunduri).
Regarding claim 20, Riddoch and Figaro do not expressly disclose, however, Chunduri teaches wherein: the information is to be transferred between the first layer and the second layer of a 5G-NR network protocol stack using a third layer between the first and second layers that is based at least on multiple transport protocols (see ¶ [0064] “For example, the current gNB 211 or 212 can consult the attached multi-access service center, which can perform an address resolution with the 5G virtualized control plane 231 by employing the IP address and/or other identifiers (IDs) in the uplink packet. Once the correct UPF 241 is determined, the current gNB 211 or 212 moves the IP address of the CN 253 to the uplink packet's metadata. The current gNB 211 or 212 sets the destination IP address of the uplink packet as the IP address for the UPF 241. Further, the current gNB 211 or 212 includes a change address command in the uplink packet with a condition set to the IP address of the UPF 241. The current gNB 211 or 212 can also update a checksum as desired, for example when the next header is a transmission control protocol (TCP)/user datagram protocol (UDP) header. The correct UDP port range is selected based on quality of service class identifier (QCI). Further, the QCI may be employed by a policy based routing (PBR) function for selecting the correct path/slice across N3. The selected UDP port may be kept as metadata for increasing the entropy for load balancing. The path identifier (ID) may be maintained as part of a path instruction.”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Chunduri to manage handovers between 5G network cells in order to reduce handover signaling traffic (see ¶ [0002] of Chunduri).
Regarding claim 33, Riddoch and Figaro do not expressly disclose, however, Chunduri teaches wherein: the information is to be transferred between two layers of a 5G-NR network protocol stack, wherein each layer is associated with a different transport protocol (see ¶ [0064] “For example, the current gNB 211 or 212 can consult the attached multi-access service center, which can perform an address resolution with the 5G virtualized control plane 231 by employing the IP address and/or other identifiers (IDs) in the uplink packet. Once the correct UPF 241 is determined, the current gNB 211 or 212 moves the IP address of the CN 253 to the uplink packet's metadata. The current gNB 211 or 212 sets the destination IP address of the uplink packet as the IP address for the UPF 241. Further, the current gNB 211 or 212 includes a change address command in the uplink packet with a condition set to the IP address of the UPF 241. The current gNB 211 or 212 can also update a checksum as desired, for example when the next header is a transmission control protocol (TCP)/user datagram protocol (UDP) header. The correct UDP port range is selected based on quality of service class identifier (QCI). Further, the QCI may be employed by a policy based routing (PBR) function for selecting the correct path/slice across N3. The selected UDP port may be kept as metadata for increasing the entropy for load balancing. The path identifier (ID) may be maintained as part of a path instruction.”); and the API is located in a third layer (see ¶[0094] “The packet 1000 also includes IP addresses 1007 (layer three information), TCP/UDP information 1002 (layer four information), and application layer information 1001 (e.g., the payload/layer seven)”).
Hence, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Chunduri to manage handovers between 5G network cells in order to reduce handover signaling traffic (see ¶ [0002] of Chunduri).
Claim(s) 13, 21, 23, 25, 27, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 10, 18, and 26 above, in view of Wei et al. (U.S. PG PUB 2014/0099119).
Regarding claim 13, Riddoch and Figaro do not expressly disclose, however, Wei teaches wherein an application associated with the wireless network computing resource calls the API and does not have information regarding any transport protocol supported by the different wireless network computing resource (see ¶ [0038] “(e.g., connection transport) may operate on an abstraction of the optical transport network and leverage transport services and optical transmission capabilities without being tied to the details of physical implementation. As shown in FIG. 3, the centralized controller 300 may also interface (e.g. southbound interface) with one or more of the optical transport hardware nodes, which are substantially similar to the optical nodes 112 in FIG. 1.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 21, Riddoch and Figaro do not expressly disclose, however, Wei teaches wherein the one or more processors are further cause the function to be performed by the different wireless network computing resource without information associated with a transmission type associated with one of wireless network computing resource and the different wireless network computing resource(see ¶ [0038] “(e.g., connection transport) may operate on an abstraction of the optical transport network and leverage transport services and optical transmission capabilities without being tied to the details of physical implementation. As shown in FIG. 3, the centralized controller 300 may also interface (e.g. southbound interface) with one or more of the optical transport hardware nodes, which are substantially similar to the optical nodes 112 in FIG. 1.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Chunduri and Figaro by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 23, Riddoch and Figaro do not expressly disclose, however, Wei teaches wherein:
one of the wireless network computing resource is to call the API (see ¶ [0028] “The virtualized transport network 106 may use an Open API to provide communication between a centralized controller and one or more VTN applications 108. The VTN applications 108 may be a variety of network applications, such as adaptive bandwidth services, secure cloud services, and self-service provisioning that may be implemented by a client, service provider, and/or other network operators.”); and
performance of the API causes, at least in part, the one 5G-NR computing resource to transfer information to the different wireless network computing resource that supports a different transport protocol without modification to the wireless network computing resource (see ¶ [0038] “e.g., connection transport) may operate on an abstraction of the optical transport network and leverage transport services and optical transmission capabilities without being tied to the details of physical implementation. As shown in FIG. 3, the centralized controller 300 may also interface (e.g. southbound interface) with one or more of the optical transport hardware nodes, which are substantially similar to the optical nodes 112 in FIG. 1.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 25, Riddoch and Figaro do not expressly disclose, however, Wei teaches wherein one of the wireless network computing resource and the different wireless network computing resource has been configured with a transport profile supported by a second of the wireless network computing resource and the different wireless network computing resource (see ¶ [0041] “Multiprotocol Label Switching (MPLS)-Transport Profile (TP)/Ethernet/OTN switches, and other types of network nodes that operate in the electrical domain. The ERG module 312 may produce a set of optical channel transport unit-k (OTUk) and/or OCHs between each virtual ORG node pair (e.g. a pair of electrical grooming switches) within the ERG. In one embodiment, the ERG may have ERG nodes that indicate whether two ERG nodes are electrical-layer reachable and may pass through ERG virtual links with an available optical channel data unit-k (ODUk) resource without the need of intermediate grooming”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 27, Riddoch and Figaro do not expressly disclose, however, Wei teaches wherein performance of the API is based at least on a transport profile associated with one of the wireless network computing resource and the different wireless network computing resource (see ¶ [0041] “Multiprotocol Label Switching (MPLS)-Transport Profile (TP)/Ethernet/OTN switches, and other types of network nodes that operate in the electrical domain. The ERG module 312 may produce a set of optical channel transport unit-k (OTUk) and/or OCHs between each virtual ORG node pair (e.g. a pair of electrical grooming switches) within the ERG. In one embodiment, the ERG may have ERG nodes that indicate whether two ERG nodes are electrical-layer reachable and may pass through ERG virtual links with an available optical channel data unit-k (ODUk) resource without the need of intermediate grooming” see ¶ [0042] “The path computation module 316, RWA and traffic grooming module 318, VTN topology migration module 320, and VTN provision and reconfiguration module 322 may be used for optimizing network performance for traffic engineering and network engineering issues. Specifically, the path computation module 316 may be configured to optimize route traffic flows through existing optical paths from the ORG and/or additional paths created in the ERG.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 28, Riddoch and Figaro do not expressly disclose, however, Wei teaches further comprising identifying one or more transport profiles supported by one or more of the wireless network computing resource and the different wireless network computing resource (see ¶ [0041] “Multiprotocol Label Switching (MPLS)-Transport Profile (TP)/Ethernet/OTN switches, and other types of network nodes that operate in the electrical domain. The ERG module 312 may produce a set of optical channel transport unit-k (OTUk) and/or OCHs between each virtual ORG node pair (e.g. a pair of electrical grooming switches) within the ERG. In one embodiment, the ERG may have ERG nodes that indicate whether two ERG nodes are electrical-layer reachable and may pass through ERG virtual links with an available optical channel data unit-k (ODUk) resource without the need of intermediate grooming”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Wei in order to have more flexibility and interoperability.
Claim(s) 22 is rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 18 above, in view of Xu et al. (U.S. PG PUB 2021/0149578).
Regarding claim 22, Riddoch and Figaro do not expressly disclose, however, Xu teaches wherein the one or more processors are one or more graphics processing units (GPUs) (see ¶ [0051] “The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (application processor, AP), a modem processor, a Graphics Processing Unit (graphics processing unit, GPU)”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Xu in order to better process graphics.
Claim(s) 14 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 10, and 26 above, in view of Lin et al. (U.S. PG PUB 2013/0074151).
Regarding claim 14, Riddoch and Figaro do not expressly disclose, however, Lin teaches wherein the API is embedded within another API (see ¶ [0013] “Before sending the second invocation request to an ISP server corresponding to the second Open API, the method may further comprise determining, according to the invocation relationship among the plurality of Open APIs, that the second Open API needs to be invoked through the first Open API; sending the second invocation request to the ISP server corresponding to the second Open API”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Lin in order to better process transactions.
Regarding claim 32, Riddoch and Figaro do not expressly disclose, however, Lin teaches wherein the API is embedded within another API (see ¶ [0013] “Before sending the second invocation request to an ISP server corresponding to the second Open API, the method may further comprise determining, according to the invocation relationship among the plurality of Open APIs, that the second Open API needs to be invoked through the first Open API; sending the second invocation request to the ISP server corresponding to the second Open API”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Lin in order to better process transactions.
Claim(s) 16, 29 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 10, and 26 above, in view of Young (US PG PUB 2021/0320850).
Regarding claim 16, Riddoch and Figaro do not expressly disclose, however, Young teaches further comprising: a network orchestrator configured to identify one or more transport profiles supported by one of the wireless network computing resource, and the network orchestrator is to deploy the different wireless network computing resource with the wireless network computing resource configured with a transport profile supported by the different wireless network computing resource (see ¶ [0044] “SIDC 345 may include an infrastructure catalog 370 that stores network infrastructure profiles that provide transport paths for a corresponding particular service profile. In one implementation, infrastructure catalog 370 obtains the network infrastructure profiles from an inventory database 375 which orders the network infrastructure profiles based on a deployment preference value associated with each of the network infrastructure profiles.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Young to provide significant flexibility in bandwidth allocation and/or improved spectral efficiency over other wireless network technology (see ¶ [0008] of Young).
Regarding claim 29, Riddoch and Figaro do not expressly disclose, however, Young teaches further comprising: configuring one 5G-NR computing resource of the wireless network computing resource and the different wireless network computing resource with transport profiles supported by the one 5G-NR computing resource (see ¶[0044] “SIDC 345 may include an infrastructure catalog 370 that stores network infrastructure profiles that provide transport paths for a corresponding particular service profile. In one implementation, infrastructure catalog 370 obtains the network infrastructure profiles from an inventory database 375 which orders the network infrastructure profiles based on a deployment preference value associated with each of the network infrastructure profiles.”); and
deploying the configured one 5G-NR computing resource with a second 5G-NR computing resource (see ¶ [0044] “In one implementation, deployment preference values include abstracted “distances” between nodes in a transport path associated with a network infrastructure”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Young to provide significant flexibility in bandwidth allocation and/or improved spectral efficiency over other wireless network technology (see ¶ [0008] of Young).
Regarding claim 30, Riddoch and Figaro do not expressly disclose, however, Young teaches wherein the API is to be called by one 5G-NR computing resource of the wireless network computing resource and the different wireless network computing resource that was deployed with a second 5G-NR computing resource of the wireless network computing resource and the different wireless network computing resource, wherein the second 5G-NR computing resource was configured with one or more transport profiles (see ¶[0047] “NFVO 335 may, based on instructions received from SO 325, deploy the alternative network service infrastructures and/or sub-infrastructures to orchestrate within data transport section 310. A transport controller may, based on the instructions from SO 325, initiate configuration of transport networks 320 to support the alternative network service infrastructures and/or sub-infrastructures.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Young to provide significant flexibility in bandwidth allocation and/or improved spectral efficiency over other wireless network technology (see ¶ [0008] of Young).
Claim(s) 4 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418), and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 1 and 26 above, in view of Zhang et al. (U.S. PG PUB 2021/0360714).
Regarding claim 4, Riddoch and Figaro do not expressly disclose, however, Zhang teaches wherein the circuitry is to in response to the API call, use at least a mapping between APIs of different data transport protocols (see ¶[0051] “As yet another example, femtocell dashboard 310 may provide a mapping and data routing API to configure data routing in private network 130. For example, an administrator may pre-configure and/or mix and match network slices for different locations and/or different devices in private network 130. For example, a user application may use multiple network slices at different locations (e.g., a first network slice at a first location/device, a second network slice at a second location/device, etc.).”), wherein the application is implemented, at least in part, on a hardware accelerator (see ¶ [0030] “hardware accelerator”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Zhang to improve wireless access networks.
Regarding claim 31, Riddoch and Figaro do not expressly disclose, however, Zhang teaches further comprising transferring the information using an application that maps the API to an operation related to a transport protocol (see ¶[0051] “As yet another example, femtocell dashboard 310 may provide a mapping and data routing API to configure data routing in private network 130. For example, an administrator may pre-configure and/or mix and match network slices for different locations and/or different devices in private network 130. For example, a user application may use multiple network slices at different locations (e.g., a first network slice at a first location/device, a second network slice at a second location/device, etc.).”), wherein the application is implemented, at least in part, on a hardware accelerator (see ¶ [0030] “hardware accelerator”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch and Figaro by adapting Zhang to improve wireless access networks.
Claim(s) 34 is rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418, and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 26 above, further in view of Lym et al. (U.S. PG PUB 2005/0097245) and Roy et al. (U.S. PG PB 2023/0044165).
Regarding claim 34, Riddoch and Figaro do not expressly disclose, however, Lym teaches wherein: performance of the API causes one or more 5G-NR computing resources to decrement a reference counter (see ¶0223] “The isochronous API then ends the broadcast, deallocates the appropriate resources, if no other connections are present, detaches buffers from the plug and closes the plug. A flowchart illustrating the process followed by the isochronous API in response to an end broadcast transmission request from an application is illustrated in FIG. 13. This end broadcast transmission process starts at the step 430. At the step 432, the broadcast is then ended by calling the function BroadcastTransmitOff, as defined in Table XXII below, which decrements the broadcast connection counter (BCC) on the output plug control register (oPCR), determines if any other connections are present at the step 434, and if no other connections are present, then deallocates the isochronous bandwidth and channel associated with the plug, at the step 436”);
the reference counter is associated with the buffer selected (see ¶[0261] “After it is determined that there are other connections present, at the step 604, or after isochronous bandwidth and channel are deallocated, at the step 606, then, the buffers are detached from the plug, at the step 608, by calling the function DetachBufferFromPlug,”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch, and Figaro by adapting Lym in order to keep track of information.
Riddoch, Figaro, and Lym do not expressly disclose, however, Roy teaches the buffer selected is further to be used as part of a zero copy buffer method (see ¶ [0048] “For example, the embodiment illustrated in FIG. 2 may be modified to include a transfer buffer (e.g., an RDMA buffer) associated with the client interface 252, One or more of the data chunks 253 may be transferred to such a transfer buffer with a zero-copy transfer, then transferred to the buffer 251.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch, Figaro, and Lym by adapting Roy to improve the ability of the client to process the requested data (see ¶ [0021] of Roy).
Claim(s) 36 is rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418), and Figaro et al. (U.S. PG PUB 2006/0106934), as applied to claim 1 above, further in view of Kim et al. (U.S. PG PUB 2022/0030531).
Regarding claim 36, Riddoch and Figaro do not expressly disclose, however, Kim teaches wherein one of the wireless network computing resource and the different wireless network computing resource uses a Peripheral Component Interconnect Express (PCIe) data transport protocol (see ¶ [0068] “The inter-processor interface may be implemented as, for example, a universal asynchronous receiver/transmitter (UART) (e.g., a high speed-UART (HS-UART)) or a peripheral component interconnect bus express (PCIe), but the type of interface is not limited thereto”)
and the different wireless network computing resource use a User Datagram Protocol (UDP) data transport protocol (see ¶[0081] “According to an embodiment, the electronic device 101 may perform Internet communication associated with the server 108 using the Internet protocol 312 (e.g., a transmission control protocol (TCP), a user datagram protocol (UDP), or an internet protocol (IP)). For example, the Internet protocol 312 may be performed in a main processor (e.g., the main processor 121 of FIG. 1) included in the electronic device 101.”)
the API call is made by an application agnostic to a type of data transport protocol used by the wireless network computing resource (see ¶[0081] “According to an embodiment, the electronic device 101 may perform Internet communication associated with the server 108 using the Internet protocol 312 (e.g., a transmission control protocol (TCP), a user datagram protocol (UDP), or an internet protocol (IP)). For example, the Internet protocol 312 may be performed in a main processor (e.g., the main processor 121 of FIG. 1) included in the electronic device 101.”).
Hence it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the teachings of Riddoch, Figaro, and Kim to improve the quality or speed of communication with 5G (see ¶ [0075] of Kim).
Response to Arguments
Applicant's arguments filed 8/24/2026 have been fully considered but they are not persuasive.
Regarding double patenting, applicant must file a terminal disclaimer as a complete and proper response to double patenting rejection. Applicants statement of filing a terminal disclaimer upon allowance is not a proper response. See MPEP 804. A complete response to a nonstatutory double patenting (NSDP) rejection is either a reply by applicant showing that the claims subject to the rejection are patentably distinct from the reference claims or the filing of a terminal disclaimer in accordance with 37 CFR 1.321 in the pending application(s) with a reply to the Office action (see MPEP § 1490 for a discussion of terminal disclaimers). Such a response is required even when the nonstatutory double patenting rejection is provisional.
Regarding 112(b) rejections, applicant have not yet provided enough support to show the underline portions of the claims as being definite and instead argues that examiner has not provided prime facie case. Examiner disagrees. Applicant has never clarified, never rebutted, and never addressed examiner’s concerns listed in the 112(b) rejection. Examiner has already made prime facie case, by disclosing what is typical in the art, and how the claims are not clear in light of what is typical in the art. Also, applicant’s claims and specification do not further explain the issues. In fact, no explanation was given. Additionally, the claimed amendments to not render the claims definite.
Regarding 101 rejections, applicants argue that the amended limitations are not an abstract idea because the human mind cannot cause circuitry to, in response to an API call from a wireless network resource of a first layer of a network protocol stack…identify a function.
Examiner disagrees. The circuitry is recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely a generic processor or generic computer components to perform the judicial exception.
The human mind can identify a function from a library of a different data transport protocol to cause a buffer to be deallocated into a pool from which the buffer was allocated, by using ones eyes and mind or with aid of pen and paper.
Regarding Prior Art Rejections, applicants argue that Riddoch and Black fail to disclose the claimed limitations. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Interview Requests
In accordance with 37 CFR 1.133(a)(3), requests for interview must be made in advance. Interview requests are to be made by telephone (571-270-7848) call or FAX (571-270-8848). Applicants must provide a detailed agenda as to what will be discussed (generic statement such as “discuss §102 rejection” or “discuss rejections of claims 1-3” may be denied interview). The detail agenda along with any proposed amendments is to be written on a PTOL-413A or a custom form and should be faxed (or emailed, subject to MPEP 713.01.I / MPEP 502.03) to the Examiner at least 5 business days prior to the scheduled interview. Interview requests submitted within amendments may be denied because the Examiner was not notified, in advance, of the Applicant Initiated Interview Request and due to time constraints may not be able to review the interview request to prior to the mailing of the next Office Action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pope et al. (U.S. PG PUB 2013/0117465) teaches a method for controlling the processing of data in a data processor such that the data processor is connectable to a further device over a data link. The method comprising the steps of receiving data at an element of the data processor and if a set interval has elapsed following the receipt of the data, determining whether processing of the received data in accordance with a data transfer protocol has begun, and, if it has not, triggering such processing of the received data by a protocol processing element. The method then senses conditions pertaining to the data link and sets the interval in dependence on the sensed conditions.
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 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 CARINA YUN whose telephone number is (571)270-7848. The examiner can normally be reached Mon, Tues, Thurs, 9-4 (EST).
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, Kevin Young can be reached on (571) 270-3180. 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.
Carina Yun
Patent Examiner
Art Unit 2194
/CARINA YUN/Examiner, Art Unit 2194
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights