DETAILED ACTION
This communication is in response to the application filed on 6/24/2024 in which claims 1-20 are pending in the application. Claims 1, 12, and 17 are in independent form.
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 .
Response to Preliminary Amendment
Applicant’s preliminary amendment dated 6/24/2024, amending claims 10, 15, and 20 and cancelling claims 21-25 has been fully considered and is entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/24/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 4, 10, 11, and 17is/are rejected under 35 U.S.C. 103 as being unpatentable over Regupathy et al. (US 20210055777) in view of Kashyap (US 20090157882).
Regarding claim 1, Regupathy teaches: A system comprising: a processor to execute a native operating system (OS) (processors 1070 and 1080 par. 0098 running in an ecosystem/operating system par. 0069 – 0070); and an interface circuit coupled to the processor (point to point interface circuits which processors use to exchange data par. 0098), the interface circuit configured to tunnel communications of a plurality of tunneled protocols (a host interface connection manager influences the OSPPM by utilizing tunneled protocols par. 0067 - 0073), the interface circuit to couple to at least one device via a first tunneled protocol (the USB4 device can be an endpoint device, peripheral device, memory, or other type of device that connects to the USB4 host and/or USB4 hub par. 0028 – 0035);
Regupathy does not explicitly teach a connection manager for the interface circuit is to execute in a user space of the native OS.
However, Kashyap teaches: wherein a connection manager for the interface circuit is to execute in a user space of the native OS (the connection managers may be implemented in software such as operating system code, or as combined user space/kernel code par. 0035).
Both Regupathy and Kashyap are in the same field of endeavor that includes connection managers that maintain connections/communications and protocols for endpoints.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy with the teachings of Kashyap in order to provide an enhancement to the connection manager in which multiple connection managers may be used to handle portions of network connection within user space/kernel code.
Modification would allow for the system of Regupathy to use a connection manager which is implemented as a user space application in a virtual application environment as well as allow for collection of TXP state information (socket data) of original source sockets as shown in Kashyap (par. 0063 – 0064).
Regarding claim 2, Regupathy teaches: further comprising a Peripheral Component Interconnect Express (PCIe) memory space (A USB4 host can optionally contain a PCIe controller which can be connected to various peripheral devices for routing par. 0031 and 0028), wherein at least a portion of the PCIe memory space comprises the connection manager (the connection manager is located within the USB4 host par. 0032)
Regupathy does not explicitly teach that a connection manager is mapped to the user space.
However, Kashyap teaches: wherein the connection manager is mapped to the user space (connection managers may be implemented as user space/kernel code par. 0035).
Both Regupathy and Kashyap are in the same field of endeavor that includes connection managers that maintain connections/communications and protocols for endpoints.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy with the teachings of Kashyap in order to provide an enhancement to the connection manager in which multiple connection managers may be used to handle portions of network connection within user space/kernel code.
Modification would allow for the system of Regupathy to use a connection manager which is implemented as a user space application in a virtual application environment as well as allow for collection of TXP state information (socket data) of original source sockets as shown in Kashyap (par. 0063 – 0064).
Regarding claim 4, Regupathy teaches: wherein the connection manager comprises a control plane for the interface circuit (the USB connection manager may monitor control plane messages par. 0076).
Regarding claim 10, Regupathy teaches: wherein the interface circuit comprises a Universal Serial Bus (USB) interface circuit (USB system includes USB4 hosts and hubs connected by a USB link further connected to any peripheral device par. 0028 – 0030) and the first tunneled protocol comprises a Thunderbolt protocol (the USB4 ports can support thunderbolt products par. 0033 – 0034).
Regarding claim 11, Regupathy teaches: wherein the processor comprises a peripheral hub circuit to execute the connection manager (the USB system includes a USB4 hub that connects to peripheral devices, the USB system implementing a connection manager par. 0073 – 0074 and 0028 – 0030).
Regarding claim 17, Regupathy teaches: a client device comprising: a processor to execute a native operating system (OS) (processors 1070 and 1080 par. 0098 running in an ecosystem/operating system par. 0069 – 0070); and a Universal Serial Bus (USB) interface circuit coupled to the processor (point to point interface circuits which processors use to exchange data par. 0098), the USB interface circuit configured to tunnel communications of a plurality of tunneled protocols (a host interface connection manager influences the OSPPM by utilizing tunneled protocols par. 0067 - 0073), the USB interface circuit to couple to a peripheral device via a first tunneled protocol (the USB4 device can be an endpoint device, peripheral device, memory, or other type of device that connects to the USB4 host and/or USB4 hub par. 0028 – 0035), and the peripheral device coupled to the client device via a USB link (the USB4 device can be an peripheral device that is connected/coupled to the USB4 hub par. 0028).
Regupathy does not explicitly teach a connection manager for the USB interface circuit is to execute in a user space of the native OS.
However, Kashyap teaches: wherein a connection manager for the USB interface circuit is to execute in a user space of the native OS (the connection managers may be implemented in software such as operating system code, or as combined user space/kernel code par. 0035).
Both Regupathy and Kashyap are in the same field of endeavor that includes connection managers that maintain connections/communications and protocols for endpoints.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy with the teachings of Kashyap in order to provide an enhancement to the connection manager in which multiple connection managers may be used to handle portions of network connection within user space/kernel code.
Modification would allow for the system of Regupathy to use a connection manager which is implemented as a user space application in a virtual application environment as well as allow for collection of TXP state information (socket data) of original source sockets as shown in Kashyap (par. 0063 – 0064).
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regupathy and Kashyap further in view of Weisshaar et al. (US 6757262).
Regarding claim 3, Weisshaar teaches: wherein the connection manager is decoupled from the system (the connection manager service is a component external to the service framework Col. 19 Lines 30 – 43), the connection manager comprising a connection manager daemon (the connection manager service comprises a proximity-detecting program module that sends a notification of a communications interface coming up or going down to the proximity daemon Col. 17 Lines 38 – 47).
Regupathy, Kashyap, and Weisshaar are all in a similar field of endeavor including connection manager services providing communication interfaces within a system.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy and Kashyap with the teachings of Weisshaar since the teachings of Weisshaar would provide an external connection manager that includes a daemon that provides notification of communication interfaces.
Modification would allow for the connection manager of the prior combination to be able to perform operation from outside of the system as well as contain/work directly with a daemon for communication management purposes (Weisshaar Col. 17 Line 18 – Col. 19 Line 43).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regupathy and Kashyap further in view of Zelenov et al. (US 20190163509).
Regarding claim 5, Zelenov teaches: wherein the connection manager comprises a virtualized connection manager to handle interface requests from a plurality of guest Oss (the host OS 145 may further include a virtual USB hub 147 that virtualizes a USB hub to manage one or more virtual USB devices 149 for use by virtual machine 150 and/or host OS 145 par. 0019), the native OS comprising a host OS (host OS of a host computer system par. 0009).
Regupathy, Kashyap, and Zelenov are all in a similar field of endeavor that relates to virtualized USB hubs that manage various USB devices.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy and Kashyap with the teachings of Zelenov since the teachings of Zelenov would allow for the USB hub to be virtualized and manage virtual USB devices instead of strictly physical ones.
Modification would allow for the USB hub of the prior combination to become virtualized and manage one or more virtual USB devices, virtual machines, and virtual hosts (Zelenov Par. 0019).
Claim(s) 9, 18, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regupathy and Kashyap in view of Kirsche et al. (US 11182695).
Regarding claim 9, Kirsche teaches: further comprising at least one application programming interface to enable a cloud entity to manage the interface circuit (API circuitry may include a separate processor, application specific interface circuit, or cloud utility to perform functions Col. 38 Lines 13 – 35), wherein the system comprises a client device (programmatic client device Col. 38 Lines 13 – 35).
Regupathy, Kashyap, and Kirsche are all in a similar field of endeavor that relates to interface circuitry and managing communication between client devices using API/communication protocols.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy and Kashyap with the teachings of Kirsche since the teachings of Kirsche would allow for cloud utilities to perform functions on programmatic client devices that include various management systems.
Modification would allow for the prior combination’s system to be enhanced by the potential of using API circuitry to include cloud utility that can perform various functions and utilize communication paths between user and client devices (Kirsche Col. 38 Lines 13 – 35).
Regarding claim 18, Kirsche teaches: wherein the client device comprises a hybrid client device to be managed by a cloud entity (programmatic client device that can be controlled via cloud utility Col. 38 Lines 13 – 35), wherein the cloud entity is to further manage the USB link via the connection manager (API circuitry may include a separate processor, application specific interface circuit, or cloud utility to perform functions Col. 38 Lines 13 – 35).
Regupathy, Kashyap, and Kirsche are all in a similar field of endeavor that relates to interface circuitry and managing communication between client devices using API/communication protocols.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy and Kashyap with the teachings of Kirsche since the teachings of Kirsche would allow for cloud utilities to perform functions on programmatic client devices that include various management systems.
Modification would allow for the prior combination’s system to be enhanced by the potential of using API circuitry to include cloud utility that can perform various functions and utilize communication paths between user and client devices (Kirsche Col. 38 Lines 13 – 35).
Regarding claim 19, Kirsche teaches: further comprising at least one application programming interface to enable the cloud entity to manage the USB interface circuit (API circuitry may include a separate processor, application specific interface circuit, or cloud utility to perform functions Col. 38 Lines 13 – 35).
Regupathy, Kashyap, and Kirsche are all in a similar field of endeavor that relates to interface circuitry and managing communication between client devices using API/communication protocols.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy and Kashyap with the teachings of Kirsche since the teachings of Kirsche would allow for cloud utilities to perform functions on programmatic client devices that include various management systems.
Modification would allow for the prior combination’s system to be enhanced by the potential of using API circuitry to include cloud utility that can perform various functions and utilize communication paths between user and client devices (Kirsche Col. 38 Lines 13 – 35).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regupathy in view of Regupathy et al. (US 20200192832) hereby known as Reference R.
Regarding claim 12, Regupathy teaches: receiving a first management request from a first guest OS, the first management request for the USB interface circuit (link management packets originate in the transport layer of a router at one end of the link and terminate in the transport layer of the other router at the other end of the link, these link management packets include time sync packets, flow control packets, and idle packets for managing communications par. 0056); and managing a topology of the USB interface circuit, via the connection manager mapped to the user space, based at least in part on the first management request (protocol traffic, which includes link management packets as well as transport layer packets and tunneled packets, allow for lane initialization, connection or disconnection on a USB4 port, lane disable or enable, and entry or exit from a sleep state par. 0056 – 0061).
Regupathy does not explicitly teach mapping a memory space of a connection manager for a universal serial bus (USB) interface circuit to a user space of a native operating system (OS) of a cloud client device.
However, Reference R teaches: A method comprising: mapping a memory space of a connection manager for a universal serial bus (USB) interface circuit to a user space of a native operating system (OS) of a cloud client device (a USB4 connection manager 72 sets up a USB driver 74, a PCIe bus driver 76, and a display kernel mode driver 78 to tunnel USB4 packets into a host router 80, which is coupled to a USB4 port par. 0025 using cloud computing infrastructure 28 par. 0016);
Both Regupathy and Reference R are in the same field of endeavor that includes USB4 tunneled protocol as well as connection managers used for communication purposes.
It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Regupathy and Reference R since the teachings of Reference R would provide an enhancement to the previous system by utilizing cloud computing infrastructure.
Modification would allow for the system of Regupathy to utilize cloud computing infrastructure as well as connection manager daemons to facilitate USB4 protocol communication (Reference R par. 0015 – 0017).
Allowable Subject Matter
Claims 6-8, 13-16, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Regupathy et al. (US 20190272181) which outlines management of I/O devices within a virtualized execution environment including a power manager.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN SCOTT MOTTER whose telephone number is (703)756-1550. The examiner can normally be reached Monday - Friday 7:30 AM - 4:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Pierre Vital can be reached at 571-272-4215. 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.
/J.S.M./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights