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 .
DETAILED ACTION
Claims 1-20 are pending. Claims 1, 8, and 15 are independent.
This Application was published as U.S. 20260023930.
Apparent priority: 20 July 2024.
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-2 and 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Allen (U.S. 9,015730) in view of Zhou (U.S.20240362093).
Regarding Claim 1, Allen teaches the entire Claim except for the vectorization feature:
1. An information handling system operating an On the Box (OTB) Artificial Intelligence (AI) productivity tool comprising: [Allen mentions that the matching of query to API capabilities of step 204 of Figure 2 may be conducted by AI. See 10:63 and vicinity. Considering that the OTB is not defined by the Claim (or for that matter the Specification) the system of Allen which acts as an intermediary between a Client Device and functionalities offered by various endpoint web services and teaches the OTB AI productivity tool and AI productivity tool enableable software application of the Claim. “Many such computing platforms, but not all, allow for the addition of or installation of application programs (401) which provide specific logical functionality and which allow the computing platform to be specialized in certain manners to perform certain jobs, thus rendering the computing platform into a specialized machine.” 15: 9-15.]
a hardware processor to receive an update for an Al productivity tool enableable software application with an updated capability having a natural language description; [Allen, Figure 4 shows the hardware including: “The "hardware" portion of a computing platform typically includes one or more processors (404) accompanied by, sometimes, specialized co-processors or accelerators, such as graphics accelerators, and by suitable computer readable memory devices (RAM, ROM, disk drives, removable memory cards, etc.).” 15:17-22. The “updated capability having a NL description” is taught by Figure 2 and input of the API Reference Documents etc. for ingestion and update of API. The premise of Allen is that because APIs need updating all the time, its method is superior: “…The known API details can be initialized and updated by ingesting the description documents for the structured APIs,….” Abstract. “As the API are constantly updated, revised, and created, programmers face a considerable challenge to remain aware of the most recent versions of each API.” 2:31-34. “…Even after learning these sequences, the user may be frustrated by the smallest of changes or updates to the user interfaces….” 2:40-43. As for the solution: “The known API elements can be initialized and updated by ingesting the description documents ….” 2:64-65.]
the hardware processor to execute machine readable code instructions to generate a vectorized capability intent value from the natural language description of the updated capability; [Allen (and a lot of other references) teach that the capabilities and functionalities of an API can be specified using natural language specification or description. “… The known API details can be initialized and updated by ingesting the description documents for the structured APIs, and then using natural language processing to extract components from the descriptions, which can then be utilized in the matching process to further enhance the results of the tool.” Abstract. ]
the hardware processor to execute machine readable code instructions of an Al productivity tool enableable software application to dynamically register with the OTB Al productivity tool the vectorized capability intent value of the natural language description for the updated capability of the Al productivity tool enableable software application; [Allen, Figure 2, the input of “API reference documents (text, XML, images, PDF, Word, etc.) for each endpoint #1 through #N” to “Ingest API documents for each of N endpoint services for which NLQ/API resolution is to be performed. 201.” The reference documents include the capabilities of the applications/services/servers/endpoints 1 … N that are represented by the API and any updates to those applications. “… As the API are constantly updated, revised, and created, programmers face a considerable challenge to remain aware of the most recent versions of each API.” 2:30-34. “The known API elements can be initialized and updated by ingesting the description documents for the structured APIs, and then using natural language processing (NLP) to extract optional and required API elements from the descriptions, which can then be utilized in the matching process to further enhance the results of the system.” 2:64-3:3.]
the hardware processor to execute machine readable code instructions of the OTB Al productivity tool to receive, via a universal user conversational interface software application, a user query input requesting performance of an action; [Allen, Figure 1, 101, 102, 103, 104. “user composes natural language, unstructured request describing the desired resource and criteria 102.” “The present inventors sought to define a new method and process that would allow use of natural language queries (NLQs) as a highly unstructured interface to access highly structured APIs. In order to "understand" a user's intent expressed in a natural language query (NLQ), Natural Language analysis (or processing or parsing) (NLP) can be employed.” 5:20-26. “Turning now to FIG. 1, such a process is illustrated: Step 101. A client device user wants to access a resource (e.g. status updates, new messages, latest news feed entries, etc.) at an endpoint service. Step 102. The client device user (or a process running on the client device) composes an unstructured query in natural language describing desired resource. The client device user may construct query however he, she (or it in the case of a program being the client user) desires, without regard to API standards, syntax or structure. Step 103. The client device sends the unstructured query to an Natural Language Query/API (NLQ/API) resolving service, such as sending to a central URL at the remote endpoint, for example: a. using a standard HTTP POST operation; b. in which the payload may simply be string with unstructured query; and c. optionally may also send the query in parameter, headers, or other HTTP operations. d. Alternatively, the client device may send the NL query to a non-descript destination, and the server at the destination may detect that it is an unstructured request (e.g. not compliant as an API call), and divert the NLQ to an embodiment of the NLQ/API invention. Step 104. The NLQ/API resolving service, or the endpoint service provider as the case may be, receives unstructured query from client. ….” 6: 44-67.]
the hardware processor to execute machine readable code instructions of the OTB Al productivity tool to determine that the vectorized query input intent value for the user query input correlates to the vectorized capability intent value determined for the registered natural language description of the updated capability, indicating that the user query input requests performance of the natural language capability; and [Allen, Figure 1, 104, 105, 16: the user query is analyzed and decomposed and matched to the capabilities of the endpoint services. Figure 2, 204: “Use NLP to correlate NL components of the request to the NL components of the API descriptions from the documents.” “Step 104. The NLQ/API resolving service, or the endpoint service provider as the case may be, receives unstructured query from client. Step 105. The NLQ/API service decomposes client's unstructured query into semantic NL components using natural processing, such as those functions available by an IBM Watson system or a similar system. Step 106. Based on semantic relationships, parts of speech, keywords, etc, NL components are identified in the NLQ, and the NLQ/API service maps the query and its components to one of its structured APIs and its elements. a. The NLQ/API service may map the query to another endpoint service, enabling both unstructured and traditional APIs to be used in conjunction. b. For example, natural language query "give me my activities over the last day" may be decomposed to NL components "my activities" and "last day", and then mapped to structured API "/connections/activities?timeframe=today", where "/connections" is the endpoint selected, "activities" is an API element, and "timeframe=today" is an API element. c. The mapping operations may be performed automatically, as disclosed in more details in the following paragraphs, which includes in at least one embodiment building a library of known structured APIs by optionally ingesting API documentation….” 7: 1-29. “Step 204. After the NLQ/API system has received a natural language unstructured request for use of an endpoint from a requesting client, in which the client's request contains natural language description of resource being requested (e.g., "Give me my latest activities from today"), the NLQ/API system utilizes a method such as that shown in FIG. 1a or FIG. 1b to map the NL components in the request to natural language description(s) (200') from the API documentation to identify a matching REST operation. a. Both the NL request and the NL documentation may be decomposed and annotated with semantic relationships, concepts, keywords, etc. b. These annotations in the unstructured request and the -API documentation may then be compared to find a high-confidence match between the requested functionality and the available, known structured APIs. c. Deep semantic NLP systems, such as IBM Watson.TM., are capable of making these NL-based matches, e.g., matching two sets of natural language expressions based on a series of annotators, scorers, AI, etc.” 10:42-62.]
the hardware processor to execute machine readable code instructions for the OTB Al productivity tool to instruct the Al productivity tool enableable software application to perform the registered capability. [Allen, Figure 1, the end of the flow may be step 108 when the appropriate API is returned to the client or “Receive corresponding structured API with arguments to be used to invoke the service.” Figure 2 after 207 shows Results of API completion coming back to the Requesting Client from the Endpoint services. “… including required an optional elements (parameters, arguments, etc.) populated with values corresponding to the extracted attributes that comply with the API's documentation. Step 207. The NLQ/API system optionally submits the constructed API call on behalf of the requesting client to the identified endpoint, or it may return the constructed API (with populated element values) to the requesting client. a. If the constructed API call is submitted to the identified endpoint on behalf of the client, the NLQ/API system the receives the service's results from the execution of the API call, and it then forwards those results to the client. b. If the constructed API call (with populated element values) is returned to the requesting client, then the client can submit it to the identified endpoint and receive the results directly from the invoked service, or the client may store the constructed API call for later use.” 11:25-44.]
Allen is an early (filed 2013) reference and while teaching natural language processing does not teach vectorizing the texts of the query and the capabilities documentation as a precursor to the comparison/mapping of the two. Vector distance is a commonly used method of determining similarity which is not taught by Allen.
Zhou teaches finding a response for an input query by vectorizing the input query (Context Vector in Zhou) and the documents that are to be searched (Corpus of documents.) Zhou generates embeddings/vectors of input queries and the documents that are to be searched by the queries and here the “context vector” is the vector obtained from the input query. “[0073] At block 452, the system receives an API query comprising a context vector representing a user query. The API query may originate from an LLM, as described herein (e.g., in relation to FIGS. 2 and 3). In some implementations, the API query may be received over a network from a remote NL based response system. In additional or alternative implementations, the API query may be received from a local NL based response system, e.g. an NL based response system operating on the same device/computing system as the external application.” “[0075] At block 454, the system compares the context vector to a set of precomputed embeddings, each embedding representing a respective document in the custom corpus of documents. Each precomputed embedding, or each precomputed embedding in a subset of the embeddings, is compared with the context vector.” “[0077] The precomputed embeddings may be determined continuously, e.g. whenever a new document is added to the custom corpus or an existing document updated, a corresponding embedding is determined. Additionally, or alternatively, the custom corpus may be checked periodically to determine if any new documents have been added or any existing documents have been updated, and corresponding embeddings determined if so.” “[0078] In some implementations, comparing the context vector to a precomputed embeddings comprises determining a distance in the embedding space between the context vector and the precomputed embedding, as shown in block 454A. A metric may be used to determine the distances between the precomputed document embedding and the context vector. For example, an L1 or L2 distance, correlation, or cosine similarity in embedding space between the precomputed embedding and the context vector may be determined by the external application.”
Allen and Zhou pertain to matching a query to a set of documents and it would have been obvious to replace the NL process of Allen which is older with the vectorizing and obtaining similarity by way of obtaining a distance between the respective vectors from Zhou as a more modern method. This combination falls under simple substitution of one known element for another to obtain predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Regarding Claim 2, Allen teaches:
2. The information handling system of claim 1 further comprising:
the hardware processor to execute code instructions of the AI productivity tool enableable software application to execute an application programming interface (API) call for performing the natural language capability requested within the user query input, [Allen is titled: “Natural Language Access to Application Programming Interfaces.” The endpoint services are accessed by API calls. “The NL components are then used to find one or more matches of known APIs, and then at least one structured API call is constructed by mapping the request's NL components to the structured API call's elements (e.g., arguments, parameters, etc.). The system can then invoke the online service on behalf of the client, and return the results to the client, or it can return the constructed structured API call to the client.” 2:55-65. “FIG. 1 illustrates a logical process according to the invention for resolving an unstructured natural language user request into a structured API call.” 3:11-14.]
wherein the API call causes an adjustment in operation of a hardware component of the information handling system. [Allen, Figure 1, 108 or Figure 2, 207 and afterwards: the query is executed and response has to be presented to the user which may use the display or the loudspeaker hardware components of the client device. “Step 204. After the NLQ/API system has received a natural language unstructured request for use of an endpoint from a requesting client, in which the client's request contains natural language description of resource being requested (e.g., "Give me my latest activities from today"),” 10:42-47.]
Regarding Claim 6, Allen teaches:
6. The information handling system of claim 1 further comprising:
the hardware processor to execute code instructions of the AI productivity tool enableable software application to execute an application programming interface (API) call for performing the updated capability requested within the user query input, [Allen, “... The system then receives unstructured requests from clients. The system maps client's unstructured requests to natural language descriptions of API operations in the API's documentation. The system then optionally constructs and executes an appropriate structured API call, such as an HTTP request with corresponding elements, which complies with the API's documentation requirements on behalf of the client, or it returns the constructed structured API to the requesting client for its own use or storage. In the former arrangement, results from executing the request on behalf of the requesting client are returned to the client. For example, turning to FIG. 2: Step 201. The NLQ/API system ingests service provider's REST API documentation. Step 202. The NLQ/API system correlates the natural language description from the documentation of the service provider's REST API operations with the API elements (URL endpoints, headers, parameters, payload formats, etc.).” 10:14-36. ]
wherein the API call causes an adjustment in operation of a hardware component of the information handling system. [Allen, Figure 1, 108 or Figure 2, 207 and afterwards: the query is executed and response has to be presented to the user which may use the display or the loudspeaker hardware components of the client device. “Step 204. After the NLQ/API system has received a natural language unstructured request for use of an endpoint from a requesting client, in which the client's request contains natural language description of resource being requested (e.g., "Give me my latest activities from today"),” 10:42-47.]
Regarding Claim 7, Allen uses NLP but not vectorized embeddings of text which is a newer technology.
Zhou teaches:
7. The information handling system of claim 1 further comprising:
the hardware processor to execute machine readable code instructions of the OTB AI productivity tool to determine the vectorized query input intent value for the user query input and the vectorized capability intent value determined for the natural language description of the updated capability using a natural language processing (NLP) text embedding algorithm. [Zhou generates embeddings/vectors of input queries and the documents that are to be searched by the queries and here the “context vector” is the vector obtained from the input query. “[0073] At block 452, the system receives an API query comprising a context vector representing a user query. The API query may originate from an LLM, as described herein (e.g., in relation to FIGS. 2 and 3). In some implementations, the API query may be received over a network from a remote NL based response system. In additional or alternative implementations, the API query may be received from a local NL based response system, e.g. an NL based response system operating on the same device/computing system as the external application.” “[0075] At block 454, the system compares the context vector to a set of precomputed embeddings, each embedding representing a respective document in the custom corpus of documents. Each precomputed embedding, or each precomputed embedding in a subset of the embeddings, is compared with the context vector.” “[0077] The precomputed embeddings may be determined continuously, e.g. whenever a new document is added to the custom corpus or an existing document updated, a corresponding embedding is determined. Additionally, or alternatively, the custom corpus may be checked periodically to determine if any new documents have been added or any existing documents have been updated, and corresponding embeddings determined if so.” “[0078] In some implementations, comparing the context vector to a precomputed embeddings comprises determining a distance in the embedding space between the context vector and the precomputed embedding, as shown in block 454A. A metric may be used to determine the distances between the precomputed document embedding and the context vector. For example, an L1 or L2 distance, correlation, or cosine similarity in embedding space between the precomputed embedding and the context vector may be determined by the external application.”]
Rationale as provided for Claim 1. The generation of vectors is by process of embedding and embeddings and vectors are used interchangeably.
Claims 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou in view of Pollock (US 20190034199).
Claims 3-5 have a similar structure and vary only in the particular modification that has been done to the API: delete/remove/disable or add and they vary in whether the update is to the software or the hardware/firmware. Allen maps the documentations of the endpoint services to the user query and as long as the components recited in the Claims are associated with a documentation in natural language of the API that is supposed to access them, Allen applies. The APIs in Allen can access various endpoints including their hardware or software. Zhou can access External Applications 160. The added Pollock covers API of any software or application including those associated with operating the hardware. Pollock is completely agnostic to the endpoint that is being handled by the API: “[0001] Application programming interfaces (APIs) facilitate usage of underlying computing tools by defining input to the computing tool such that the tool may be used without revealing implementation details of the tool. Sometimes documentation, which is a description of how an API functions, is provided with the API to facilitate use of the API.”
Regarding Claim 3, Allen teaches:
3. The information handling system of claim 1,
wherein the natural language description of the updated capability omits a previous feature that has been removed or disabled in a most recent update to the AI productivity tool enableable software application. [Allen is directed to accommodating the updates to the various endpoint services as supported at length above in the mapping of Claim 1. One type of update is removing certain features. “These resources may be retrieved, created, updated, or deleted via standard HTTP GET, POST, PUT, or DELETE operations respectively.” 3:65-67. “These REST API calls will get all activities, get a specific activity by identification (ID), create a new activity, update an activity, and delete an activity, respectively.” 7:61-64.]
Updating of the documentation every time the API is update is not automatic and Allen and Zhou do not mention it.
Pollock teaches:
wherein the natural language description of the updated capability omits a previous feature that has been removed or disabled in a most recent update to the AI productivity tool enableable software application. [Pollock teaches a natural language documentation of an API which is updated as the API is updated: Figures 1A and 1B show an “analyzer 120” which generates the “API documentation 104”and Figure 3 that shows with every new and undocumented interaction detected at 304 a new API documentation is generated at 306. Figure 5, “update the received documentation 510.” “[0058] … The reviewer may annotate or edit (e.g., add or remove) portions of the generated API documentation.” “[0065] … In one aspect, the process of FIG. 5 is compatible with existing documentation processes and may augment existing processing by making additive or corrective edits to existing documentation…..” See also Figure 6 that outputs an alert when change is detected. “[0025] The analyzer 120 is configured to generate and/or update API documentation. …The API documentation may facilitate use of the API.” “[0026] In various embodiments, the analyzer 120 is configured to generate and/or update API documentation according to the processes described herein. For example, an API interaction may be observed and automatically documented according to the process of FIG. 2. API documentation may be updated to cover previously undocumented API interactions according to the process of FIG. 3. API documentation may be automatically generated and updated based on feedback according to the process of FIG. 4. Automatically generated API documentation may be used to audit the quality of existing manual API documentation according to the process of FIG. 5. Changes to API documentation may be identified and alerts issued based on the changes according to the process of FIG. 6.” “[0047] At 206, API documentation is generated based on the interaction parameter(s). The API documentation includes documentation of an action associated with an API interaction such as a description of how an API interaction can be used and/or how an API functions. … The description may be generated based on various techniques such as natural language processing, looking up the definition of the method definition in a library, and the like.”]
Allen/Zhou and Pollock pertain to the use of API’s and their natural language documentation and it would have been obvious to modify the system of combination with the specifics of the added reference to include an update feature for the natural language documentation every time the API is updated considering that both Allen and Zhou utilize the natural language description of the API. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Regarding Claim 4, Allen teaches:
4. The information handling system of claim 1,
wherein the natural language description of the updated capability includes a new functionality for a hardware component of the information handling system that has been added in a most recent update to firmware for the hardware component. [Allen is directed to accommodating the updates to the various endpoint services as supported at length above in the mapping of Claim 1. One type of update is adding new features and functionalities to a particular endpoint service. “These resources may be retrieved, created, updated, or deleted via standard HTTP GET, POST, PUT, or DELETE operations respectively.” 3:65-67. “These REST API calls will get all activities, get a specific activity by identification (ID), create a new activity, update an activity, and delete an activity, respectively.” 7:61-64.]
Allen and Zhou do not discuss the update of the natural language documentation but Pollock as applied to Claim3 and under the same rationale does.
Pollock teaches the generation of the updated documentation for any application that is being used by the client device:
wherein the natural language description of the updated capability includes a new functionality for a hardware component of the information handling system that has been added in a most recent update to firmware for the hardware component. [Pollock, Figure 1A, the user 102 is contacting a “backend API 140” for performance of a function by the application that is associated with the API. Figure 1B shows that as the API is updated, the “analyzer 120” detects the changes and updates the “API documentation 104.” Figure 5, the system has the initial documentations at 502 but as the application and its API change/update the documentation is also updated at 510 and conveyed back to the user /registered. Figure 6 when the Documentation is Updated, the Administrator is notified. “[0020] FIG. 1A is a block diagram illustrating an embodiment of a system for generating API documentation. The system 100 includes an API gateway 110 and an analyzer 120.” “[0021] … The API gateway may parse an API request to determine requested operations and data to be obtained from backend API 140.” “[0025] The analyzer 120 is configured to generate and/or update API documentation….” “[0026] … API documentation may be updated to cover previously undocumented API interactions according to the process of FIG. 3. …” “[0027] The backend API 140 is a backend interface that interfaces with the API gateway. For example, the backend API 140 may be in the control of another user such as a customer. The backend API is configured to service API requests received via API gateway 110 by forwarding the requests to backend computing modules. For example, the backend API may invoke portions of a backend system (not shown) to carry out operations to service the API request. In some embodiments, the backend API may parse the API request and determine relevant resources to obtain and return based on the API request. The backend API may be deployed in a cloud or on-site at a customer's location.” “[0071] If a change is observed at 606, the process proceeds to 608, in which an alert is output. … In various embodiments, if a change is observed, the API documentation is updated accordingly. …That is, the process includes identifying changes to API documentation and provide an alert if there is a change. For example, when a new release of an API has occurred, an alert may be generated. As another example, if the addition of new parameters is detected, an alert may be generated. … An alert enables an administrator to communicate directly with a developer. In some instances, this allows an error to be detected earlier compared with conventional systems.”
PNG
media_image1.png
542
594
media_image1.png
Greyscale
PNG
media_image2.png
620
444
media_image2.png
Greyscale
PNG
media_image3.png
634
882
media_image3.png
Greyscale
Allen/Zhou and Pollock pertain to the use of API’s and their natural language documentation and it would have been obvious to modify the system of combination with the specifics of the added reference to include an update feature for the natural language documentation every time the API is updated considering that both Allen and Zhou utilize the natural language description of the API. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396. (For the benefits of updating the natural language documentation see Pollock: “[0001] Application programming interfaces (APIs) facilitate usage of underlying computing tools by defining input to the computing tool such that the tool may be used without revealing implementation details of the tool. Sometimes documentation, which is a description of how an API functions, is provided with the API to facilitate use of the API. Whether documentation is provided for an API or the quality of the documentation provided for an API can affect its usage and popularity with users. Conventional techniques of API documentation are costly, insufficiently descriptive, or incompatible with legacy APIs, thus discouraging use of associated APIs.” “[0015] … Code-generated documentation refers to documentation that is derived automatically from API code. For example, the API code may be annotated with developer-focused information for an internal audience. Although this type of documentation may be performed automatically,…” “[0018] There are numerous benefits to well-documented APIs. For example, a good documentation for API is intelligible, succinct, descriptive, and both human-readable (meaningful to developers and lay-people) and machine-readable. …” “[0019] Automatic generation of API documentation via implementation-neutral analysis of API traffic is disclosed….”)
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou in view of Pollock and Nersisyan (U.S. 20250199892).
Regarding Claim 5, Allen teaches:
5. The information handling system of claim 1,
wherein the natural language description of the updated capability omits a previous functionality for a hardware component of the information handling system that has been removed or disable in a most recent update to firmware for the hardware component. [Allen, Figure 2 shows that the API reference documents are digested to created ta definition for the service that is connected to the API and when a function is removed, it is natural that the reference document of the endpoint would remove a reference to it. “In such an embodiment according to this aspect of the present invention, the NLQ/API resolving system "learns" the service provider's API documentation, such that each API endpoint is documented in natural language and has a defined set of required and optional API elements, such as an HTTP signature. … For example, turning to FIG. 2: Step 201. The NLQ/API system ingests service provider's REST API documentation. Step 202. The NLQ/API system correlates the natural language description from the documentation of the service provider's REST API operations with the API elements (URL endpoints, headers, parameters, payload formats, etc.).” 10:14-36.]
Allen and Zhou do not discuss the update of the natural language documentation but Pollock as applied to Claim 3 and under the same rationale does.
Allen and Zhou both teach the use of the natural language documentation of APIs of different software. Pollock teaches the update of natural language documentation of APIs that can be used with different applications including those that run hardware. A more express reference is provided that mentions firmware.
Nersisyan teaches:
wherein the natural language description of the updated capability omits a previous functionality for a hardware component of the information handling system that has been removed or disable in a most recent update to firmware for the hardware component. [ [Nersisyan teaches the API documentation and teaches that firmware may be updated: “[0014] Developers of applications that consume cloud services may rely on the documentation of example reusable API cloud service calls (or “API calls”). A factor that affects the availability of such documentation for a particular API call is the number of ways that an API call signature can potentially vary to accommodate different use cases. …” “[0025] … In an example, for a cloud service instance that is associated with a network management system (NMS) service, an API request may be related to an operation to configure a network device with parameters corresponding to a particular network telemetry reporting subscription. In another example, an API request to an NMS cloud service instance may be related to an operation to update firmware of a network device….”]
Allen/Zhou/Pollock and Nersisyan pertain to hardware/software/firmware that either are or are operated by applications that are in turn operated by APIs and it would have been obvious to complement the system of combination with the details pertaining to the update of firmware from Nersisyan to address the specific case of this Claim.
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou further in view of Christensen (U.S. 20090327994).
Regarding Claim 8, Allen and Zhou as applied to Claim teach this independent Claim except for the limitation of “registering …an update for an AI productivity tool”:
8. An application programming interface (API)-agnostic method of instructing execution of updated capabilities by an artificial intelligence (AI) productivity tool enableable software application from a user query input at an information handling system comprising:
registering with the OTB AI productivity tool, via a hardware processor executing machine readable code instructions of an AI productivity tool enableable software application, an update for an AI productivity tool enableable software application with an updated capability having a natural language description;
generating, via the hardware processor executing machine readable code instructions of the OTB AI productivity tool, a vectorized capability intent value from the natural language description of the updated capability of the AI productivity tool enableable software application; [Limitation similar to Claim 1 and mapped similarly. This is the ingestion of the documentation of the endpoint service shown in Figure 2 of Allen where the “vectorization” of NL text is combined from Zhou because Allen conducted its NLP without vectorizing as shown in Figure 1 a t 105.]
receiving at the OTB AI productivity tool, via a hardware processor executing machine readable code instructions of a universal user conversational interface software application, a user query input requesting performance of an action; [Limitation similar to Claim 1 and mapped similarly. This is the input of user query that is shown in Figure 1 of Allen.]
determining, via the hardware processor executing machine readable code instructions of the OTB AI productivity tool, that a vectorized query input intent value for the user query input correlates to the vectorized capability intent value determined for the registered natural language description of the updated capability indicating that the user query input is requesting performance of the updated capability; and [Limitation similar to Claim 1 and mapped similarly. This is the comparison of user query against the documentation of capabilities of the endpoint service that is shown in the mapping at 106 of Figure 1 of Allen where the “vectorization” of NL text is combined from Zhou because Allen conducted its NLP without vectorizing.]
instructing, via the hardware processor executing machine readable code instructions of the OTB AI productivity tool, the AI productivity tool enableable software application to perform the updated capability. [Limitation similar to Claim 1 and mapped similarly. This is the performance of the user requested function shown at the end of Figures 1 and 2 of Allen.]
Allen and Zhou do not teach the step of registering of the updates of the endpoint software with the client device.
Christensen teaches:
registering with the OTB AI productivity tool, via a hardware processor executing machine readable code instructions of an AI productivity tool enableable software application, an update for an AI productivity tool enableable software application with an updated capability having a natural language description; [Christensen synchronizes/registers the updates between developers and users. “The described method and system synchronizes source code with byproducts or artifacts of an application creation process. … The described method and system may be integrated into a development platform that is adapted to direct the user to perform particular revisions or updates to bring the source code in line with the artifacts.” Abstract.]
Allen/Zhou and Christensen pertain to the use of API’s and their natural language documentation and it would have been obvious to modify the system of combination with the specifics of the added reference to include the registration of an update feature for the natural language documentation every time the API is updated considering that both Allen and Zhou utilize the natural language description of the API. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Claim 15 is a system Claim with limitations similar to the limitations of method Claim 8 and is rejected under similar rationale.
15. An information handling system operating an On the Box (OTB) Artificial Intelligence (AI) productivity tool comprising:
a hardware processor to execute machine readable code instructions of an AI productivity tool enableable software application to determine an update to the AI productivity tool enableable software application has adjusted at least one capability of the AI productivity tool enableable software application;
a hardware processor to execute machine readable code instructions of an AI productivity tool enableable software application to automatically register with the OTB AI productivity tool an update for an AI productivity tool enableable software application with an updated capability with a natural language description for the updated capability;
the hardware processor to execute machine readable code instructions of the OTB AI productivity tool to generate a vectorized capability intent value from the natural language description of the updated capability of the AI productivity tool enableable software application;
the hardware processor to execute machine readable code instructions of the OTB AI productivity tool to receive, via a universal user conversational interface software application, a user query input requesting performance of an action;
the hardware processor to execute machine readable code instructions of the OTB AI productivity tool to determine that a vectorized query input intent value for the user query input correlates to the vectorized capability intent value determined for the registered natural language description of the updated capability indicating that the user query input is requesting performance of the updated capability; and
the hardware processor to execute machine readable code instructions for the OTB AI productivity tool to instruct the AI productivity tool enableable software application to execute the updated capability.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou and Christensen further in view of Lindrup (US 20250069613).
Regarding Claim 9, Allen makes its comparison/mapping through older NLP methods and does not vectorize the text.
Zhou teaches:
9. The method of claim 8,
wherein the vectorized capability intent value is a vectorized mathematical representation in a multi-axis vector space of the natural language description of the updated capability describing operations or services from the updated AI productivity tool enableable software application, [Zhou, the capability is reflected in the set of documents that provide a documentation for the API. “[0037] The document embeddings 170 are latent representations of the documents (e.g., vectors in an embedding space or lower-dimensional latent space) that each represent a respective document or set of documents in the custom corpus. …” See [0048]-[0049] and [0055] for the rest of the process. See for the updating of the documentation: “[0077] The precomputed embeddings may be determined continuously, e.g. whenever a new document is added to the custom corpus or an existing document updated, a corresponding embedding is determined. Additionally, or alternatively, the custom corpus may be checked periodically to determine if any new documents have been added or any existing documents have been updated, and corresponding embeddings determined if so.” See Figure 4, 454 for comparison of query to the documentation. The “context vector” is the vector generated from the user query: “[0075] At block 454, the system compares the context vector to a set of precomputed embeddings, each embedding representing a respective document in the custom corpus of documents. Each precomputed embedding, or each precomputed embedding in a subset of the embeddings, is compared with the context vector.”]
where the vectorized capability intent value is generated via execution of machine readable code instructions by the hardware processor of a text embedding algorithm. [Zhou, “[0037] … The embeddings may be generated from an intermediate output of an LLM, such as output of an intermediate layer of the LLM that has processed the document. Alternatively, a dedicated encoder model, such as an encoder of a variational autoencoder (VAE) model may be used to generate the document embeddings 170.” The documents that are input and vectorized are Text: “[0055] The data representative of one or more documents may comprise a copy of one or more of the documents identified by the external application, e.g., the full text of the document. Additionally, or alternatively, the data representative of one or more documents may comprise a textual summary of one or more of the documents identified by the external application, e.g., an abstract of the document….”]
Rationale for combination as provided for Claim 1.
The vectorized embeddings for text are multi-axis but Zhou does not teach that expressly.
Lindrup teaches:
wherein the vectorized capability intent value is a vectorized mathematical representation in a multi-axis vector space of the natural language description of the updated capability describing operations or services from the updated AI productivity tool enableable software application, [Lindrup, “[0061] According to a more specific embodiment a numerical representation is assigned to at least some of the words comprised in the first sound signal and said plurality of provided sound source signals. This is done using a word embedding function that provides embedded words by assigning a vector of a relatively high dimensionality, say in the range of 50 to 400 to at least some of the words comprised in the considered signals. …”]
Allen/Zhou/Christensen and Lindrup pertain to vectorized textual comparisons and it would have been obvious to combine Lindrup which provides more detail regarding this well-known process with the system of combination for completeness and to demonstrate that the process of Zhou may be conducted according to details taught by Lindrup.
Regarding Claim 10, Allen makes its comparison/mapping through older NLP methods and does not vectorize the text. Zhou teaches the vectorization of the query and the updated documentation of the APIs but does not discuss the specifics of vectorization of text which is outside the main subject of this reference.
Lindrup teaches:
10. The method of claim 8,
wherein the vectorized capability intent value is a vectorized mathematical representation in a multi-axis vector space of the natural language description of the updated capability with a first axis of the multi-axis vector space measuring likelihood that a plurality of words within the natural language description of the updated capability form a known phrase. [Lindrup is directed to speech recognition which also relies on the probability of certain words following one another in order to make a determination of what words were said. The multi-axis vector space or multi-dimensional vector space is a feature of neural networks and the LLM that convert text into the vector space. “[0061] According to a more specific embodiment a numerical representation is assigned to at least some of the words comprised in the first sound signal and said plurality of provided sound source signals. This is done using a word embedding function that provides embedded words by assigning a vector of a relatively high dimensionality, say in the range of 50 to 400 to at least some of the words comprised in the considered signals. …” “[0062] However, the concept of word embedding is well known and software for training and using word embeddings are known and includes e.g. “Word2vec”, “GloVe” and “BERT” all of which are configured to map words into a meaningful space where the distance between the embedded words reflect the semantic similarity and all of which are available based on API's.” “[0069] According to another more specific embodiment for comparing said first sound signal with the provided plurality of sound source signals a Language Model (LM) capable of predicting the probability of “next words” given the previous words is applied.”]
Rationale for combination as provided for Claim 9. Lindrup merely explains details that Zhou does not bother to expand upon.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou and Christensen further in view of Wang (U.S. 20180253139).
Regarding Claim 11, Allen teaches:
11. The method of claim 8 further comprising:
the hardware processor to execute code instructions of the AI productivity tool enableable software application to execute an application programming interface (API) call for performing the updated capability requested within the user query input, [Allen is titled: “Natural Language Access to Application Programming Interfaces.” The endpoint services are accessed by API calls. “The NL components are then used to find one or more matches of known APIs, and then at least one structured API call is constructed by mapping the request's NL components to the structured API call's elements (e.g., arguments, parameters, etc.). The system can then invoke the online service on behalf of the client, and return the results to the client, or it can return the constructed structured API call to the client.” 2:55-65. “FIG. 1 illustrates a logical process according to the invention for resolving an unstructured natural language user request into a structured API call.” 3:11-14.]
wherein the API call causes an adjustment in operation of a hardware component of the information handling system.
Allen and Zhou do not discuss the details of how API calls operate which is outside the scope of these references which are focused on the main aspect of query vs. documentation of API and Christensen which was cited to show that software must register itself every time it gets updated.
Wang teaches:
wherein the API call causes an adjustment in operation of a hardware component of the information handling system. [ Wang: “[0044] In use, the one or more applications of the application layer 210 initiate one or more API calls and direct the same to the API(s) of the API layer 208, in response to various application-level activity. See operation 1. Thereafter, in operation 2, such call is translated by the API(s) of the API layer 208 into an inter process communication (IPC). In operation 3, such IPC is sent to one or more system-level applications or an OS of the OS layer 206 for determining an appropriate action configured to reduce energy consumption of the hardware of the hardware layer 202. Further, in operation 4, this is supported and accomplished by the driver(s) of the driver layer 204 being used to configure hardware settings by, for example, adjusting the corresponding hardware-level settings.” “[0045] To this end, through the execution of the foregoing setting adjustments, the hardware of the hardware layer 202 operates with the adjusted settings in operation 5 ….” See Figures 2-3.]
Allen/Zhou/Christensen and Wang pertain to applications that are operated by API calls and it would have been obvious to complement the system of combination with the details pertaining to the use of API calls from Wang which are probably almost universally applicable to all applications and hardware in order to fill in the blanks left out by the references of the combination which focus on a different aspect and area particular to their particular subject.
PNG
media_image4.png
420
444
media_image4.png
Greyscale
PNG
media_image5.png
362
456
media_image5.png
Greyscale
Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou and Christensen further in view of Rothley (U.S. 20140173562) and Yan (U.S. 20240103838).
Regarding Claim 16, Allen and Zhou both teach the use of the natural language documentation of APIs of different software. Christensen was cited for the registering of an application.
Rothley teaches:
16. The information handling system of claim 15,
wherein the natural language description of the updated capability includes a new functionality for a hardware component of the information handling system that has been allowed in a most recent update to hardware component policies. [Rothley is directed to an “automatic documentation generator” and teaches: “[0022] …The automatic documentation generator disclosed herein resolves this problem by automatically generating and continuously updating a functions and features list of the various modules and entities in a software product in parallel with the software development process. ...”]
Allen/Zhou/Christensen and Rothley pertain to applications that are operated by APIs and it would have been obvious to complement the system of combination with the details pertaining to the use of documentation for software from Rothley to address the specific case of this Claim.
The fact that hardware like software is controlled by APIs is not taught by any of the above.
Yan teaches that the hardware function updates occur and are reflected in the associated API:
wherein the natural language description of the updated capability includes a new functionality for a hardware component of the information handling system that has been allowed in a most recent update to hardware component policies. [Yan: [0040] CMS 220 includes an application programming interface (API) to allow common access to different types of UE, in accordance with various embodiments. API calls support requests from user equipment to CMS 220 triggering checks for updates to containers; requests to download containers to run new applications; triggering updates by discovery service 228 in database 230 of added, deleted, or modified containers; or triggering storage of data from containers for future access, for example. Through API calls, various type of user equipment can interact with discovery service 228 using API 232 and cellular network 218 to manage installed software in the form of containers. API 232 is platform agnostic and results in communication and management of containers to run on an abstraction layer 210, regardless of the hardware configuration running abstraction layer 210. The same containers 212, 214, 216 may thus run on any compatible abstraction layer deployed on different types of UE.” “[0047] ... Containers 212, 214, 216 monitored and kept updated may be drivers and firmware for UE 141 that support UE interaction with hardware and basic functions such as communications on cellular network 218, for example. CMS 220 may monitor third-party apps or other software deployed to UE 141 in some embodiments.”]
Allen/Zhou/Christensen/Rothley and Yan pertain to applications that are operated by API calls and it would have been obvious to complement the system of combination with the details pertaining to the use of API calls from Yan which are used for software, firmware and hardware in order to fill in the blanks left out by the references of the combination which focus on a different aspect and area particular to their particular subject.
PNG
media_image6.png
480
852
media_image6.png
Greyscale
Regarding Claim 17, Allen and Zhou both teach the use of the natural language documentation of APIs of different software. Christensen was cited for the registering of an application.
Rothley teaches:
17. The information handling system of claim 15,
wherein the natural language description of the updated capability omits a previous functionality for a hardware component of the information handling system that has been disallowed in a most recent update to hardware component policies. [Rothley is directed to an “automatic documentation generator” and teaches: “[0022] …The automatic documentation generator disclosed herein resolves this problem by automatically generating and continuously updating a functions and features list of the various modules and entities in a software product in parallel with the software development process. ...”]
Rationale for combination as provided for Claim 16.
The fact that hardware like software is controlled by APIs is not taught by any of the above.
Yan teaches that the hardware function updates occur and are reflected in the associated API:
wherein the natural language description of the updated capability omits a previous functionality for a hardware component of the information handling system that has been disallowed in a most recent update to hardware component policies. [Yan, [0040], [0047] and Figure 2.]
Rationale as provided for claim 16.
Claims 12-13 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou and Christensen further in view of Rothley.
Regarding Claim 12, Allen and Zhou both teach the use of the natural language documentation of APIs of different software. Christensen was cited for the registering of an application. A more express reference is provided.
Rothley teaches the automatic update of documentation as software is changed:
12. The method of claim 8, wherein the natural language description of the updated capability includes a new feature that has been added in a most recent update to the AI productivity tool enableable software application. [Rothley is directed to an “automatic documentation generator” and teaches: “[0022] …The automatic documentation generator disclosed herein resolves this problem by automatically generating and continuously updating a functions and features list of the various modules and entities in a software product in parallel with the software development process. ...” “[0008] In some implementations, the operations may further comprise updating the list of object descriptions when a change event, a create event, or a delete event is detected. In some implementations, the change event may be triggered when the object is changed. In some implementations, the create event may be triggered when a new object is added to the repository. In some implementations, the delete event may be triggered when the object is deleted from the repository.” “4. The non-transitory computer-readable medium of claim 1, the operations further comprising: updating the list of object descriptions when a change event, a create event, or a delete event is detected.” See also [0038] and [0042].]
Allen/Zhou/Christensen and Rothley pertain to applications that are operated by APIs and it would have been obvious to complement the system of combination with the details pertaining to the use of documentation for software from Rothley to address the specific case of this Claim.
Regarding Claim 13, Allen and Zhou both teach the use of the natural language documentation of APIs of different software. A more express reference is provided.
Rothley teaches:
13. The method of claim 8, wherein the natural language description of the updated capability includes removes a feature and a capability with a most recent update to the AI productivity tool enableable software application. [Rothley, see mapping of Claim 18 which includes all types of update. “4. The non-transitory computer-readable medium of claim 1, the operations further comprising: updating the list of object descriptions when a change event, a create event, or a delete event is detected.” See also [0038] and [0042].]
Rationale for combination as provided for Claim 12.
Claim 18 is similar to Claim 12 and is rejected under similar rationale.
18. The information handling system of claim 15,
wherein the natural language description of the updated capability includes a new feature that has been added in a most recent update to the AI productivity tool enableable software application.
Claim 19 is similar to Claim 13 and is rejected under similar rationale.
19. The information handling system of claim 15,
wherein the natural language description of the updated capability omits a previous feature that has been removed or disabled in a most recent update to the AI productivity tool enableable software application.
Claims 14 and 20 is rejected under 35 U.S.C. 103 as being unpatentable over Allen and Zhou and Christensen further in view of Pollock and Nersisyan.
Regarding Claim 14, Allen and Zhou both teach the use of the natural language documentation of APIs of different software. Pollock teaches the update of natural language documentation of APIs that can be used with different applications including those that run hardware. A more express reference is provided that mentions firmware.
Nersisyan teaches:
14. The method of claim 8, wherein the natural language description of the updated capability includes an adjusted functionality for a hardware component of the information handling system that has been adjusted in a most recent update to firmware for the hardware component. [Nersisyan teaches the API documentation and teaches that firmware may be updated: “[0014] Developers of applications that consume cloud services may rely on the documentation of example reusable API cloud service calls (or “API calls”). A factor that affects the availability of such documentation for a particular API call is the number of ways that an API call signature can potentially vary to accommodate different use cases. …” “[0025] … In an example, for a cloud service instance that is associated with a network management system (NMS) service, an API request may be related to an operation to configure a network device with parameters corresponding to a particular network telemetry reporting subscription. In another example, an API request to an NMS cloud service instance may be related to an operation to update firmware of a network device….”]
Allen/Zhou/Christensen and Nersisyan pertain to hardware/software/firmware that either are or are operated by applications that are in turn operated by APIs and it would have been obvious to complement the system of combination with the details pertaining to the update of firmware from Nersisyan to address the specific case of this Claim.
Claim 20 is similar to Claim 14 and is rejected under similar rationale.
20. The information handling system of claim 15,
wherein the natural language description of the updated capability includes an adjusted functionality for a hardware component of the information handling system that has been adjusted in a most recent update to firmware for the hardware component.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Overmyer (US 20240394118) teaches that the API natural language documentation and also teaches that API updates may include deletion of some underused functions. “[0064] The method 200 includes detecting one or more changes and one or more updates in the one or more APIs by monitoring the one or more APIs. In an embodiment of the present disclosure, the one or more changes correspond to one or more new endpoints, one or more modified data formats, and one or more deprecated features. Further, the method 200 includes automatically updating the one or more integration scripts and the one or more data mappings based on the detected one or more changes and the detected one or more updates.” “[0063] Furthermore, the method 200 includes monitoring one or more API changes associated with the API. The data learning module performs a learning operation via the AI-based code generation model on an updated API documentation, one or more user feedbacks, and one or more integration issues and improves the AI-based code generation model based on a result of performing the learning operation. In an embodiment of the present disclosure, fine-tuning large language models (e.g., third-generation Generative Pre-trained Transformer (GPT-3), GPT-Neo, or Text-to-Text Transfer Transformer (T5)) are used based on new API documentation and user feedback to improve understanding and code generation capabilities.”
Gutierrez (U.S. 20240419706)
Gutierrez teaches the documentation/specification of a program can be in natural language and also teaches that when a server registers an endpoint, it synchronizes the updates to the endpoint. “[0282] According to some embodiments, SKQL may be used to allow developers or users to “program,” or define, logic in near-natural language. This natural language may be parsed into one or more search elements and compiled into a series of commands to run against databases and/or data sources. …” “[0274] According to some embodiments, Standard Knowledge Query Language (“SKQL”) may be an abstraction that standardizes the interaction with different types of databases by providing a single interface for operations that may be performed using various database query languages. …” “[0277] … SKQL could have its own programming language which may be compiled either as a developer programs or at build time to a more well supported target programming language …” “[[0478] In yet another embodiment, a similar procedure may also be performed for an Asynchronous API or an Event-Driven Architecture (EDA) via the AsyncAPI specification. Within an EDA, the Standard API server may act as a broker. As such, it may register or initialize an endpoint, websocket, or other connection mechanism to listen for events or messages from Producers when it starts up by reading the user's chosen AsyncAPI specifications. It then may implement an endpoint, websocket, or other connection mechanism for Subscribers to register their subscription per AsyncAPI defined channel. ….”
PNG
media_image7.png
476
902
media_image7.png
Greyscale
PNG
media_image8.png
230
546
media_image8.png
Greyscale
PNG
media_image9.png
758
504
media_image9.png
Greyscale
Nicolson (U.S. 20250245663)
” [0020] In an embodiment, model manager 116 uses a combination of natural language processing (NLP) algorithms and deep learning algorithms (such as models 114 and 115) to clean, categorize, and classify transaction data or strings. This is done using “transaction embedding,” which involves represent each transaction and its corresponding transaction data as a vector in high or multi-dimensional space, where each dimension corresponds to a specific feature or attribute of the corresponding transaction.” “[0022] Next, model manager 116 transforms each transaction string into a high-dimensional vector using an embedding algorithm, such as word-to-vector (Word2Vec) or GloVe. Notably, other embedded algorithms or customized embedding algorithms can also be used. The result of processing the embedding algorithm provides semantic meaning to a given transaction and its transaction string and allows for the detection of similarities and differences between other transactions and their transaction strings within multi-dimensional space.”
Tan (U.S. 20220012106):
[0024] In addition, the methods and apparatus disclosed herein resolve the aforementioned challenges of manually deriving a pathway between a software layer and a hardware microservice by introducing an intelligent engine (e.g., the dynamic software engine 302 of FIG. 3 below) that can dynamically evolve or orchestrate an API execution recipe and adjust the depth of software layers needed to expose a hardware feature/function interface to software application. The methods and apparatus disclosed herein provide for the discovery of functional application interfaces (FAPIs) and corresponding system application interface (SAPIs) from a registry having FAPIs and corresponding SAPIs supplied by one or more registries of a federation of registries.
Wang (US 20200359087):
[0020] The adaptive rate control adjustment module 242 is configured to adaptively adjust the bit-rate of the encoder function of the hardware video encode and decode module 212 with regard to a target (send) bit-rate for the conferencing video endpoint 100 and to drop frames to maintain the desired bit-rate as between adjustments of the hardware video encode and decode module 212.
[0025] If step 410 determines it is time for an adjustment determination, operation proceeds to step 414 to determine if more than 256 frames have been dropped since the last rate adjustment determination. This is done by checking the skipped frame counter that is incremented in step 408. The skipped frame counter is cleared in this determination of step 414. If more than 256 frames have been skipped, operation proceeds to step 416. In step 416 the application programming interface (API) of the SOC 204 is used to decrease the bit rate value of the hardware video encode and decode module 212 and operation proceeds to step 412.
Carlen (U.S. 20140298091): “[0062] … Each of such combinations may be represented by single API calls with represent multi-step complex logic, or the grouping and sequential request of several individual API calls, which represent primitive hardware functions, such as on, off, flash, and adjust color. API definitions supporting the above examples may be for entering pulsating mode, set pulsation frequency, and set LED color, for example.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARIBA SIRJANI whose telephone number is (571)270-1499. The examiner can normally be reached 9 to 5, M-F.
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 Desir can be reached at 571-272-7799. 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.
/Fariba Sirjani/
Primary Examiner, Art Unit 2659
Prosecution Insights