DETAILED ACTION
Applicant adds new claims 17-20.
Claims 1-20 rejected under 35 USC § 103.
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-3, 9-10, 12-17, and 19 are rejected under 35 U.S.C. 103 as being patentable over Socher et al., U.S. PG-Publication No. 2024/0020538 A1, in view of Gardner et al., U.S. PG-Publication No. 2024/0296177 A1.
Claim 1
Socher discloses a method implemented by one or more processors, the method comprising: receiving a user query associated with a client device. Socher discloses “methods for a real-time search based generative AI platform,” wherein “in response to a user input to perform an NLP task, the generative AI platform way trigger a real-time search based on the user input, and then aggregate search results to generate an output.” Socher, ¶ 21. The method receives “input 122” including a “user NL input 126 such as a user question, user parameters, user context, or other context” (i.e., user query). Id. at ¶ 26.
Socher discloses generating, by a large language model (LLM), an API query for an external application based on the user query. Text generation server 110 “may adopt at least NLP model 115 to generate a search query” (text generation server 110 → a large language model). Text generation server 110 “receives input 122 from a user device” and “may determine data sources that have been pre-defined as related to … elements of input 122.” Text generation server 110 “may then convert the search query into customized search queries 111a-n that comply with a format requirement specific to data source 103a-n respectively.” (data sources 103 → external applications). The customized search queries 111a-n “are sent to respective data sources 103a-n through respective APIs 112a-n” (i.e., API queries based on the user query). Id. at ¶¶ 28-33.
Socher discloses wherein the external application has access to … [a] custom corpus of documents comprising a plurality of documents. The data sources 103 “may be any number of available databases, webpages, servers, blogs, content providers, cloud servers, and/or the like.” Id. at ¶ 27.
Socher discloses wherein the API query includes the user query. User input includes “a user NL input 126 such as a user question” (i.e., user query). Id. at ¶ 26. Server 110 uses NLP model 115 “to generate a search query” from the text input 126. Id. at ¶¶ 28, 32. The customized search queries are “sent to respective data sources … through respective APIs.” Id. at ¶ 33. Accordingly, the API query includes a search query based on a user question text.
Socher discloses querying the external application using the API query; and receiving, from the external application and in response to the API query, data representative of one or more documents in the … custom corpus of documents. The customized search queries 111a-n “are sent to respective data sources 103a-n through respective APIs 112a-n,” and in response, “the data sources 103a-n may return query results 113a-n in the form of links to webpages and/or cloud files to the text generation server 110” (query results 113 → data representative of one or more documents). Id. at ¶ 33.
Socher discloses generating, by the LLM, a response to the user query conditioned on the data representing one or more of the documents in the … custom corpus of documents received from the external application; and causing the response to the user query to be rendered at the client device. Socher discloses that instead of presenting links to search results to the user, “the text generation server 110 may utilize one or more NLP models 115 to extract information from the search results, generate text based on the search results and any parameters specified in input 122, generate a natural language response, and return as a NL output 125 for display at the user device 120.” In one embodiment, at least one NLP model 114 may “parse the web content following the links provided” and “generate a summary of the web content from at least one search result 113a, and use such generated summary to generate the final NL output 125.” Id. at ¶¶ 34-35.
Socher does not expressly disclose wherein the external application has access to an access restricted custom corpus of documents comprising a plurality of documents; and wherein the API query includes access control data for accessing the access restricted custom corpus of documents.
Gardner discloses wherein the external application has access to an access restricted custom corpus of documents comprising a plurality of documents. Gardner discloses “an orchestrator … coordinating interactions among … one or more LLMs or LLM-based systems, information access devices, and/or data storage systems,” wherein the “interactions may include … using application programming interface (‘API’) calls, generating prompts, and/or generating responses.” Gardner, ¶ 4. Queries predicted by an AI model are “translated deterministically … into calls to APIs for other functions or services.” For example, orchestrator 215 may translate a query into an API call “for the data storage system 240 and/or the information access device 235.” Id. at ¶¶ 37-38. The information access device 235 “may determine a level of user access to data stored within the data storage system 240, based on at least one of an account of the user 205 or an authorization level of the user 205.” The user accessible portion 240a of the data storage system 240 is “determined based on the determined level of user access” (user accessible portion 240a → access restricted custom corpus of documents;). Id. at ¶¶ 39-40.
Gardner discloses wherein the API query includes access control data for accessing the access restricted custom corpus of documents. In one embodiment, natural language input request 251 is received from a user. AI Model 256 then generates one or more queries 255 based on request 251. For each query, “an execute query request 257 is provided to the access device or data store(s) 258. The execute query request 257 includes “user credentials, authentication details, or other account intimation the allows the access device or data stored 258 to determine the subset of the data stores 258 to which the user is able to access” (i.e., access control data). Prior to transmission, “the queries may be transformed into an API call that can be understood and processed by an API of the access device or data store(s) 258.” Id. at ¶¶ 53, 72, 75. An API call created by transforming a query with user credentials is analogous to an API query including access control data.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method for a real-time search based generative AI platform of Socher to incorporate an LLM accessing a restricted portion of data using API queries as taught by Gardner. One of ordinary skill in the art would be motivated to integrate an LLM accessing a restricted portion of data using API queries into Socher, with a reasonable expectation of success, in order to provide technical benefit to the technical problem “of increasing cumbersomeness and ineffectiveness in implementation of … search and access … in multitenancy contexts in which siloed or scoped access is combined with the search and access functionalities,” Gardner, ¶ 138; the improvement causing an orchestrator and LLMs to interact in “an efficient and high-performance manner that produces highly accurate and customized results that are specific to the user.” Id. at ¶ 5.
Claim 2
Socher discloses wherein generating, by the LLM, an API query for the external application based on the user query comprises: selecting, based on the user query, the external application from a plurality of external applications, wherein each external application is associated with a respective custom corpus of documents. Upon receiving input 122, the text generation server 110 “may determine whether a real-time search is needed, and/or which data source(s) may be searched.” Socher, ¶ 28. Text generation server 110 “receives input 122 from a user device” and “may determine data sources that have been pre-defined as related to … elements of input 122.” Id. at ¶ 31. Data sources 102 “may be any available number of available databases, webpages, servers, blogs, content providers, cloud servers, and/or the like” (i.e., each data source is associated with a respective custom corpus of documents).
Claim 3
Socher discloses wherein selecting the external application from the plurality of external applications is further based on one or more of: a state of the client device; one or more further queries associated with the client device; and/or user data associated with a user of the client device. Socher discloses that input 122 “may include a user NL input 126 such as a user question, user parameters, user context, or other context.” The user context “may include any user preferences such as a user preferred search source, user activities on social media, and/or the like.” Socher, ¶ 26. Text generation server 110 receives input 122 (e.g., user data) “from a user device 120” and determines “data sources that have been pre-defined as related to key words, phrases, topics, parameters, or other elements of input 122 related to search.” Id. at ¶ 31.
Claim 9
Socher discloses wherein the data representative of one or more documents in the access restricted custom corpus of documents comprises one or more of the documents and/or a portion of one or more of the documents. Socher discloses that instead of presenting links to search results to the user, “the text generation server 110 may utilize one or more NLP models 115 to extract information from the search results, generate text based on the search results and any parameters specified in input 122, generate a natural language response, and return as a NL output 125 for display at the user device 120.” In one embodiment, at least one NLP model 114 may “parse the web content following the links provided” and “generate a summary of the web content from at least one search result 113a, and use such generated summary to generate the final NL output 125.” Socher, ¶¶ 34-35.
Claim 10
Socher discloses wherein causing the response to the user query to be rendered at the client device comprises: causing a portion of a document in one or more of the documents to be incorporated into the response to the user query. Socher discloses that instead of presenting links to search results to the user, “the text generation server 110 may utilize one or more NLP models 115 to extract information from the search results, generate text based on the search results and any parameters specified in input 122, generate a natural language response, and return as a NL output 125 for display at the user device 120.” In one embodiment, at least one NLP model 114 may “parse the web content following the links provided” and “generate a summary of the web content from at least one search result 113a, and use such generated summary to generate the final NL output 125.” Socher, ¶¶ 34-35.
Claim 12
Socher discloses wherein causing the response to the user query to be rendered at the client device comprises: causing a selectable link to one or more of the documents in the access restricted custom corpus to be incorporated into the response rendered at the client device. Socher discloses that output 250 includes “a conversational text-based response presented in an element along with supporting links to different data sources.” Socher, ¶ 54.
Claim 13
Socher discloses generating, by the LLM, a further API query for a further external application based on the user query, wherein the further external application has access to a further access restricted custom corpus of documents comprising a plurality of further documents; and receiving, from the further external application and in response to the further API query, further data representative of one or more further documents in the further access restricted custom corpus of documents, wherein generating, by the LLM, the response to the user query is further conditioned on the further data representative of one or more of the further documents in the further access restricted custom corpus of documents. Socher discloses that “text generation server 110 interacts with various data sources 103a-n,” engages “models 115 to predict relevant data sources for the search,” determines “data sources that have been predefined as related to … input 122,” in order to generate “customized search queries 111a-n are sent to respective data sources 103a-n through respective APIs 112a-n.” Id. at ¶¶ 27-28, 31, 33. Socher discloses using a plurality of data sources; data source 112a is the claimed “external application” and data sources 112b-n are the claimed “further external applications.”
Claim 14
Socher discloses determining, by the LLM, whether the user query associated with the client device is directed towards the access restricted custom corpus of documents, and in response to a negative determination, generating, by the LLM, the response to the user query without querying the external application. Socher discloses that the “text generation server 110 may determine whether a real-time search is needed.” Socher, ¶ 28. If real-time search is not applied, then the LLM provides “a generative output based on knowledge they have obtained from prior training data.” See Id. at ¶ 20.
Claim 15
Claim 15 is rejected utilizing the rationale for Claim 1; the claim is directed to a system performing the method.
Claim 16
Claim 16 is rejected utilizing the rationale for Claim 1; the claim is directed at medium storing instructions corresponding to the method.
Claim 17
Gardner discloses wherein the access control data is associated with the client device, and wherein the access control data is received along with the user query. In one embodiment, natural language input request 251 is received from a user. AI Model 256 then generates one or more queries 255 based on request 251. For each query, “an execute query request 257 is provided to the access device or data store(s) 258. The execute query request 257 includes “user credentials, authentication details, or other account intimation the allows the access device or data stored 258 to determine the subset of the data stores 258 to which the user is able to access” (i.e., access control data). Prior to transmission, “the queries may be transformed into an API call that can be understood and processed by an API of the access device or data store(s) 258.” Gardner, ¶¶ 53, 72, 75. An API call created by transforming a query with user credentials is analogous to an API query including access control data.
Claim 19
Gardner discloses wherein querying the external application using the API query causes the external application to: determine whether the access control data included in the API query matches access control data associated with the access restricted custom corpus; and obtain, responsive to the access control data included in the API query matching the access control data associated with the access restricted custom corpus, the data representative of one or more of the documents in the access restricted custom corpus of documents. Gardner discloses “an orchestrator … coordinating interactions among … one or more LLMs or LLM-based systems, information access devices, and/or data storage systems,” wherein the “interactions may include … using application programming interface (‘API’) calls, generating prompts, and/or generating responses.” Gardner, ¶ 4. Queries predicted by an AI model are “translated deterministically … into calls to APIs for other functions or services.” For example, orchestrator 215 may translate a query into an API call “for the data storage system 240 and/or the information access device 235.” Id. at ¶¶ 37-38. The information access device 235 “may determine a level of user access to data stored within the data storage system 240, based on at least one of an account of the user 205 or an authorization level of the user 205.” The user accessible portion 240a of the data storage system 240 is “determined based on the determined level of user access” (user accessible portion 240a → access restricted custom corpus of documents;). Id. at ¶¶ 39-40.
Claims 4-8 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Socher et al., U.S. PG-Publication No. 2024/0020538 A1, in view of Gardner et al., U.S. PG-Publication No. 2024/0296177 A1, further in view of Misiewicz et al., U.S. PG-Publication No. 2022/0138170 A1.
Claim 4
Misiewicz discloses wherein generating, by the LLM, an API query for the external application based on the user query comprises: generating, by the LLM, a current context vector based on the user query; and generating, by the LLM, the API query based on the context vector. Misiewicz discloses a method for “generating vector representations of search result candidates and search query terms and producing search results based on a comparison of the vector representations.” A knowledge search system “receives a search query associated with the entity from an end user,” and a “set of search terms of the search query is identified and processed to generate embedding vectors for each search term.” Misiewicz, ¶¶ 11-12; See Also ¶ 38 (“labeled queries are used to train the neural network 117 to predict relationships between queries and documents”); ¶ 53 (“an entity-specific query rule can include a context associated with a search query”). Figure 3 illustrates operations performed by the knowledge search system. At 310, the system “receives from an end user system, a search query including a set of keywords associated with an entity.” At 320, the system “identifies, using a neural network, an embedding vector based on the set of keywords of the search query” (embedding vector associated with the search query → context vector). Id. at ¶¶ 60-62.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method for a real-time search based generative AI platform of Socher-Gardner to incorporate vector-based document search as taught by Misiewicz. One of ordinary skill in the art would be motivated to integrate vector-based document search into Socher-Gardner, with a reasonable expectation of success, “for improved query comprehension and enhanced candidate search result recall,” because the method “does not require a large number of word matches,” unlike conventional searching processes “that require many matches in words between the queries and unstructured documents.” Misiewicz, ¶ 40.
Claim 5
Misiewicz discloses wherein generating, by the LLM, the current context vector is further based on one or more of: a state of the client device; one or more further queries associated with the client device; and/or user data associated with a user of the client device. Misiewicz discloses that “the knowledge search system 110 can enable an entity to establish query rules to augment, modify, or guide the vector-based search result integration process.” Misiewicz, ¶ 48. In an embodiment, “the criteria and action for an entity-specific query rule can include a context associated with a search query … that can include one or more parameters such as attributes associated with the end user, a role associated with the end user, a segment associated with the end user, or other suitable parameter.” For example, “if an end user executing a search query via a financial service merchant system is identified as a ‘high net worth’ individual … the knowledge system 110 can perform a corresponding action pursuant to the query rule.” Id. at ¶ 53.
Claim 6
Misiewicz discloses wherein querying the external application using the API query causes the external application to: compare the context vector to a set of precomputed embeddings, each of the precomputed embeddings associated with a respective document in the access restricted custom corpus of documents. Figure 3 illustrates operations performed by the knowledge search system. At 310, the system “receives from an end user system, a search query including a set of keywords associated with an entity.” At 320, the system “identifies, using a neural network, an embedding vector based on the set of keywords of the search query” (embedding vector associated with the search query → context vector). At 330, the system “executes a comparison of the embedding vector associated with the search query to a set of embedding vectors associated with a set of structured data elements relating to the entity” (embedding vectors associated with a set of structured data elements → precomputed embeddings associated with a respective document). The set of structured data elements “is queries to identify candidate structured data elements which are within a distance threshold in a feature space based on the comparison of the embedding vectors.” Misiewicz, ¶¶ 60-64.
Misiewicz discloses select, based on the comparison of the context vector to the set of precomputed embeddings, one or more of the documents in the access restricted custom corpus of documents. At 340, the system “identifies, based on the comparison, a set of matching structured data elements,” wherein processing logic “applies a distance threshold to each of the generated distance metric scores.” The processing logic “can employ a top-N approach wherein an N number of structured data elements are identified as matching.” Id. at ¶¶ 65-66.
Misiewicz discloses provide, to the LLM, data representative of the selected one or more documents in the access restricted custom corpus of documents. At 350, the system may “generate a search result in response to the search query, wherein the search result includes at least a portion of the set of matching structured data elements,” wherein “the set of matching structured elements (e.g., the elements having a distance in the numerical vector space that is less than the distance threshold) can be further ranked based on their relative distance scores,” and “a portion of the matching structured data elements can be selected for inclusion in the search result.” Id. at ¶ 67.
Claim 7
Misiewicz discloses wherein causing the external application to select, based on the comparison of the context vector to the set of precomputed embeddings, one or more of the documents in the access restricted custom corpus of documents causes the external application to: determine a distance between the context vector and each of the precomputed embeddings; and select documents in the access restricted custom corpus of documents that are within a threshold distance of the context vector. Figure 3 illustrates operations performed by the knowledge search system. At 310, the system “receives from an end user system, a search query including a set of keywords associated with an entity.” At 320, the system “identifies, using a neural network, an embedding vector based on the set of keywords of the search query” (embedding vector associated with the search query → context vector). At 330, the system “executes a comparison of the embedding vector associated with the search query to a set of embedding vectors associated with a set of structured data elements relating to the entity” (embedding vectors associated with a set of structured data elements → precomputed embeddings associated with a respective document). The set of structured data elements “is queries to identify candidate structured data elements which are within a distance threshold in a feature space based on the comparison of the embedding vectors.” Misiewicz, ¶¶ 60-64.
Claim 8
Misiewicz discloses wherein causing the external application to select, based on the comparison of the context vector to the set of precomputed embeddings, one or more of the documents in the access restricted custom corpus of documents causes the external application to: determine a distance between the context vector and each of the precomputed embeddings. Figure 3 illustrates operations performed by the knowledge search system. At 310, the system “receives from an end user system, a search query including a set of keywords associated with an entity.” At 320, the system “identifies, using a neural network, an embedding vector based on the set of keywords of the search query” (embedding vector associated with the search query → context vector). At 330, the system “executes a comparison of the embedding vector associated with the search query to a set of embedding vectors associated with a set of structured data elements relating to the entity” (embedding vectors associated with a set of structured data elements → precomputed embeddings associated with a respective document). The set of structured data elements “is queries to identify candidate structured data elements which are within a distance threshold in a feature space based on the comparison of the embedding vectors.” Misiewicz, ¶¶ 60-64.
Misiewicz discloses the documents in the access restricted custom corpus of documents based on the distance between the context vector and the precomputed embedding for each document in the access restricted custom corpus of documents; and select the closest pre-defined number of documents from the access restricted custom corpus of documents. At 340, the system “identifies, based on the comparison, a set of matching structured data elements,” wherein processing logic “applies a distance threshold to each of the generated distance metric scores.” The processing logic “can employ a top-N approach wherein an N number of structured data elements are identified as matching.” Id. at ¶¶ 65-66. At 350, the system may “generate a search result in response to the search query, wherein the search result includes at least a portion of the set of matching structured data elements,” wherein “the set of matching structured elements (e.g., the elements having a distance in the numerical vector space that is less than the distance threshold) can be further ranked based on their relative distance scores,” and “a portion of the matching structured data elements can be selected for inclusion in the search result.” Id. at ¶ 67.
Claim 11
Misiewicz discloses wherein the data representative of one or more documents in the access restricted custom corpus of documents comprises an embedded representation of one or more of the documents. Misiewicz discloses a method for “generating vector representations of search result candidates and search query terms and producing search results based on a comparison of the vector representations.” A knowledge search system “receives a search query associated with the entity from an end user,” and a “set of search terms of the search query is identified and processed to generate embedding vectors for each search term.” Misiewicz, ¶¶ 11-12; See Also ¶ 38 (“labeled queries are used to train the neural network 117 to predict relationships between queries and documents”); ¶ 53 (“an entity-specific query rule can include a context associated with a search query”). Figure 3 illustrates operations performed by the knowledge search system. At 310, the system “receives from an end user system, a search query including a set of keywords associated with an entity.” At 320, the system “identifies, using a neural network, an embedding vector based on the set of keywords of the search query” (embedding vector associated with the search query → context vector). At 330, the system “executes a comparison of the embedding vector associated with the search query to a set of embedding vectors associated with a set of structured data elements relating to the entity” (embedding vectors associated with a set of structured data elements → precomputed embedded representation of one or more documents). The set of structured data elements “is queries to identify candidate structured data elements which are within a distance threshold in a feature space based on the comparison of the embedding vectors.” Id. at ¶¶ 60-64.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the method for a real-time search based generative AI platform of Socher-Gardner to incorporate vector-based document search as taught by Misiewicz. One of ordinary skill in the art would be motivated to integrate vector-based document search into Socher-Gardner, with a reasonable expectation of success, “for improved query comprehension and enhanced candidate search result recall,” because the method “does not require a large number of word matches,” unlike conventional searching processes “that require many matches in words between the queries and unstructured documents.” Misiewicz, ¶ 40.
Claims 18 and 20 are rejected under 35 U.S.C. 103 as being patentable over Socher et al., U.S. PG-Publication No. 2024/0020538 A1, in view of Gardner et al., U.S. PG-Publication No. 2024/0296177 A1, in further view of Park et al., U.S. Patent No. 11,163,621 B1.
Claim 18
Park discloses wherein the access control data is associated with the LLM, and wherein the access control data is assigned to the LLM by an organization. Park discloses “an API platform that may provide automatic user registration with various APIs, may automatically acquire credentials for accessing the APIs (including … API-key authentication approaches), and may utilize the pre-registered API-key … such that the user may quickly access … an API.” Park, 2:54-67. The API platform operates as a proxy for users in interacting with multiple API hosts” and is “capable of providing access to the various APIs 132 hosted by the API hosts 130” (e.g., API platform incorporated into an LLM). See Id. at 3:1-36. The API host 130 “may be a third party” (i.e., an organization). Id. at 4:14-17. The API platform “may automatically create and register an account for the new user” and “the API platform may automatically sign in to the API to verify the account creation” (i.e., the access control data is assigned by an organization). Id. at 5:21-38. The platform extracts the API-key authentication data; and the “API platform may store the API-key” (e.g., access control data is associated with the API platform at an LLM). See Id. at 5:60-6:12.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the LLM generating API queries of Socher-Gardner to incorporate obtaining API keys from API providers as taught by Park. One of ordinary skill in the art would be motivated to integrate obtaining API keys from API providers into Socher-Gardner, with a reasonable expectation of success, in order to improve performance of a computer by reducing software development overhead “by removing significant effort that must otherwise be expended in retrieving the access credentials manually from each API host,” thereby permitting “the automated acquisition of API access credentials and the renewal thereof from a single interface.” Park, 3:1-18.
Claim 20
Park discloses wherein the access control data comprises a token or a key. Park discloses “an API platform that may provide automatic user registration with various APIs, may automatically acquire credentials for accessing the APIs (including … API-key authentication approaches), and may utilize the pre-registered API-key … such that the user may quickly access … an API.” Park, 2:54-67. The API platform operates as a proxy for users in interacting with multiple API hosts” and is “capable of providing access to the various APIs 132 hosted by the API hosts 130” (e.g., API platform incorporated into an LLM). See Id. at 3:1-36. The API host 130 “may be a third party” (i.e., an organization). Id. at 4:14-17. The API platform “may automatically create and register an account for the new user” and “the API platform may automatically sign in to the API to verify the account creation” (i.e., the access control data is assigned by an organization). Id. at 5:21-38. The platform extracts the API-key authentication data; and the “API platform may store the API-key” (e.g., access control data is associated with the API platform at an LLM). See Id. at 5:60-6:12.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the LLM generating API queries of Socher-Gardner to incorporate obtaining API keys from API providers as taught by Park. One of ordinary skill in the art would be motivated to integrate obtaining API keys from API providers into Socher-Gardner, with a reasonable expectation of success, in order to improve performance of a computer by reducing software development overhead “by removing significant effort that must otherwise be expended in retrieving the access credentials manually from each API host,” thereby permitting “the automated acquisition of API access credentials and the renewal thereof from a single interface.” Park, 3:1-18.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. See Gardner et al., U.S. PG-Publication No. 2024/0296177 A1; Park et al., U.S. Patent No. 11,163,621 B1.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 9-5:30 CT.
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, KEVIN YOUNG can be reached at (571)270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 July 25, 2026
Prosecution Insights