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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/10/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 3 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 3, recites “the buffer to be deallocated is identified by another transport layer API,” does not appear to be supported in applicants’ specification. Examiner cannot find any mention of the claim limitation. Examiner can only find mention of a “transport layer” in ¶ [0105] but does not include the particulars of the claim. Applicant should point to support or remove the subject matter.
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, “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 claim 10, recites “memory to store instructions” but does not actually store them. It is not clear if applicant intends to claim the instructions or just the memory.
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.
Regarding claim 18, recites, “instructions, which if performed.” It is not clear if applicant intends to claim the instructions or just the medium. The broadest reasonable interpretation does not require the step to be performed.
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 using 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 “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 “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 using 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 “cause” 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 perform, in response to the API call, the API by using 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 “the buffer to be deallocated is identified by another transport layer 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).
Regarding claim 4, is a dependent claim rejected for the same reasons as claim 1. Furthermore, claims include additional elements “wherein the circuity are further to perform, in response to the API call, the API by using 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 further 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 in part, 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 further 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 in part, 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 a first layer, a 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 API is further to transfer information between a first layer and a second layer corresponding to a 5G-NR network protocol, wherein the wireless network computing resources is associated with the second layer and 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 resources 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 in part, 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 a first layer and a 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 a 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 in part, 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 a first layer and a second layer of a 5G-NR network protocol stack using a third layer between the first and second layers that is based, at least in part, 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, perform the API 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 protocols 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 if the decremented reference counter holds a value of zero, the allocated buffer is deselected.” 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 in part, 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) information transmission type, 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 circuitry is further to cause the function to be performed by the different wireless network computing resource to deallocate the buffer.” 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 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 3-9, 11-17, 19-23, 25, 27-33, 35 of current application are substantially the same or identical to claims 3-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 Black et al. (U.S. Patent 8,812733).
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.”) using 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, Black teaches identify a function from a library of a different data transport protocol (see col. 5, lines 14-20 “The communications library 102 includes support for two or more transport protocols, t.sub.1, t.sub.2, t.sub.3, t.sub.4, etc. Each of the transport protocols is associated with a feature set, f.sub.1, f.sub.2, f.sub.3, f.sub.4, etc., that defines how data can be sent and received. For example, communication features can include a cache storage and a cache timeout, and the corresponding feature values can define if received data is cached and a cache timeout value.”), cause the function to be performed by a different wireless network computing resource (see col. 8, lines 15-22, “The first server 206 identifies resources responsive to the first request 216, wraps the identified resources together with feature values from a feature set F, and provides the wrapped data to the first instance of the communications library 204 in a first response 218”).
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 Black to processing the communication request according to the selected transport protocol (see col. 1, lines 50-55, of Black).
Regarding claim 2, Riddoch teaches wherein the processing circuitry is to perform 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.”).
Regarding claim 3, Riddoch teaches the buffer to be deallocated is identified by another transport layer API (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 further 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 in part, 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 further to cause the wireless network computing resource to perform an operation related to a first information transmission type based, at least in part, 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 in part, 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 in part, 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 performance of the API 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.”).
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 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.”).
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 Black et al. (U.S. Patent 8,812733), 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 Black 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 Black 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 Black do not expressly disclose, however, Chunduri teaches wherein: the API is further to transfer information between a first layer and a second layer corresponding to a 5G-NR network protocol, wherein the wireless network computing resources is associated with the second layer and 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 performance of the API the different wireless network computing resources associated with a second 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 Black 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 Black do not expressly disclose, however, Chunduri teaches wherein: the information is to be transferred between a first layer and a 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 Black 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 Black 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 a 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 Black 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 Black 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 Black 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 Black do not expressly disclose, however, Chunduri teaches wherein: the information is to be transferred between a first layer and a second layer of a 5G-NR network protocol stack using a third layer between the first and second layers that is based, at least in part, 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 Black 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 Black 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 Black 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 Black et al. (U.S. Patent 8,812733), 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 Black 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 Black by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 21, Riddoch and Black do not expressly disclose, however, Wei teaches wherein the one or more processors are further to perform the API 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 Black by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 23, Riddoch and Black 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 protocols 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 Black by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 25, Riddoch and Black 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 Black by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 27, Riddoch and Black do not expressly disclose, however, Wei teaches wherein performance of the API is based, at least in part, 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 Black by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 28, Riddoch and Black 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 Black 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 Black et al. (U.S. Patent 8,812733), as applied to claim 18 above, in view of Xu et al. (U.S. PG PUB 2021/0149578).
Regarding claim 22, Riddoch and Black 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 Black 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 Black et al. (U.S. Patent 8,812733), 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 Black 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 Black by adapting Lin in order to better process transactions.
Regarding claim 32, Riddoch and Black 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 Black 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 Black et al. (U.S. Patent 8,812733), as applied to claim 10, and 26 above, in view of Young (US PG PUB 2021/0320850).
Regarding claim 16, Riddoch and Black 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 Black 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 Black 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 Black 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 Black 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 Black 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 Black et al. (U.S. Patent 8,812733), 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 Black do not expressly disclose, however, Zhang teaches wherein the circuitry are further to perform the API using 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 Black by adapting Zhang to improve wireless access networks.
Regarding claim 31, Riddoch and Black 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 Black 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 Black et al. (U.S. Patent 8,812733), 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 Black 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 Black by adapting Lym in order to keep track of information.
Riddoch, Black, 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, Black, 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 Black et al. (U.S. Patent 8,812733), as applied to claim 1 above, further in view of Kim et al. (U.S. PG PUB 2022/0030531).
Regarding claim 36, Riddoch and Black 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 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 Riddoch, Black, and Kim to improve the quality or speed of communication with 5G (see ¶ [0075] of Kim).
Response to Arguments
Applicant's arguments filed 3/10/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(a) rejections, applicants have not addressed claim 3, which do not appear to be supported by applicants specification.
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 Prior Art Rejections, applicants argue that Riddoch and Rosu fail to disclose the newly amended claims. However, argument is moot, examiner cited new art to show the amended claims.
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.
White (U.S. PG PUB 2021/0182124) teaches if an application programming interface (API) call is idempotent. If the API call is idempotent, the calls can be concurrently forwarded to multiple datacenters. If the API call is not idempotent, the calls can be sent to each of a multiple datacenters in turn until a response is received or timeout occurs. Automatically providing multi-region calls in synchrony provides a faster response time during data center or regional failures. Automatically providing multi-region calls in synchrony at the appliance server side, moves the logic out of the client and into a transparent and centrally managed service. This can allow business logic to focus on the core logic and not on logic to retry requests or manage the multi-regional aspect of a dependent service
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
Prosecution Insights