DETAILED ACTION
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 Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Use of the word “means” (or “step for”) in a claim with functional language creates a rebuttable presumption that the claim element is to be treated in accordance with 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is invoked is rebutted when the function is recited with sufficient structure, material, or acts within the claim itself to entirely perform the recited function.
Absence of the word “means” (or “step for”) in a claim creates a rebuttable presumption that the claim element is not to be treated in accordance with 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph). The presumption that 35 U.S.C. 112(f) (pre-AIA 35 U.S.C. 112, sixth paragraph) is not invoked is rebutted when the claim element recites function but fails to recite sufficiently definite structure, material or acts to perform that function.
Claim elements in this application that use the word “means” (or “step for”) are presumed to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Similarly, claim elements that do not use the word “means” (or “step for”) are presumed not to invoke 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “processing unit” in claim 12.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-6 and 14-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 3 and 4 recite “a digital assistant”. However, “a digital assistant” and “a target digital assistant” have been previously introduced in claim 1. This antecedent basis ambiguity renders the scope of the claim indefinite. Similarly for claims 14-15.
Dependent claims incorporate all of the limitations of their respective independent or intervening claim(s) and are rejected on the same basis.
Prior Art
Listed herein below are the prior art references relied upon in this Office Action:
Pitchaimani (US Patent Application Publication 20190132321), referred to as Pitchaimani herein.
Kannan et al. (US Patent Application Publication 2016/0155442), referred to as Kannan herein.
Gupta et al. (US Patent Application Publication 2018/0190278), referred to as Gupta herein.
Examiner’s Note
Strikethrough notation in the pending claims has been added by the Examiner.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-2, 4, and 7-11 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pitchaimani.
Regarding claim 1, Pitchaimani discloses a method of digital assistant creation, comprising (Pitchaimani, Abstract, ¶0003 – linking a digital assistant with an application provides a user with a digital assistant for the linked the application):
obtaining registration information of a first assistant application platform, the registration information comprising at least a first interface definition for releasing a digital assistant on the first assistant application platform (Pitchaimani, ¶0080 – registry of applications available to the user. Users can register which applications are to be accessible to the digital assistant. ¶0082 – backend server can forward API calls to the third-party application. ¶0092-¶0093, ¶0119 – API call can include credentials and commands for accessing permitted applications. Applicant’s Specification ¶0046 indicates that an interface definition may be an API);
receiving release confirmation information for a target digital assistant, the release confirmation information indicating release of the target digital assistant to the first assistant application platform (Pitchaimani, Fig. 5B, 5D with ¶0092, ¶0098 ¶0101-¶0106 – the user is prompted to enable the digital assistant to access the application);
and in response to the release confirmation information, releasing the target digital assistant to the first assistant application platform based on at least the first interface definition (Pitchaimani, Fig. 5B, 5D with ¶0092, ¶0098, ¶0101-¶0106 – the user is prompted to enable the digital assistant to access the application. Prior to authorization, the access is blocked. ¶0050 – API).
Regarding claim 2, Pitchaimani discloses the limitations of claim 1 above, and further discloses wherein the registration information further comprises an authorization mode of the first assistant application platform for an assistant creator, and wherein releasing the target digital assistant to the first assistant application platform comprises: in response to the release confirmation information, requesting, based on the authorization mode, the first assistant application platform to perform authorization on a creator of the target digital assistant (Pitchaimani, ¶0039-¶0041, ¶0045, ¶0049, ¶0064 – application authorization using user credentials); and
releasing, based on the first interface definition, the target digital assistant to the first assistant application platform in response to determining that the authorization of the first assistant application platform on the creator of the target digital assistant is completed (Pitchaimani, ¶0045, ¶0048-¶0049, ¶0064 – application authorization enables the assistant to fulfill the request within the application).
Regarding claim 4, Pitchaimani discloses the limitations of claim 1 above, and further discloses in response to the registration information of the first assistant application platform, associating the first assistant application platform with a third interface definition that defines an interaction interface between a user and a digital assistant released on the first assistant application platform (Pitchaimani, ¶0101 – multiple applications can be authorized for access. ¶0050 – API. ¶0106 – digital assistant performs actions within the GUI).
Regarding claim 7, Pitchaimani discloses the limitations of claim 1 above, and further discloses wherein receiving release confirmation information for a target digital assistant comprises: providing a candidate platform list in response to detecting a release request for the target digital assistant, the candidate platform list comprising at least the registered first assistant application platform (Pitchaimani, Fig. 5B and 5D with ¶0097–¶0106 – list of menu options associated for the application. ¶0080, ¶0101 – the portal can list all available applications for digital assistant access within the GUI);
and receiving the release confirmation information based on at least a selection of the first assistant application platform and a release confirmation of the target digital assistant (Pitchaimani, ¶0099 – generating an authorized session with the digital assistant and application based on selection of approval for the assistant with the application. Fig. 5C – session confirmation is displayed. ¶0062, ¶0079 - confirmation).
Regarding claim 8, Pitchaimani discloses the limitations of claim 1 above, and further discloses wherein the registration information further comprises description information for the first assistant application platform (Pitchaimani, Fig. 5D – application information for authorization is displayed. ¶0080, ¶0101 – the portal can list all available applications for digital assistant access within the GUI).
Regarding claim 9, Pitchaimani discloses the limitations of claim 1 above, and further discloses wherein obtaining registration information of the first assistant application platform comprises: receiving a registration request for the first assistant application platform; providing a registration page to the first assistant application platform, the registration page comprising an input control for receiving registration information; and receiving, via the registration page, the registration information of the first assistant application platform (Pitchaimani, Fig. 5B and 5D with ¶0097–¶0106 – authorization page for generating a registered digital assistant authorized to access the application. ¶0080, ¶0101 – the portal can list all available applications for digital assistant access within the GUI for selection. ¶0045, ¶0048-¶0049, ¶0064 – application authorization enables the assistant to fulfill the request within the application).
Regarding claim 10, Pitchaimani discloses the elements of claim 1 above, and further discloses wherein the registration information is received at an assistant creation platform distinct from the assistant application platform, and wherein the interface definition in the registration information is based on an application programming interface specification parseable by the assistant creation platform (Pitchaimani, ¶0045, ¶0050 – API call to the portal application to open a third party application, and API call to the third-party application to perform the action. Fig. 3 with ¶0082 – backend server verifies whether the application is available, and forwards the API call to the third-party application. ¶0093 – API call can be generated by the portal. ¶0119 – API call can be generated by the backend. ¶0065, ¶0081 – application registration represented in profile links access to the application API used to communicate commands).
Regarding claim 11, Pitchaimani discloses the elements of claim 1 above, and further discloses sending, to the first assistant application platform, a release notification of the target digital assistant being released (Pitchaimani, ¶0115-¶0117 – credentials are passed to the application based on user authentication at the server and access to the application. ¶0058 – notification is sent to the remote application of access request. Fig. 3 with E362, E364, E382 with ¶0071-¶0073, ¶0082 – messages sent to third party application. E361, E370 with ¶0070, ¶0077 – remote application notifications).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 3, 12-15, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pitchaimani in view of Kannan.
Regarding claim 3, Pitchaimani discloses the limitations of claim 1 above, and further discloses wherein the registration information further comprises providing, based on
However, Pitchaimani appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Kannan discloses a digital personal assistance infrastructure service (Kannan, Abstract), including
a second interface definition for accessing a digital assistant released on the first assistant application platform (Kannan, ¶0052, ¶0092-¶0101, ¶0115, Table 1 – contract interface specification during registration of an action provider. An example command definition file is shown. An action provider can be registered for more than one task. An example is given for an action provider that includes different definitions for different tasks such as messaging and calling. ¶0169-¶0173 – an example is given of Skype for VOIP and video calls).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the digital assistant interface of Pitchaimani to include different interface definitions for different tasks with the same application based on the teachings of Kannan. The motivation for doing so would have been to enable additional extension of personal digital assistant functionalities (Kannan, ¶0172).
Regarding claim 12, Pitchaimani an electronic device, comprising: ¶0003 – linking a digital assistant with an application provides a user with a digital assistant that can perform automation within the application. Fig. 1 with ¶0037 – backend server. This element is interpreted under 35 U.S.C. 112(f) as the hardware processor described in Applicant’s Specification ¶0122):
obtaining registration information of a first assistant application platform, the registration information comprising at least a first interface definition for releasing a digital assistant on the first assistant application platform (Pitchaimani, ¶0080 – registry of applications available to the user. Users can register which applications are to be accessible to the digital assistant. ¶0082 – backend server can forward API calls to the third-party application. ¶0092-¶0093, ¶0119 – API call can include credentials and commands for accessing permitted applications. Applicant’s Specification ¶0046 indicates that an interface definition maybe an API);
receiving release confirmation information for a target digital assistant, the release confirmation information indicating release of the target digital assistant to the first assistant application platform (Pitchaimani, Fig. 5B, 5D with ¶0092, ¶0098 ¶0101-¶0106 – the user is prompted to enable the digital assistant to access the application);
and in response to the release confirmation information, releasing the target digital assistant to the first assistant application platform based on at least the first interface definition (Pitchaimani, Fig. 5B, 5D with ¶0092, ¶0098 ¶0101-¶0106 – the user is prompted to enable the digital assistant to access the application. Prior to authorization, the access is blocked. ¶0050 – API).
However, Pitchaimani appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Kannan discloses a digital personal assistance infrastructure service (Kannan, Abstract), including
at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the electronic device to perform operations (Kannan, Fig. 9 with ¶0040, ¶0218-¶0219, ¶0225, ¶0238 – server computer including hardware memory storing instructions executed by a processor).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have backend of Pitchaimani to include a hardware processor executing instructions stored in hardware memory based on the teachings of Kannan. The motivation for doing so would have been to enable realization of the system using commercially available hardware (Kannan, ¶0238).
Regarding claim 13, Pitchaimani as modified discloses the limitations of claim 12 above, and further discloses wherein the registration information further comprises an authorization mode of the first assistant application platform for an assistant creator, and wherein releasing the target digital assistant to the first assistant application platform comprises: in response to the release confirmation information, requesting, based on the authorization mode, the first assistant application platform to perform authorization on a creator of the target digital assistant (Pitchaimani, ¶0039-¶0041, ¶0045, ¶0049, ¶0064 – application authorization using user credentials); and
releasing, based on the first interface definition, the target digital assistant to the first assistant application platform in response to determining that the authorization of the first assistant application platform on the creator of the target digital assistant is completed (Pitchaimani, ¶0045, ¶0048-¶0049, ¶0064 – application authorization enables the assistant to fulfill the request within the application).
Regarding claim 14, Pitchaimani as modified discloses the limitations of claim 12 above, and further discloses wherein the registration information further comprises a second interface definition for accessing a digital assistant released on the first assistant application platform (Kannan, ¶0052, ¶0092-¶0101, ¶0115 – contract interface specification during registration of an action provider. An action provider can be registered for more than one task. An example is given for an action provider that includes different definitions for different tasks such as messaging and calling. ¶0169-¶0173 – an example is given of Skype for VOIP and video calls),
the operations further comprising: in response to the target digital assistant being released to the first assistant application platform, providing, based on the second interface definition, an access link to the target digital assistant released on the first assistant application platform, wherein the target digital assistant is accessed on the first assistant application platform via the access link (Pitchaimani, Fig. 5B and 5D with ¶0098 and ¶0104-¶0106 – link to enable the digital assistant to perform the task. The task may be performed in the application GUI).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the digital assistant interface of Pitchaimani to include different interface definitions for different tasks with the same application based on the teachings of Kannan. The motivation for doing so would have been to enable additional extension of personal digital assistant functionalities (Kannan, ¶0172).
Regarding claim 15, Pitchaimani as modified discloses the limitations of claim 12 above, and further discloses wherein the operations further comprise: in response to the registration information of the first assistant application platform, associating the first assistant application platform with a third interface definition that defines an interaction interface between a user and a digital assistant released on the first assistant application platform (Pitchaimani, ¶0101 – multiple applications can be authorized for access. ¶0050 – API. ¶0106 – digital assistant performs actions within the GUI).
Regarding claim 18, Pitchaimani as modified discloses the limitations of claim 12 above, and further discloses wherein receiving release confirmation information for a target digital assistant comprises: providing a candidate platform list in response to detecting a release request for the target digital assistant, the candidate platform list comprising at least the registered first assistant application platform (Pitchaimani, Fig. 5B and 5D with ¶0097–¶0106 – list of menu options associated for the application. ¶0080, ¶0101 – the portal can list all available applications for digital assistant access within the GUI); and
receiving the release confirmation information based on at least a selection of the first assistant application platform and a release confirmation of the target digital assistant (Pitchaimani, ¶0099 – generating an authorized session with the digital assistant and application based on selection of approval for the assistant with the application. Fig. 5C – session confirmation is displayed. ¶0062, ¶0079 - confirmation).
Regarding claim 19, Pitchaimani as modified discloses the limitations of claim 12 above, and further discloses wherein the registration information further comprises description information for the first assistant application platform (Pitchaimani, Fig. 5D – application information for authorization is displayed. ¶0080, ¶0101 – the portal can list all available applications for digital assistant access within the GUI).
Regarding claim 20, Pitchaimani discloses a
obtaining registration information of a first assistant application platform, the registration information comprising at least a first interface definition for releasing a digital assistant on the first assistant application platform (Pitchaimani, ¶0080 – registry of applications available to the user. Users can register which applications are to be accessible to the digital assistant. ¶0082 – backend server can forward API calls to the third-party application. ¶0092-¶0093, ¶0119 – API call can include credentials and commands for accessing permitted applications. Applicant’s Specification ¶0046 indicates that an interface definition maybe an API);
receiving release confirmation information for a target digital assistant, the release confirmation information indicating release of the target digital assistant to the first assistant application platform (Pitchaimani, Fig. 5B, 5D with ¶0092, ¶0098 ¶0101-¶0106 – the user is prompted to enable the digital assistant to access the application); and
in response to the release confirmation information, releasing the target digital assistant to the first assistant application platform based on at least the first interface definition (Pitchaimani, Fig. 5B, 5D with ¶0092, ¶0098 ¶0101-¶0106 – the user is prompted to enable the digital assistant to access the application. Prior to authorization, the access is blocked. ¶0050 – API).
However, Pitchaimani appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Kannan discloses a digital personal assistance infrastructure service (Kannan, Abstract), including
a non-transitory computer-readable storage medium having a computer program stored thereon, the computer program being executable by a processor to perform operations (Kannan, Fig. 9 with ¶0040, ¶0218-¶0219, ¶0225, ¶0238 – server computer including hardware memory storing instructions executed by a processor).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have backend of Pitchaimani to include a hardware processor executing instructions stored in hardware memory based on the teachings of Kannan. The motivation for doing so would have been to enable realization of the system using commercially available hardware (Kannan, ¶0238).
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pitchaimani in view of Gupta.
Regarding claim 5, Pitchaimani discloses the limitations of claim 4 above, and further discloses after the target digital assistant is released to the first assistant application platform, receiving, based on the third interface definition, query content of a user for the target digital assistant from the first assistant application platform; determining response content to the query content using the target digital assistant; and providing the response content to the first assistant application platform based on the third interface definition, to
However, Pitchaimani appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Gupta discloses a digital assistant creation interface (Gupta, Abstract), including
generate a response message to the user by the first assistant application platform (Pitchaimani, Fig. 5F, 5H with ¶0053-¶0054, ¶0063-¶0065 – user queries for information and commands are responded to with confirmation or requests for additional information).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the digital assistant interface of Pitchaimani to include a response message prompt based on the teachings of Gupta. The motivation for doing so would have been enable the assistant to clarify queries, communicate completion status (Gupta, ¶0001-¶0002, ¶0065).
Regarding claim 6, Pitchaimani discloses the limitations of claim 4 above, and further discloses in response to obtaining registration information of a second assistant application platform, associating the second assistant application platform with the third interface definition (Pitchaimani, ¶0101 – multiple applications can be authorized for access. ¶0050 – API);
and after the target digital assistant is released to the second assistant application platform, receiving, based on the third interface definition, second query content of a user for the target digital assistant from the second assistant application platform (Pitchaimani, ¶0045-¶0047, ¶0106 – query to assistant to perform actions); and
determining, based on the second query content, second response content for the second query content using the target digital assistant; and providing the second response content to the second assistant application platform based on the third interface definition, to generate a second response
However, Pitchaimani appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Gupta discloses a digital assistant interface (Gupta, Abstract), including
generate a response message to the user by the first assistant application platform (Pitchaimani, Fig. 5F, 5H with ¶0053-¶0054, ¶0063-¶0065 – user queries for information and commands are responded to with confirmation or requests for additional information).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the digital assistant interface of Pitchaimani to include a response message prompt based on the teachings of Gupta. The motivation for doing so would have been enable the assistant to clarify queries, communicate completion status (Gupta, ¶0001-¶0002, ¶0065).
Claim(s) 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pitchaimani in view of Kannan in further view of Gupta.
Regarding claim 16, Pitchaimani as modified discloses the limitations of claim 15 above, and further discloses wherein the operations further comprise: after the target digital assistant is released to the first assistant application platform, receiving, based on the third interface definition, query content of a user for the target digital assistant from the first assistant application platform; determining response content to the query content using the target digital assistant; and providing the response content to the first assistant application platform based on the third interface definition, to
However, Pitchaimani appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Gupta discloses a digital assistant interface (Gupta, Abstract), including
generate a response message to the user by the first assistant application platform (Pitchaimani, Fig. 5F, 5H with ¶0053-¶0054, ¶0063-¶0065 – user queries for information and commands are responded to with confirmation or requests for additional information).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the digital assistant interface of Pitchaimani to include a response message prompt based on the teachings of Gupta. The motivation for doing so would have been enable the assistant to clarify queries, communicate completion status (Gupta, ¶0001-¶0002, ¶0065).
Regarding claim 17, Pitchaimani as modified discloses the limitations of claim 15 above, and further discloses wherein the operations further comprise: in response to obtaining registration information of a second assistant application platform, associating the second assistant application platform with the third interface definition (Pitchaimani, ¶0101 – multiple applications can be authorized for access. ¶0050 – API);
and after the target digital assistant is released to the second assistant application platform, receiving, based on the third interface definition, second query content of a user for the target digital assistant from the second assistant application platform (Pitchaimani, ¶0045-¶0047, ¶0106 – query to assistant to perform actions); and
determining, based on the second query content, second response content for the second query content using the target digital assistant; and providing the second response content to the second assistant application platform based on the third interface definition, to generate a second response
However, Pitchaimani appears not to expressly disclose the limitations in strikethrough above. However, in the same field of endeavor, Gupta discloses a digital assistant interface (Gupta, Abstract), including
generate a response message to the user by the first assistant application platform (Pitchaimani, Fig. 5F, 5H with ¶0053-¶0054, ¶0063-¶0065 – user queries for information and commands are responded to with confirmation or requests for additional information).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the digital assistant interface of Pitchaimani to include a response message prompt based on the teachings of Gupta. The motivation for doing so would have been enable the assistant to clarify queries, communicate completion status (Gupta, ¶0001-¶0002, ¶0065).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. References are at least relevant as indicated in the corresponding summary.
Koneru et al. (US Patent Application Publication 2024/0281619) – virtual assistant creation platform.
Harper et al. (US Patent Application Publication 2015/0169336) - virtual assistant creation platform.
Zheng et al. (US Patent Application Publication 2019/0034604) – virtual assistant application access link.
Knox (US Patent Application Publication 2018/0288616) – granting virtual assistant access to application data.
Singh et al. (US Patent Application Publication 2022/0066800) – virtual assistant credential management for authentication levels.
Brown et al. (US Patent Application publication 2015/0186156) – virtual assistant access authorization for another virtual assistant.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL W PARCHER whose telephone number is (303)297-4281. The examiner can normally be reached Monday - Friday, 9:00am - 5:00pm, Mountain Time.
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, William Bashore can be reached at (571)272-4088 (Eastern Time). 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.
/DANIEL W PARCHER/Primary Examiner, Art Unit 2174
Prosecution Insights