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 plurality of wireless computing resources, wherein the network orchestrator is to deploy the at least one other wireless network computing resource configured with a transport profile supported by at least one of the plurality of wireless 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 Hendel 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 Hendel do not expressly disclose, however, Young teaches further comprising: configuring one wireless computing resource of the plurality of wireless computing resources with transport profiles supported by the at least one of the plurality of wireless computing resources (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 wireless computing resource with a second wireless 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 Hendel 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 Hendel do not expressly disclose, however, Young teaches wherein the API is to be called by the at least one other wireless computing resource that was deployed with a second wireless computing resource of the plurality of 5G-NR computing resources, wherein the second wireless 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 Hendel 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) 24 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 in view of Lym et al. (U.S. PG PUB 2005/0097245).
Regarding claim 24, Riddoch and Hendel do not expressly disclose, however, Lym teaches wherein: the buffer selected is an allocated buffer (see ¶[0007] “In a transmitting application, the Skipstone API actively manages the transfer of data from the appropriate portion of the appropriate buffer onto the bus structure, during the appropriate time period. In a receiving application, the Skipstone API actively manages the reception of data from the bus structure, storing the data in the appropriate portion of the appropriate buffer and the processing of the data in the appropriate time period.”); and
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 Riddoch and Hendel by adapting Lym in order to keep track of information.
Claim(s) 31 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 26 above, further in view of Zhang et al. (U.S. PG PUB 2021/0360714).
Regarding claim 31, Riddoch and Hendel 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 Hendel 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 Hendel et al. (U.S. PG PUB 2014/0310370) as applied in claims 26 above, further in view of Roy et al. (U.S. PG PB 2023/0044165).
Regarding claim 34, Riddoch and Hendel do not expressly disclose, 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 Riddoch and Hendel by adapting Roy to improve the ability of the client to process the requested data (see ¶ [0021] of Roy).
Response to Arguments
Applicant's arguments filed 4/3/2025 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 non-statutory 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 argue “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” is supported in ¶[0083] and [0090] and [0082].
Examiner disagrees. Examiner can only find mention of “to transfer data between a plurality of 5G-NR computing resources.” 5G-NR computing resource appears to be different from wireless network computing resource.
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.
Regarding Prior Art Rejections, applicants’ arguments are moot due to the new grounds of rejections. Examiner has applied new prior art.
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.
Thanker et al. (U.S. PG PUB 2015/0006318) teaches adapting legacy endpoints to modern application protocol interfaces (APIs). A legacy endpoint may provide a powerful and complex API. A modern application may desire access to the legacy endpoint. One or more layers may be added between the modern application and the legacy endpoint. Each layer may provide a different API. These layers of APIs may transform the interface from a powerful and complex interface to a more limited but simpler and easier to use interface. In some example embodiments, a proxy layer, an adapter layer, a facade layer, and a service layer may be used.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARINA YUN whose telephone number is (571)270-7848. The examiner can normally be reached Mon, Tues, Thurs, 9-4 (EST).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to call.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Carina Yun
Patent Examiner
Art Unit 2194
/CARINA YUN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights