DETAILED ACTION
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax, Regular postal mail, or EFS Web (PTO/SB/439).
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-36 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 1, 10, 18, and 26, recite “a buffer used to transfer information between a plurality of wireless network computing resource, wherein at least one of the plurality of wireless network computing resources uses a processor that uses the data transport protocol different from at least one other data transport protocol used by a processor of the at least one other wireless network computing resource.” Examiner cannot find any mention of the claim limitation. Examiner can only find mention of “to transfer data between a plurality of 5G-NR computing resources” see ¶[0084]. Applicant should point to support or remove the subject matter.
Claims 2-9, 11-17, 19-25, 27-36 are rejected based on dependency.
Regarding claim 2, recites “without the at least one other wireless computing resource having information about the data transport protocol used by the at least one of the plurality of wireless computing resources,” 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 protocol” in ¶ [0072] 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-36 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 claim 1, recites “circuitry to, in response to an API, identify,” “cause” It is not clear if applicant intends to claim the circuitry only or the API, the circuitry does not actually identify or cause performance, and it is not clear how it could, since normally circuits execute instructions stored in memory that do certain things. In addition, the claim recites “circuitry to identify,” “circuitry to cause,” “to obtain,” “to transfer,” it is not clear whether these actions are performed or merely intended to. The broadest reasonable interpretation does not require the step to be performed.
Regarding claims 2-9, recite similar limitations, for example, “is to be transferred” in claim 3, “to perform” in claim 5 and “to cause,” “to perform” in claim 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. The recitation of “one or more circuits to perform” after the medium step does not make grammatical sense. It is not clear what the instructions are. It is not clear how the medium can contain circuits, as those are normally in processors.
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.
Claim 27-35, 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 be transferred”, etc.
Claim 36 is rejected based on dependency to claim 1, and contain the same issues as claim 1.
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-23, 25-33, 35, and 36 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-9, 11-17, 19-23, 25, 27-22, and 35 of copending Application No. 17/720203 in view of Riddoch et al. (U.S. PG PUB 2007/0183418).
Regarding claim 1, 10, 18, and 26, Application No. 17/720203 teaches all the limitations of the claims except corresponding to the API by at least using a mapping between the API and the one or more functions (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.” 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. API calls which cannot be serviced by the transport libraries that are available directly to the application can typically be passed on through the interface between the application and the operating system to be handled by the libraries that are available to the operating system or modules within the operating system. For implementation with many operating systems it is convenient for the transport libraries to use existing Ethernet/IP based control-plane structures: e.g. SNMP and ARP protocols via the OS interface.”).
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/720203 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/720203 teaches all the limitations of the claim except wherein the circuitry is further to, in response to the API call, cause the at least one other wireless computing resource to receive the data stored in the buffer from the at least one of the plurality of wireless computing resource without the at least one other wireless computing resource having information about the data transport protocol used by the at least one of the plurality of wireless computing resource. However, Riddoch teaches wherein the circuitry is further to, in response to the API call, cause the at least one other wireless computing resource to receive the data stored in the buffer from the at least one of the plurality of wireless computing resource without the at least one other wireless computing resource having information about the data transport protocol used by the at least one of the plurality of wireless computing resource (see ¶[0014] “In order for an application to retrieve a data buffer it must invoke the OS API (step v), for example by means of a call such as recv( ), select( ) or poll( ). This has the effect of informing the application that data has been received and (in the case of a recv( ) call) copying the data from the kernel buffer to the application's buffer. The copy enables the kernel (OS) to reuse its network buffers, which have special attributes such as being DMA accessible and means that the application does not necessarily have to handle data in units provided by the network, or that the application needs to know a priori the final destination of the data, or that the application must pre-allocate buffers which can then be used for data reception.”).
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/720203 by adapting Riddoch in order provide existing connections to be reconfigured on a resource-by-resource basis (see ¶ [0086] of Riddoch).
Claims 3-9, 11-17, 19-23, 25, 27-33, and 35 of current application are substantially the same or identical to claims 3-9, 11-17, 19-23, 25, 27-33, and 35 of copending Application No. 17/720203, respectively, and are rejected.
Regarding claim 36, Application No. 17/720203 teaches all the limitations of the claim except wherein at least two of the plurality of wireless computing resources uses different communication protocols.
However, Riddoch teaches wherein the one or more functions correspond to one or more APIs of the data transport protocol (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.”).
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/720203 by adapting Riddoch in order provide existing connections to be reconfigured on a resource-by-resource basis (see ¶ [0086] of Riddoch).
This is a provisional nonstatutory double patenting rejection.
Claim 24 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 24 of copending Application No. 17/720203 in view of Lym et al. (U.S. PG PUB 2005/0097245).
Regarding claim 24, Application No. 17/720203 teaches all the limitations of the claim except
a reference counter associated with the allocated buffer remains unchanged after performance of the API. However, Lym teaches a reference counter associated with the allocated buffer remains unchanged after performance of the API (see ¶ [0124] “The Current Indication Buffer Count function returns the total count of indication buffers in the indication buffer pool. The returned value is the current count of indication buffers.”).
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/720203 by adapting Lym in order to keep track of information.
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 34 of copending Application No. 17/720203 in view of Roy et al. (U.S. PG PB 2023/0044165).
Regarding claim 34, Application No. 17/720203 teaches all the limitations of the claim except the storage selected is further to be used as part of a zero copy buffer method. However, Roy teaches the storage 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 Application No. 17/720203 by adapting Roy to improve the ability of the client to process the requested data (see ¶ [0021] of Roy).
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-6, 8-13, 15, 18-20, 26, 33, 35, and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) in view of Hendel et al. (U.S. PG PUB 2014/0310370).
Regarding claim 1, Riddoch teaches one or more processors comprising: circuitry to, in response to an application programming interface (API) call (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.”)
cause performance of the one or more functions to obtain data from a buffer used to transfer information between a plurality of wireless computing resources (see ¶[0014] “In order for an application to retrieve a data buffer it must invoke the OS API (step v), for example by means of a call such as recv( ), select( ) or poll( ). This has the effect of informing the application that data has been received and (in the case of a recv( ) call) copying the data from the kernel buffer to the application's buffer.”),
wherein at least one of the plurality of wireless network computing resources uses a processor that uses a data transport protocol different from at least one other data transport protocol used by a processor of at least one other wireless network computing resource (see ¶ [0009] “Some API calls may be handled by the transport libraries that have been provided to support the network interface device. API calls which cannot be serviced by the transport libraries that are available directly to the application can typically be passed on through the interface between the application and the operating system to be handled by the libraries that are available to the operating system or modules within the operating system. For implementation with many operating systems it is convenient for the transport libraries to use existing Ethernet/IP based control-plane structures: e.g. SNMP and ARP protocols via the OS interface.”);
Riddoch does not expressly disclose, however, Hendel teaches
Identify one or more functions, from a library of a data transport protocol, corresponding to the API by at least using a mapping between API and the one or more functions (see ¶[0035] “The commands from the API may be mapped to a transport protocol over a network for NDDS support of object storage. For example, the API commands may be mapped to RoCE. In some implementations a stack architecture 200 in which the NDDS layer bypasses the storage layer may be implemented to support object storage. At the NSAC, the received commands may be RoCE terminated and processed through an API processing layer to translate the commands back into a form supporting object storage on the NSAC.”).
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 by adapting Hendel to support network communications over one or more protocols (see ¶[0016] of Hendel).
Regarding claim 2, Riddoch teaches wherein the circuitry is further to, in response to the API call, causes the at least one other wireless computing resource to receive the data stored in the buffer from the at least one of the plurality of wireless computing resource without at least one other wireless computing resource having information about the data transport protocol used by the at least one of the plurality of wireless computing resource (see ¶[0014] “In order for an application to retrieve a data buffer it must invoke the OS API (step v), for example by means of a call such as recv( ), select( ) or poll( ). This has the effect of informing the application that data has been received and (in the case of a recv( ) call) copying the data from the kernel buffer to the application's buffer. The copy enables the kernel (OS) to reuse its network buffers, which have special attributes such as being DMA accessible and means that the application does not necessarily have to handle data in units provided by the network, or that the application needs to know a priori the final destination of the data, or that the application must pre-allocate buffers which can then be used for data reception.”).
Regarding claim 3, Riddoch does not expressly disclose, however, Hendel teaches wherein the one ore more functions correspond to the data transport protocol; and the API corresponds to the at least one other data transport protocol (see ¶[0035] “The commands from the API may be mapped to a transport protocol over a network for NDDS support of object storage. For example, the API commands may be mapped to RoCE. In some implementations a stack architecture 200 in which the NDDS layer bypasses the storage layer may be implemented to support object storage. At the NSAC, the received commands may be RoCE terminated and processed through an API processing layer to translate the commands back into a form supporting object storage on the NSAC.”).
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 by adapting Hendel to support network communications over one or more protocols (see ¶[0016] of Hendel).
Regarding claim 4, Riddoch teaches wherein the circuitry are further perform the one or more functions of the data transport protocol (see ¶[0008] “User level protocol processing stacks can enable data transfers using standard protocols to be made without requiring data to traverse the kernel stack. It is desirable for the network interface device to be capable of supporting standard transport level protocols such as TCP, UDP, RDMA and ISCSI at user level.”); and perform one or more functions of another different 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 5, Riddoch teaches wherein the circuitry is to further, in response to the API call, identify, from a plurality of data transport protocols, the data transport protocol (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 does not expressly disclose, however, Hendel teaches wherein an abstraction layer interfaces between layer 2 and layer 3 of a network protocol stack, the abstraction layer comprising a plurality of data transport protocol libraries (see ¶[0026] “FIG. 5 shows an example NSAC stack 500. In various implementations, the example NSAC stack may execute on the processors 104 and/or storage circuitry 114 of a NSAC 160. In the example, the NSAC stack 500 may include network protocol termination 502 for communications received from the network layer 221 of host stack architecture, e.g., 200, 300, 400. For example, the NSAC stack 500 may include a layer for de-encapsulation of commands received from a host over the network. The layer may de-encapsulate commands from ethernet transport packets. Additionally or alternatively, the layer may de-map commands from transport protocols, such as RoCE, to allow for block command recovery. In some cases, the layer may include a RoCE termination layer for processing RoCE compliant communications.”).
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 by adapting Hendel to support network communications over one or more protocols (see ¶[0016] of Hendel).
Regarding claim 8, Riddoch teaches wherein: the plurality of wireless computing resources are associated with a wireless network protocol stack that includes a first layer, a second layer, and a third layer (see ¶[0040] “More generally, a NIC has limited capacity to maintain multicast group membership information. For example the NIC might support multicast group membership of only some predetermined number N endpoints have joined the group, or it might support multicast group membership as long as the total number of endpoint memberships within the host computer system, including all multicast groups, does not exceed some maximum number M.”);
a first wireless computing resource of the plurality of wireless computing resources is associated with the first layer (see ¶ [0004] “The kernel executes in kernel mode, also sometimes called trusted mode or a privileged mode, whereas application level processes (also called user level processes) execute in a user mode”);
a second wireless computing resource of the plurality of wireless computing resources is associated with the second layer (see ¶ [0005] “Each time a kernel routine is called, the current privilege level increases to kernel mode in order to allow the routine to access the hardware directly. When the kernel relinquishes control back to a user process, the current privilege level returns to that of the user process.”);
the API is associated with the third layer (see ¶ [0016] “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.”); and
the third layer is located between the first and second layers (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 9, Riddoch teaches wherein the circuitry is further to, in response to the API call: transfer information between a first layer and a second layer corresponding to a wireless network protocol, wherein one or more of the plurality of wireless computing resources associated with the data transport protocol (see ¶ [0017] “If successful, the system call returns with an indication of the data scheduled (by the hardware) for transmission. However there are a number of circumstances where data does not become enqueued by the network interface device. For example the transport protocol may queue pending acknowledgments or window updates, and the device driver may queue in software pending data transmission requests to the hardware.”);
and cause one or more of the plurality of wireless computing resources associated with the first layer to perform an operation associated with the data transport protocol (see ¶[0022] “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.)”).
Regarding claim 10, is rejected for the same reasons as claim 1. Further, Riddoch teaches a system, comprising memory to store instructions that, as a result of execution by one or more processors (see ¶[0095] memory):
Regarding claim 11, Riddoch teaches wherein performance of the API is based, at least in part, on the at least one other transport protocol (see ¶[0157] “Step 2212 begins an example sequence of steps in which the application process uses a UDP transport protocol. In step 2212 the application makes a call to the socket( ) routine of the user level transport library 1224, specifying that it would like a UDP socket.”).
Regarding claim 12, Riddoch teaches wherein: the information is to be transferred between a first layer and a second layer of a wireless network protocol stack (see ¶ [0008] “User level protocol processing stacks can enable data transfers using standard protocols to be made without requiring data to traverse the kernel stack. It is desirable for the network interface device to be capable of supporting standard transport level protocols such as TCP, UDP, RDMA and ISCSI at user level.”);
and the first layer and second layer are each associated with a different 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 13, Riddoch teaches wherein an application associated with the one or more of the plurality of wireless computing resources calls the API and does not have information regarding any transport protocol supported by the at least one other wireless computing resource (see ¶[0170] “The source IP address and port may be left as zeros if the application does not know them. The application does not necessarily know the destination IP address and port to which the packet will be directed”).
Regarding claim 15, Riddoch 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 ¶ [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 18, is rejected for the same reasons as claim 1. Further, Riddoch teaches a machine-readable medium having stored thereon one or more instructions, which if performed by one or more processors (see ¶[0095] memory).
Regarding claim 19, Riddoch teaches wherein performance of the API is based, at least in part, on a transport configuration associated with one of the plurality of wireless computing resources (see ¶[0023] “Broadcast packets are typically used for network configuration and management purposes, rather than content transmission. On IP-based networks, a broadcast data packet is identified by a destination address of 255.255.255.255, which is a 32-bit address of all 1's. Virtually all NICs will receive broadcast data packets and forward them on to the kernel for further processing, regardless of whether the NIC performs hardware filtering.”).
Regarding claim 20, Riddoch teaches wherein: the information is to be transferred between a first layer and a second layer of a wireless 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 ¶[0008] “User level protocol processing stacks can enable data transfers using standard protocols to be made without requiring data to traverse the kernel stack. It is desirable for the network interface device to be capable of supporting standard transport level protocols such as TCP, UDP, RDMA and ISCSI at user level.”).
Regarding claim 26, is an independent method claim, and corresponds with processor claim 1, and is rejected for the same reasons as claim 1.
Regarding claim 33, Riddoch teaches wherein: the information is to be transferred between two layers of a wireless network protocol stack, wherein each layer is associated with a different 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.”); and
the API is located in a third layer (see ¶[0016] “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 35, Riddoch teaches wherein the information includes different messages each associated with a different information transmission type (see ¶ [006] “Here protocol is applied and fully formed TCP/IP packets are enqueued with the interface driver for transmission.”);
and the information is to be transferred between two of the plurality of wireless computing resources using one transport (see ¶[0009] “FIG. 1 illustrates one implementation in which user level protocol stacks are incorporated. In this architecture the TCP (and other) protocols are implemented twice: as denoted TCP1 and TCP2. In a typical operating system TCP2 will be the standard implementation of the TCP protocol that is built into the operating system of the computer. 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.”).
Regarding claim 36, Riddoch teaches wherein the one or more functions correspond to one or more APIs of the 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.”).
Claim(s) 7 under 35 U.S.C. 103 as being unpatentable over Riddoch et al. (U.S. PG PUB 2007/0183418) and Hendel et al. (U.S. PG PUB 2014/0310370) as applied in claims 1 above, further in view of Aijaz (U.S. PG PUB 2021/0328736).
Regarding claim 7, Riddoch and Hendel do not expressly disclose, however Aijaz teaches wherein the circuitry is to further, in response to the API call, cause one or more of the plurality of wireless computing resources to perform the one or more functions related to the data transport protocol by using a transport abstraction layer of a Fifth Generation New Radio (5G-NR) network protocol stack (see ¶[0046] “FIG. 1 illustrates the architecture and protocol stack (user-plane as well as control-plane) of a 5G New Radio (NR) network. As shown, the core network comprises a plurality (in this case two) of networked computers, in wireless connection with a radio access network (RAN) comprising a plurality of base stations in wireless and/or wired interconnection with each other.”).
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 Hendel by adapting Aijaz for supporting very high data rates, massive machine type communications (mMTC) for supporting a large number of devices, and ultra-reliable low latency communications (uRLLC) for real-time control applications (see ¶[0020] of Aijaz).
Claim(s) 17, 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 Hendel et al. (U.S. PG PUB 2014/0310370) as applied in claims 10, 18, and 26 above, further in view of Wei et al. (U.S. PG PUB 2014/0099119).
Regarding claim 17, Riddoch and Hendel do not expressly disclose, however, Wei teaches wherein one or more of the plurality of wireless resources is a virtual device (see ¶ [0041] virtual machines).
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 Hendel by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 21, Riddoch and Hendel do not expressly disclose, however, Wei teaches wherein the one or more circuits are further to perform the API without information associated with a transmission type associated with one or more of the plurality of the wireless computing resources ((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 Hendel by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 23, Riddoch and Hendel do not expressly disclose, however, Wei teaches wherein: the at least one other wireless 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 implotherented by a client, service provider, and/or other network operators.”); and
performance of the API causes, at least in part, the at least one of the plurality of wireless computing resources to transfer the information to the at least one other wireless computing resource that supports different transport protocols without modification to the at least one of the plurality of wireless computing resources (see ¶[0026] “The layer may de-encapsulate commands from ethernet transport packets. Additionally or alternatively, the layer may de-map commands from transport protocols, such as RoCE, to allow for block command recovery. In some cases, the layer may include a RoCE termination layer for processing RoCE compliant communications.” See ¶[0035] “The commands from the API may be mapped to a transport protocol over a network for NDDS support of object storage. For example, the API commands may be mapped to RoCE. In some implementations a stack architecture 200 in which the NDDS layer bypasses the storage layer may be implemented to support object storage. At the NSAC, the received commands may be RoCE terminated and processed through an API processing layer to translate the commands back into a form supporting object storage on the NSAC.”).
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 Hendel by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 25, Riddoch and Hendel do not expressly disclose, however, Wei teaches wherein the at least one other wireless computing resource has been configured with a transport profile supported by the at least one of the plurality of wireless computing resources (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 Hendel by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 27, Riddoch and Hendel do not expressly disclose, however, Wei teaches wherein performance of the API is based, at least in part, on a transport profile associated with the at least one other wireless computing resources (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 Hendel by adapting Wei in order to have more flexibility and interoperability.
Regarding claim 28, Riddoch and Hendel do not expressly disclose, however, Wei teaches further comprising identifying one or more transport profiles supported by one or more of the plurality of wireless computing resources (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 Hendel 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 Hendel et al. (U.S. PG PUB 2014/0310370) as applied in claims 18 above, further in view of Xu et al. (U.S. PG PUB 2021/0149578).
Regarding claim 22, Riddoch and Hendel 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 Hendel 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 Hendel et al. (U.S. PG PUB 2014/0310370) as applied in claims 10 and 26 above in view of Lin et al. (U.S. PG PUB 2013/0074151).
Regarding claim 14, Riddoch and Hendel 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 Hendel by adapting Lin in order to better process transactions.
Regarding claim 32, Riddoch and Hendel 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 Hendel 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 Hendel et al. (U.S. PG PUB 2014/0310370) as applied in claims 10, 18, and 26 above in view of Young (US PG PUB 2021/0320850).
Regarding claim 16, Riddoch and Hendel do not expressly disclose, however, Young teaches further comprising: a network orchestrator configured to identify one or more transport profiles supported by the at least one of the pl