DETAILED ACTION
This communication is in response to the application filed on 05/23/2024 in which claim 1-20 are pending in the application. Claims 1,15, and 18 are 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 .
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.
Claims 1, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117), in view of Lewis (US 20130061242).
As per claim 1 Pellowski discloses
An Information Handling System (IHS), comprising: a processor; and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to: [col 3 lines 5-13] “Control circuitry 76 includes a processor 78 and memory 80. Processor 78 may be any kind of processing device for performing operations…. a collection of circuits configured to perform various operations, a storage processor, or another similar device or set of devices configured to perform operations.”
receive, at a kernel driver of a host Operating System (OS) [col. 5 lines 3-6], “sends the reformatted kernel driver control command 99 to the target host server via the selected protocol path for execution by a kernel driver 34, 56 running on the target host server”, a message from a host OS application for distribution to an Embedded Controller (EC) [col. 3 lines 47-48], “In step 110, CLI 82 receives a kernel driver control command 97 from the user 53 via the UI 70” [col. 3 lines 52-55], “…instead of receiving the kernel driver control command 97 from the user 53 via the UI 70, kernel driver control command 97 may be received from another application via a programmatic interface.”;
translate the message, by the kernel driver, into an Application Programming Interface (API) call corresponding to a selected one of a plurality of data transfer paths between the kernel driver and the EC [col. 4 lines 58-62], “In step 140, the protocol switch 86 reformats the XML (or JSON, etc.) command 98 (or, in some embodiments, the raw user command 97) into a protocol format associated with the selected protocol path, thus forming reformatted command 99”, based, at least in part, upon a type of the processor [col. 5 lines 13-17], “a single client can communicate with many remote host servers according to a proper protocol for each individual host server's requirements”; and
transmit the API call by the kernel driver to the EC via the selected data transfer path [col. 5 lines 7-11], “sending the reformatted kernel driver control command to the target host via the selected protocol path for execution by a kernel driver running on the target host”.
Under BRI, “Embedded controller (EC)” reads on “Control circuity” disclose in Pellowski [col 3 lines 5-13]
Pellowski does not explicitly disclose “translating based, at least in part, upon a type of the processor”
However, Lewis disclose ([0011], “enable system firmware services to be utilized from within an operating system on x86 and non-x86 processors. Embodiments of the invention create an execution environment (denoted SAFE) that mimics many of the attributes of the System Management Mode (SMM) found on X86 CPUs on CPUs and platforms that do not support SMM” and [0012], “the firmware may identify an appropriate service handler to perform the requested service”).
Pellowski and Lewis are in similar fields of endeavor because both relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, and with the teachings of Lewis to translate the message, by the kernel driver, into an Application Programming Interface (API) call corresponding to a selected one of a plurality of data transfer paths between the kernel driver and the EC, based, at least in part, upon a type of the processor.
Motivation to combine would be to improve the system performance and reliability by enhancing communication, flexibility and scalability between the type of processors when translating a message into an API call.
As per claim 15, it has similar limitation as claim 1, therefore is rejected under the same rationale.
As per claim 18, it has similar limitation as claim 1, therefore is rejected under the same rationale.
Claims 2, 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117) in view of Lewis (US 20130061242), in view of Molteni et al. (US 20240143367).
As per claim 2, Pellowski and Lewis disclose the system of claim 1 detailed above.
Pellowski and Lewis does not explicitly disclose
“wherein the type of the processor comprises a Reduced Instruction Set Computer (RISC) architecture or a Complex Instruction Set Computer (CISC) architecture.”
However, Molteni disclose “wherein the type of the processor comprises a Reduced Instruction Set Computer (RISC) architecture or a Complex Instruction Set Computer (CISC) architecture.” [0059] “Processing device 602 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 602 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC)”
Pellowski, Lewis and Molteni are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, and with the teachings of Molteni that the type of processor comprises a Reduced Instruction Set Computer (RISC) architecture or a Complex Instruction Set Computer (CISC) architecture.
Motivation to combine would be to improve the system performance by either using the RISC for a faster execution or using the CISC to execute a more complex task that would lead to a more efficient memory.
As per claim 6,
Lewis further discloses “wherein in response to the type of the processor being a Complex Instruction Set Computer (CISC) processor, the selected data transfer path comprises a System Management Mode (SMM) path via an Advanced Configuration and Power Interface (ACPI) table using a Basic Input/Output System (BIOS)/Unified Extensible Firmware Interface (UEFI).” [0003] “The SMM is a special operating mode that is reserved for firmware. The SMM is used by firmware to perform certain functions is a secure manner without the possibility of interference by the operating system or an application. [0005] “Another way for applications to interact with or engage the services of the firmware is through an implementation of the UEFI specification.” [0007] “Another way in which applications may interact with or engage the services of the firmware involves an implementation of the ACPI specification.”
As per claim 7,
Lewis further disclose “wherein in response to the type of the processor being a Reduced Instruction Set Computer (RISC) processor, the selected data transfer path comprises a hardware-based security architecture accessible via a hardware-based security architecture driver.” [0086] “In ARM7 processors, a new feature known as TrustZone is available which provides similar hardware protection capabilities to those provided by SMM mode on x86 processor…. which are meant to provide certain standard capabilities to ARM platforms that support the TrustZone hardware protection features of the ARM7 processor.” [0087] “There are several models whereby SAFE 100 will work with the TrustZone feature provided by ARM7 processors. In those cases where the "monitor" is provided by a 3.sup.rd party (such as an ARM processor vendor), SAFE 100 may run as a client of the monitor. During the initialization stages of the firmware, when the TrustZone environment is being initialized, the monitor is instantiated and SAFE 100 may be instantiated as a client of the monitor, usually by registering for notification of a specific SMC sub-function. The notification may be a call into SAFE dispatcher 130. The means used to register and the means of instantiation may vary from monitor to monitor since the mechanism is not standardized. In these cases, the call from OS interface driver 186 to SAFE entry point 120 would then, in turn, use the SMC instruction with the registered sub-function to initiate SAFE functionality. “
Under Bri, “a hardware-based security architecture accessible via a hardware-based security architecture driver” which reads on the “TrustZone hardware protection” disclose by Lewis.
As per claim 8,
Lewis further disclose “wherein the hardware-based security architecture comprises a TRUSTZONE architecture.” [0086] “In ARM7 processors, a new feature known as TrustZone is available which provides similar hardware protection capabilities to those provided by SMM mode on x86 processor.”
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117) in view of Lewis (US 20130061242), in view of Jeansoone et al. (US 20160063255 A1)
As per claim 3 Pellowski and Lewis disclose the system of claim 1 detailed above.
Pellowski and Lewis does not explicitly disclose
“wherein the API call is transmitted to the EC over an Inter-Integrated Circuit (I2C), Improved I2C (I3C), Serial Peripheral Interface (SPI), or Enhanced SPI (eSPI) bus.”
However, Jeansonne disclose “wherein the API call is transmitted to the EC over an Inter-Integrated Circuit (I2C), Improved I2C (I3C), Serial Peripheral Interface (SPI), or Enhanced SPI (eSPI) bus.” [0020] “In some examples, the shared bus 220 is a shared Serial Peripheral Interface (SPI) bus. An SPI bus is a synchronous serial data link in which devices on the SPI bus operate in a master-slave mode.” [0041] The boot block 210 can access an interface, such as an application programming interface (API), of the embedded controller 202, to send an instruction to the embedded controller 202…” (See Fig 2)
Pellowski, Lewis and Jeansoone are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, and with the teachings of Jeansonne wherein the API call is transmitted to the EC over an Inter-Integrated Circuit (I2C), Improved I2C (I3C), Serial Peripheral Interface (SPI), or Enhanced SPI (eSPI) bus.
Motivation to combine would be to improve the system performance by having a faster communication of data transfers.
Claim 4, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117) in view of Lewis (US 20130061242), in view of Boyapalle (US 20220382890 A1)
As per claim 4 Pellowski and Lewis disclose the system of the claim 1 detailed above.
Pellowski and Lewis does not disclose
“wherein the message comprises a request for telemetry data.”
However, Boyapalle disclose “wherein the message comprises a request for telemetry data.” [0045] “At 435, telemetry agent 410 receives a request for telemetry data from an agent in the user space of the information handling system such as application 415. Telemetry agent 410 responds to the request by transmitting the hardware telemetry data, also referred to as platform data to application 415 at 440.”
Pellowski, Lewis and Boyapalle are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, and with the teachings of Boyapalle wherein the message comprises a request for telemetry data.
Motivation to combine would be to improve the system by enabling faster recovery through requesting a telemetry data in the event of failure or assessing health within the system.
As per claim 17, it has similar limitation as claim 4, therefore is rejected under the same rationale.
As per claim 19, it has similar limitation as claim 4, therefore is rejected under the same rationale.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable Pellowski (US 9021117) in view of Lewis (US 20130061242), in view of Boyapalle (US 20220382890 A1), in view of Iyer et al. (US 20220414026 A1)
As per claim 5, Pellowski, Lewis and Boyapalle disclose the system of claim 4 detailed above
Pellowski, Lewis and Boyapalle does not disclose
“wherein the telemetry data comprises at least one of: battery data, fan data, or thermal data.”
However, Iyer disclose “wherein the telemetry data comprises at least one of: battery data, fan data, or thermal data.” [0092] “Consumers/applications 210A-N may make calls to telemetry service 215A to receive and/or collect telemetry data of: (a) a selected depth (e.g., all registrations, class of providers—sensors, thermal data, specific device/types— TOF presence/distance, etc.)”
Pellowski, Lewis, Boyapalle and Iyer are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, with the teachings of Boyapalle, and with the teachings of Iyer wherein the telemetry data comprises at least one of: battery data, fan data, or thermal data.
Motivation to combine would be to improve the system by revealing the performance of said hardware that may be causing failure or before failure occurs based on the data given.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117), in view of Lewis (US 20130061242), in view of Bramhill (US 10176067 B1)
As per claim 9, Pellowski and Lewis disclose the system of the claim 1 detailed above.
Pellowski and Lewis does not disclose
“wherein the message comprises a request for a diagnostic operation.”
However, Bramhill disclose “wherein the message comprises a request for a diagnostic operation.” [col 5: 25-34] “When a web service receives the API request from a client device, the web service can perform a specific action and generate a response to the request and send the response to the endpoint identified in the request. For example, a user can access the diagnostic service 110 via an API request to run a diagnostic test on demand, the diagnostic service 110 can cause the requested diagnostic test to be loaded onto and executed on the hardware resources 140, results can be returned to the diagnostic service 110, and the diagnostic service 110 can send a response to the user.”
Pellowski, Lewis and Bramhill are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, with the teachings of Bramhill wherein the message comprises a request for a diagnostic operation.
Motivation to combine would be to improve the system by enabling faster recovery through requesting a diagnostics operation in the event of failure or before it occurs.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117), in view of Lewis (US 20130061242), in view of Bramhill (US 10176067 B1), in view of Pepper (US 20200042391 A1)
As per claim 10, Pellowski, Lewis and Bramhill disclose the system of claim 9 detailed above.
Pellowski, Lewis and Bramhill does not disclose
“wherein the diagnostic operation comprises at least one of: battery test, fan test, or thermal test.”
However, Pepper disclose “wherein the diagnostic operation comprises at least one of: battery test, fan test, or thermal test.” [0023] In another example, BIOS/EFI module 142 may send a category “Fan Failure” when the failure decision logic determines that cooling components are not working as expected. In this instance, diagnostic code 216 may execute all available fan tests for all possible fan sources populated in the information handling system.
Pellowski, Lewis, Bramhill and Pepper are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, with the teachings of Bramhill, and with the teachings Pepper wherein the diagnostic operation comprises at least one of: battery test, fan test, or thermal test.
Motivation to combine would be improve the system by enhancing fault detection before failure, by running a test for said hardware, which would further reveal it performance.
Claim 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117), in view of Lewis (US 20130061242), in view of Bramhill (US 10176067 B1), in view of Pepper (US 20200042391 A1), in view of Walter (US 10379995 B1)
As per claim 11, Pellowski, Lewis, Bramhill and Pepper disclose the system of the claim 10 detailed above.
Pellowski, Lewis, Bramhill and Pepper does not disclose
“receive, at the kernel driver from the EC over the selected transfer data path, a response to the API call;
translate the response into another API call usable by the host OS application;
and transmit the response to the host OS application.”
Walter disclose “receive, at the kernel driver from the EC over the selected transfer data path, a response to the API call” [col 27: 38] “At step 902, API management system 104 receives an API call….” [col 28 21-26] “At step 912, API management system 104 determines an API version associated with a destination API node, consistent with disclosed embodiments. The destination API node may be the next node to which the output will be transmitted, which may be the same API node from which the API call was received at step 902 (i.e., a source node). [col 28 lines 50-55] “…. the translated API output may be transmitted to another part of API management system 104, another component of system 100 (e.g., one of API systems 102a, 102b, 102c), and/or or a computing component outside system 100 (e.g., via interface 106).”
“translate the response into another API call usable by the host OS application;” [col 11 lines 56-60] “Translation module 338 may be configured to translate a call (an input call) to a different call (i.e., a translated call). The input call may be associated with an API and/or a particular version of an API.”
“and transmit the response to the host OS application.” [col 12 lines 45-48, 52-57] “Translation module 338 may also be configured to send a translated input to another module, such as routing module 339, another part of API Management System 104, or another device connected to Management System 104…. In some embodiments, translation module 338 may send a translated input to a module or device that processes the input to produce a result. For example, translation module 338 may send an API call to an API that processes the API call to produce an API result responsive to the call.”
Pellowski, Lewis, Bramhill, Pepper, and Walter are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, which disclose selecting a path for the set of protocol path to reach the target server, with the teachings of Lewis, with the teachings of Bramhill, with the teachings Pepper, and with the teaching of Walter which disclose receiving an API call that is needed to be transmitted, which so the responses received over the selected path by Pellowski to receive a response from the EC to the kernel driver in response to the API call.
Motivation to combine would be to improve the system by ensuring the translated response is sent back to the host OS application from what was requested from EC to the kernel driver.
As per claim 20, it has similar limitation as claim 11, therefore rejected under the same rationale.
Claim 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117), in view of Lewis (US 20130061242), in view of Bramhill (US 10176067 B1), in view of Pepper (US 20200042391 A1), in view of Walter (US 10379995 B1), in view of Orot et al. (US 20240176876 A1)
As per claim 12, Pellowski, Lewis, Bramhill, Pepper and Walter disclose the system of claim 11 detailed above.
Pellowski, Lewis, Bramhill, Pepper and Walter does not disclose
“wherein the kernel driver is configured to translate the message based, at least in part, upon a policy.”
However, Orot disclose “wherein the kernel driver is configured to translate the message based, at least in part, upon a policy.” [0034] “kernel driver 100 is configured to receive a message 600 from process 104, where message 600 is encrypted in accordance with conventional techniques, such as using a public key 602 of a key pair 604 that also includes a private key 606, prior to kernel driver 100 receiving message 600. Kernel driver 100 decrypts encrypted message 600, such as using private key 606, encrypts a response 608, such as using private key 606, and provides the encrypted response 608 to process 104…. kernel driver 100 determines, as described above, whether digital signature 112 of process 104's executable file, is valid, and then provides, or doesn't provide, encrypted response 608 to process 104 in accordance with protection policy 108, where protection policy 108 is at least partly based on whether the digital signature is valid.”
Pellowski, Lewis, Bramhill, Pepper, Walter and Orot are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, with the teachings of Bramhill, with the teachings Pepper, with the teachings of Walter, and with the teachings of Orot wherein the kernel driver is configured to translate the message based, at least in part, upon a policy.
Motivation to combine would be to improve the system by have a more secure yet reliable way for controlling how a message should be process based on the policy given.
As per claim 13,
Orot further disclose “wherein the policy comprises one or more rules usable to translate the message based, at least in part, upon an entitlement verification.” [0029] “Kernel driver 100 is further configured to modify protection policy 108 in accordance with instruction 110, preferably after kernel driver 100 determines… kernel driver 100 determines that process 104 is so authorized by determining that a digital signature 112 of computer software application 106 is valid….” (See Fig 1)
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Pellowski (US 9021117), in view of Lewis (US 20130061242), in view of Bramhill (US 10176067 B1), in view of Pepper (US 20200042391 A1), in view of Walter (US 10379995 B1), in view of Orot et al. (US 20240176876 A1), in view of Andrew et al (US 20190294800 A1)
As per claim 14, Pellowski, Lewis, Bramhill, Pepper, Walter and Orot disclose the system of the claim 13 detailed above.
Pellowski, Lewis, Bramhill, Pepper, Walter and Orot does not disclose
“wherein the policy comprises one or more rules usable to translate the message based, at least in part, upon context information, and wherein the context information comprises at least one of: a location of the IHS, an identity of a user of the IHS, a host Operating System (OS) of the IHS, an identity of the host OS application, or a network connectivity of the IHS.”
However, Andrew disclose “wherein the policy comprises one or more rules usable to translate the message based, at least in part, upon context information, and wherein the context information comprises at least one of: a location of the IHS, an identity of a user of the IHS, a host Operating System (OS) of the IHS, an identity of the host OS application, or a network connectivity of the IHS.” [0063] “which was provided to the IHS by the Certificate Authority during the provisioning phase. In some embodiments, one or more policy specific actions may take place before the encrypted key is decrypted. Examples of policy specific actions include, but are not limited… question/answer sessions to verify identity of a user or administrator”
Pellowski, Lewis, Bramhill, Pepper, Walter, Orot and Andrew are in similar fields of endeavor because they all relate to data handling and communication functions and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, with the teachings of Bramhill, with the teachings Pepper, with the teachings of Walter, with the teachings of Orot, and with the teaching of Andrews wherein policy comprises one or more rules usable to translate the message based, at least in part, upon context information, and wherein the context information comprises at least one of: a location of the IHS, an identity of a user of the IHS, a host Operating System (OS) of the IHS, an identity of the host OS application, or a network connectivity of the IHS.
Motivation to combine would be to improve the system by enhancing reliability and security by translating message according to one or more policy rules based on context information.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Pellowski (US 9,021,117) in view of Lewis (US 20130061242), in view of Herrera et al. (US 20090037706 A1)
As per claim 16 Pellowski and Lewis disclose the method of the claim 15 detailed above.
Pellowski and Lewis does not explicitly disclose
“wherein the identity of the processor comprises a service tag or serial number.”
However, Herrera disclose “wherein the identity of the processor comprises a service tag or serial number.” [0027] “The control code is preferably related to the identity of processor 102 and/or to the identity of system 100 so as to provide an extra security…. Preferably, the control code is checked in combination with a unique identifier (ID) of the processor, such as the processor's unique serial number stored in register 116”
Pellowski, Lewis, and Herrera are in similar fields of endeavor because they all relate to data handling and communication function and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Pellowski, with the teachings of Lewis, and with the teachings of Herrera wherein the identity of the processor comprises a service tag or serial number.
Motivation to combine would be improve the system security to properly identifying the processor based on its serial number, which would also assist in tracking if a problem has occurred or managing task that is currently being processed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Teshome; Abeye US 20160378604 A1 disclose an operational status of the processor or BIOS, perform one or more diagnostic operations upon the IHS, and communicate a result of the one or more diagnostic operations to a remote server using the network stack.
Terrill; John Ondy US 20160323318 A1 disclose a computer network security system includes a central controller in communication with software-based endpoint agents operating on individual host computers.
Ragupathi; Dinesh US 20170046242 A1 disclose an information handling system may include a plurality of information handling resources and a controller communicatively coupled to the plurality of information handling resources.
Harwood; John S (US 20230214263 A1) disclose identifying a composed infrastructure associated with the composed system blueprint capable of performing the workflow based on telemetry data and the first predictive analytics;
SHINTANI TAKESHI (JP 2021071929 A) disclose a technique for reducing the possibility of interference occurring with operation of an API call handling system itself when use of an API is limited.
DU, Chao (CN 116501367 A) disclose obtaining the data source related parameter and the first request parameter needed by the configuration application program interface API, wherein the first request parameter comprises a first request path.
Iyer; Vivek Viswanathan (US 11868815 B2) disclose managing compute resources and runtime object load status in a platform framework.
Mehta; Kunal (US 10339303 B2) disclose a binder kernel driver can be configured to receive an application program interface (API) call.
Dinh; Hung The (US 20180324118 A1) disclose a first request from an application to connect to a messaging queue manager provided by a messaging queue service on a messaging queue service device, and in response, connects the application to the messaging queue manager by executing a connect API command.
Shah; Rajesh R. (US 7039922 B1) disclose an operating system includes a kernel and a fabric bus driver to provide an I/O bus abstraction to the kernel for the cluster fabric to report multiple paths to a target fabric-attached I/O controller.
Whitfield; Michael (US 20100088703 A1) disclose a first processor can include a number of hardware drivers for receiving the transactions from the system dispatcher and providing the transactions to the slave processing cores for execution.
CHAN; Benjamin Koon Pan (US 20200192679 A1) disclose a hybrid co-processing system including both complex instruction set computer (CISC) architecture-based processing clusters and reduced instruction set computer (RISC) architecture-based processing clusters.
Cardinell; Charles S (US 20170091135 A1) disclose an embedded port of a host bus adapter of a storage controller receives, from a driver of the host bus adapter, a first set of commands to quiesce I/O operations in the embedded port.
Kiran Kumar Modukuri (US 11132326 B1) disclose a techniques to route data transfers between hardware devices
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHMEED ACHILLE whose telephone number is (571)272-9437. The examiner can normally be reached Monday-Friday 7am -4pm.
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.
/A.A./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights