DETAILED ACTION
1. Claims 1-4, 6-15, and 17-22 are pending.
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 .
Priority
2. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 18/497,517, filed on December 13, 2023.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on January 15, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 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.
4. Claim 9 is 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.
The following claim language is unclear:
Claim 9 includes the limitations of “further comprising obtaining a matched solution template when the first keyword matches a second keyword of the matched solution template, and wherein the matched solution template is the alternative solution template.” It is unclear from the context of the claim what the first keyword is referring to. For examination purposes, examiner interprets the limitation as when the first keyword of the service request matches a second keyword of a solution template, that solution template is selected as the matched solution template.
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.
5. Claims 1-4, 6, 8, 12-15, 17, 19, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Cherumbath et al. US 20200067796 A1 in view of Melander et al. US 20150271251 A1
Cherumbath et al. US 20200067796 A1 was cited in IDS filed January 15, 2025.
6. With regard to claim 1, Cherumbath teaches:
A method comprising:
obtaining a service request of a user ([0003] According to some possible implementations, a method may include providing, by a device, a user interface for accepting user input, and receiving, by the device and through the user interface, a service request from a user device.);
obtaining a script of a target solution, wherein the target solution comprises products that satisfy the service request ([0003] The service request may include data identifying a service to be deployed in a cloud computing environment, data identifying an execution environment in which the service is to be deployed, data identifying a framework on which the service is to be deployed, and data identifying a version strategy to be applied to the service [...] The method may include identifying, by the device, a service template based on the service, and the service template may specify a virtual hardware configuration. The method may include providing, by the device and to a service deployment platform, instructions to deploy the service using the virtual hardware configuration. The instructions may include the data identifying the execution environment, the data identifying the framework, and the data identifying the version strategy; Examiner’s Note: The script of the target solution is the template for the service. The request contains a script which comprises products that satisfy the service request: execution environment, framework, and version strategy.);
sending a configuration of the target solution to a terminal ([0039] User device 210 may receive information associated with a service request from a user (e.g., via a user interface), and may provide a service request (e.g., including data identifying a service, data identifying an execution environment, data identifying a framework, data identifying a version, and/or the like) to service deployment manager 220; [0040] Service deployment manager 220 includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with deploying services. For example, service deployment manager 220 may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, and/or a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), and/or may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device. In various implementations, service deployment manager 220 may be hosted in a cloud computing environment, may be implemented outside of a cloud computing environment, or may be partially cloud-based.); and
receiving an acknowledgment for the configuration or a modified configuration parameter from the terminal ([0028] In some implementations, the service deployment manager may enable a user (e.g., the user associated with the user device and/or the service request) to modify a template. For example, in a situation where the service deployment manager has identified a service template for the service, the service deployment manager may present one or more of the virtual hardware configuration options to the user, enabling the user to change one or more of the virtual hardware configuration options (e.g., to add or remove virtual hardware resources to be used to deploy the service). In this situation, the changes the user is allowed to make to a service template and/or virtual hardware configuration may be based on permissions associated with the user's user account (e.g., a user may only be permitted to make changes that the user has permission to make).); and
deploying, on a cloud computing platform and after receiving the acknowledgment, the target solution for the user by using the script ([0028] In some implementations, the service deployment manager may enable a user (e.g., the user associated with the user device and/or the service request) to modify a template. For example, in a situation where the service deployment manager has identified a service template for the service, the service deployment manager may present one or more of the virtual hardware configuration options to the user, enabling the user to change one or more of the virtual hardware configuration options (e.g., to add or remove virtual hardware resources to be used to deploy the service). In this situation, the changes the user is allowed to make to a service template and/or virtual hardware configuration may be based on permissions associated with the user's user account (e.g., a user may only be permitted to make changes that the user has permission to make); [0061] In some implementations, the service request may include data identifying a service to be deployed in a cloud computing environment, data identifying an execution environment in which the service is to be deployed, data identifying a framework on which the service is to be deployed, and data identifying a version strategy to be applied to the service; [0062] As further shown in FIG. 4, process 400 may include receiving data identifying a user account associated with the service request (block 430). For example, the service deployment manager (e.g., using processor 320, memory 330, storage component 340, input component 350, communication interface 370, and/or the like) may receive, from the user device, data identifying a user account associated with the service request, as described above in connection with FIG. 1; [0063] As further shown in FIG. 4, process 400 may include determining that the user account has permission to deploy the requested service (block 440). For example, the service deployment manager (e.g., using processor 320, memory 330, storage component 340, and/or the like) may determine, based on the user account, that the user account has permission to deploy the requested service, as described above in connection with FIG. 1; [0064] As further shown in FIG. 4, process 400 may include identifying a service template based on the service (block 450). For example, the service deployment manager (e.g., using processor 320, memory 330, storage component 340, and/or the like) may identify a service template based on the service, as described above in connection with FIG. 1. In some implementations, the service template specifying a virtual hardware configuration; Examiner’s Note: The service request is deployed on a cloud computing environment. This is done using a template, which a user can acknowledge and modify according to user needs/permission.).
Although Cherumbath teaches of deploying a solution for a service request and sending and receiving the request to a service deployment manager, which may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, and/or a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), and/or may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device ([0040]). However, Cherumbath does not explicitly state that these devices are a terminal.
However, in analogous art, Melander teaches:
a terminal ([0024] The terminals 221,222,223 are mobile in the sense that they can change location but they still need access to cloud services. The terminals 221,222,223 can be wireless terminals such as smart phones, tablets, laptops, PCs etc and they can be portable or integrated in vehicles such as trucks, vans, trains etc [...] The cloud customer could even be a software client in the terminal working in a machine-to-machine (M2M) configuration in the cloud computing network 230.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cherumbath with the teachings of Melander wherein it is reasonable to interpret a device, which may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, and/or a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), and/or may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device to be a terminal. Similarly to Cherumbath, Melander teaches of deploying a cloud service to a customer by using a terminal. Additionally, the requested service and planned location of the cloud customer's terminal, time of arrival and duration is determined in advance by a cloud service deployment system that is receiving reservation requests comprising this information from the cloud customer's terminal [...] The cloud service is then deployed by the cloud service deployment system to the feasible cloud service processing environment closest to the terminal requesting the cloud service so that the cloud customer can access the requested cloud service at the estimated time of arrival and duration. ([0015]). Together, Cherumbath and Melander teach of receiving a service request from a user, obtain a script for a target solution that satisfies the service request, send a configuration of the solution to a terminal, receive acknowledgement for the configuration or modified configuration parameter from the terminal, and deploying the solution on cloud computing platform.
7. With regard to claim 2, Cherumbath further teaches:
wherein the script comprises default parameters for configuring the target solution ([0003] The method may include identifying, by the device, a service template based on the service, and the service template may specify a virtual hardware configuration. The method may include providing, by the device and to a service deployment platform, instructions to deploy the service using the virtual hardware configuration. The instructions may include the data identifying the execution environment, the data identifying the framework, and the data identifying the version strategy.).
8. With regard to claim 3, Cherumbath further teaches:
wherein the default parameters comprise:
a topology parameter, for configuring the products ([0024] As shown by reference number 140, the service deployment manager identifies a service template associated with the service. The service template specifies a virtual hardware configuration for the service. The virtual hardware configuration includes, for a particular service, virtual hardware resources that are to be allocated to perform the particular service. For example, virtual hardware resources may include a number and/or type of processors, an amount and/or type of memory, an amount and/or type of data storage, a type of network connection, a target server, a target rack, an operating system, firmware, software, and/or the like); and
a product parameter, for configuring the products ([0030] For example, the instructions may include data identifying the service, the service template (e.g., with the virtual hardware configuration), the service environment, the service framework, the service version, and/or the like. In some implementations, the instructions may include a link to an image of the service (e.g., an image that was previously prepared by the user for deployment). The image may be, for example, a container image (such as a Docker image, AppC image, and/or the like) that includes executable code and data representing service infrastructure. Providing the service deployment platform with instructions that include a link to an image for the service enables the service deployment platform to obtain the image and use the image, in addition to other information included in the instructions, to deploy the service.).
9. With regard to claim 4, Cherumbath further teaches:
wherein before deploying the target solution, the method further comprises:
generating, based on the service request, a service parameter for configuring the target solution ([0028] In some implementations, the service deployment manager may enable a user (e.g., the user associated with the user device and/or the service request) to modify a template. For example, in a situation where the service deployment manager has identified a service template for the service, the service deployment manager may present one or more of the virtual hardware configuration options to the user, [...]); and
updating a corresponding default parameter in the script using the service parameter ([0028] [...] enabling the user to change one or more of the virtual hardware configuration options (e.g., to add or remove virtual hardware resources to be used to deploy the service).).
10. With regard to claim 6, Cherumbath further teaches:
wherein when receiving the modified configuration parameter, the method further comprises updating a corresponding service parameter or a corresponding default parameter in the script using the modified configuration parameter ([0028] In some implementations, the service deployment manager may enable a user (e.g., the user associated with the user device and/or the service request) to modify a template. For example, in a situation where the service deployment manager has identified a service template for the service, the service deployment manager may present one or more of the virtual hardware configuration options to the user, enabling the user to change one or more of the virtual hardware configuration options (e.g., to add or remove virtual hardware resources to be used to deploy the service).).
11. With regard to claim 8, Cherumbath further teaches:
wherein before obtaining the script of a target solution, the method further comprises:
sending an alternative solution template matching the service request to the terminal, wherein the alternative solution template comprises a target solution template ([0027] In a situation where multiple service templates could be used to deploy the service, the service deployment manager may identify the service template to be used in a variety of ways. For example, the service deployment manager may use a priority scheme where certain types of templates have higher priority than others (e.g., more granular or specific templates may have priority over general service templates, and user account specific templates may have a highest priority). As another example, the service deployment manager may determine which service template to use based on available resources (e.g., in a situation where resources are limited and some service templates require more resources than the resources available for deployment). In some implementations, user input may be used to determine which service template to be used (e.g., a user may be presented with a choice of service templates to be used).); and
receiving an identifier of the target solution template from the terminal ([0027] The service template may be identified by the service deployment manager in a variety of ways. In some implementations, data that maps services, user accounts, service deployment options, and/or the like to service templates may be stored by or otherwise accessible to the service deployment manager (e.g., stored in the service deployment data storage device, another data storage device, a separate device, and/or the like). The deployment manager may identify the service template to be used based on the mapping. In a situation where multiple service templates could be used to deploy the service, the service deployment manager may identify the service template to be used in a variety of ways),
wherein the target solution template describes the target solution, and wherein the script is associated with the target solution template ([0027] For example, the service deployment manager may use a priority scheme where certain types of templates have higher priority than others (e.g., more granular or specific templates may have priority over general service templates, and user account specific templates may have a highest priority). As another example, the service deployment manager may determine which service template to use based on available resources (e.g., in a situation where resources are limited and some service templates require more resources than the resources available for deployment). In some implementations, user input may be used to determine which service template to be used (e.g., a user may be presented with a choice of service templates to be used).).
Although Cherumbath teaches of deploying a solution for a service request and sending and receiving the request to a service deployment manager, which may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, and/or a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), and/or may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device ([0040]). However, Cherumbath does not explicitly state that these devices are a terminal.
However, in analogous art, Melander teaches:
a terminal ([0024] The terminals 221,222,223 are mobile in the sense that they can change location but they still need access to cloud services. The terminals 221,222,223 can be wireless terminals such as smart phones, tablets, laptops, PCs etc and they can be portable or integrated in vehicles such as trucks, vans, trains etc [...] The cloud customer could even be a software client in the terminal working in a machine-to-machine (M2M) configuration in the cloud computing network 230.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cherumbath with the teachings of Melander wherein it is reasonable to interpret a device, which may include a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, and/or a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), and/or may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device to be a terminal. Similarly to Cherumbath, Melander teaches of deploying a cloud service to a customer by using a terminal. Additionally, the requested service and planned location of the cloud customer's terminal, time of arrival and duration is determined in advance by a cloud service deployment system that is receiving reservation requests comprising this information from the cloud customer's terminal [...] The cloud service is then deployed by the cloud service deployment system to the feasible cloud service processing environment closest to the terminal requesting the cloud service so that the cloud customer can access the requested cloud service at the estimated time of arrival and duration. ([0015]). Together, Cherumbath and Melander teach of receiving a service request from a user, obtain a script for a target solution that satisfies the service request, send a configuration of the solution to a terminal, receive acknowledgement for the configuration or modified configuration parameter from the terminal, and deploying the solution on cloud computing platform.
12. Regarding claim 12, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
13. Regarding claim 13, it is rejected under the same reasoning as claim 2 above. Therefore, it is rejected under the same rationale.
14. Regarding claim 14, it is rejected under the same reasoning as claim 3 above. Therefore, it is rejected under the same rationale.
15. Regarding claim 15, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
16. Regarding claim 17, it is rejected under the same reasoning as claim 6 above. Therefore, it is rejected under the same rationale.
17. Regarding claim 19, it is rejected under the same reasoning as claim 8 above. Therefore, it is rejected under the same rationale.
18. Regarding claim 22, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
19. Claims 7, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Cherumbath et al. US 20200067796 A1 and Melander et al. US 20150271251 A1, as applied to claim 1, and in further view of Ng et al. US 20210314407 A1.
20. With regard to claim 7, Cherumbath and Melander teach the method of claim 1 but fail to explicitly teach further comprising determining a solution matching a first keyword of the service request as the target solution.
However, in analogous art, Ng teaches:
further comprising determining a solution matching a first keyword of the service request as the target solution ([0063] Voice assistance unit 414 integrates the voice assistance service software development kit (SDK) of an existing cloud solution to home cloud 401. For example, the Alexa Voice Service SDK may be integrated into home cloud 401. This unit utilizes the mic hardware (for example, mic array 515 as shown in FIG. 5) of home cloud 401 to monitor the triggering keyword and capture the voice data from a user. If it finds a matched keyword, it may send out a voice service request to an external service provider. The external service provider processes the request and sends the action plus the voice notification back to voice assistance unit 414. The action sent back from the external service provider may be a MQTT based message, which may trigger the rules engine on home cloud 401 to take care of subsequent actions. The voice notification may be played back by the speaker hardware (for example, speaker array 516) of home cloud 401 by voice assistant unit 414.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cherumbath and Melander with the teachings of Ng further comprising determining a solution matching a first keyword of the service request as the target solution. Together, Cherumbath and Melander teach of receiving a service request from a user, obtain a script for a target solution that satisfies the service request, send a configuration of the solution to a terminal, receive acknowledgement for the configuration or modified configuration parameter from the terminal, and deploying the solution on cloud computing platform. Similarly, Ng teachings of a cloud computing system that includes a voice assist unit that helps provide a solution to a user based on the user’s request. The request is analyzed based on identifying keywords. As discussed in Ng, this helps simplify the process for user since the user may articulate an IoT device request rather than entering the request through mobile device 412 when the user is in close proximity to voice assistance unit 414, for example a voice assistance electronic circuit. Continuing the example, the user may verbally request to subscribe to messages published by IoT device 305 (as shown in FIG. 3) through broker 308 when executing app 307 while viewing device data from IoT device 304 on the mobile device. Consequently, home computing cloud may handle multiple device operations in parallel, where one operation is initiated directly through mobile device 412 and the other through voice assistance unit 414 ([0062]). Therefore, pulling keywords of a user requests helps properly identify an action/solution for the user, and integrating it into a voice assistant unit only simplifies the process even more.
21. With regard to claim 11, Cherumbath and Melander teach the method of claim 8 but fail to explicitly teach wherein obtaining the service request comprises: receiving a voice input from the terminal; and obtaining the service request based on the voice input.
However, Ng further teaches:
wherein obtaining the service request comprises:
receiving a voice input from the terminal ([0063] Voice assistance unit 414 integrates the voice assistance service software development kit (SDK) of an existing cloud solution to home cloud 401. For example, the Alexa Voice Service SDK may be integrated into home cloud 401. This unit utilizes the mic hardware (for example, mic array 515 as shown in FIG. 5) of home cloud 401 to monitor the triggering keyword and capture the voice data from a user. If it finds a matched keyword, it may send out a voice service request to an external service provider.); and
obtaining the service request based on the voice input ([0062] Home computing cloud 401 may support voice assistance unit 414 that facilitates a natural interaction with a user and home computing cloud 401 associated with an application executing on mobile device 412. For example, the user may articulate an IoT device request rather than entering the request through mobile device 412 when the user is in close proximity to voice assistance unit 414, for example a voice assistance electronic circuit. Continuing the example, the user may verbally request to subscribe to messages published by IoT device 305 (as shown in FIG. 3) through broker 308 when executing app 307 while viewing device data from IoT device 304 on the mobile device; [0063] The external service provider processes the request and sends the action plus the voice notification back to voice assistance unit 414. The action sent back from the external service provider may be a MQTT based message, which may trigger the rules engine on home cloud 401 to take care of subsequent actions. The voice notification may be played back by the speaker hardware (for example, speaker array 516) of home cloud 401 by voice assistant unit 414.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cherumbath and Melander with the teachings of Ng wherein obtaining the service request comprises: receiving a voice input from the terminal; and obtaining the service request based on the voice input. Together, Cherumbath and Melander teach of receiving a service request from a user, obtain a script for a target solution that satisfies the service request, send a configuration of the solution to a terminal, receive acknowledgement for the configuration or modified configuration parameter from the terminal, and deploying the solution on cloud computing platform. Similarly, Ng teachings of a cloud computing system that includes a voice assist unit that helps provide a solution to a user based on a voice input. As discussed in Ng, this helps simplify the process for user since the user may articulate an IoT device request rather than entering the request through mobile device 412 when the user is in close proximity to voice assistance unit 414, for example a voice assistance electronic circuit. Continuing the example, the user may verbally request to subscribe to messages published by IoT device 305 (as shown in FIG. 3) through broker 308 when executing app 307 while viewing device data from IoT device 304 on the mobile device. Consequently, home computing cloud may handle multiple device operations in parallel, where one operation is initiated directly through mobile device 412 and the other through voice assistance unit 414 ([0062]). Therefore, pulling keywords of a user requests helps properly identify an action/solution for the user, and integrating it into a voice assistant unit only simplifies the process even more.
22. Regarding claim 18, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
23. Claims 9-10 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Cherumbath et al. US 20200067796 A1 and Melander et al. US 20150271251 A1, as applied to claim 1, and in further view of Xi US 20200007957 A1.
24. With regard to claim 9, Cherumbath and Melander teach the method of claim 8 but fail to explicitly teach further comprising obtaining a matched solution template when the first keyword matches a second keyword of the matched solution template, and wherein the matched solution template is the alternative solution template.
However, in analogous art Xi teaches:
further comprising obtaining a matched solution template when the first keyword matches a second keyword of the matched solution template, and wherein the matched solution template is the alternative solution template ([0016] In some embodiments, the video search request is a voice request; the wearable device is further configured to: determine a search keyword indicated by the voice request; and the wearable device is further configured to: search for the video file based on the search keyword; Examiner’s Note: The keyword of the voice request matches a search keyword indicated by the voice request, which helps the device search for a video file based on the search keyword. The video file is the alternative solution template.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cherumbath and Melander with the teachings of Xi further comprising obtaining a matched solution template when the first keyword matches a second keyword of the matched solution template, and wherein the matched solution template is the alternative solution template. Xi teaches of a wearable device with an information processing system that searches for a video based on a user’s voice input and keywords, which is similar to additional art Ng that is found in current rejection. The user in the present embodiment can interact with the wearable device in the form of voice, eliminating the need for operation and is highly efficient. In addition, in this embodiment, by searching for the keywords in the voice request, a relatively accurate video file can be obtained, as discussed in Xi ([0066]).
25. With regard to claim 10, Xi further teaches:
wherein the alternative solution template is a video file or a solution document ([0064] In some embodiments, the video search request is a voice request; the method further includes: determining a voice keyword indicated by the voice request; and the searching for a video file indicated by a video search request, includes: searching for the video file based on the voice keyword.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cherumbath and Melander with the teachings of Xi wherein the alternative solution template is a video file or a solution document. Together, Cherumbath and Melander teach of receiving a service request from a user, obtain a script for a target solution that satisfies the service request, send a configuration of the solution to a terminal, receive acknowledgement for the configuration or modified configuration parameter from the terminal, and deploying the solution on cloud computing platform. Cherumbath and Melander teach of a terminal being a communication and/or computing device, such as a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, and/or a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), and/or may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device (Cherumbath [0040]), or the terminals 221,222,223 are mobile in the sense that they can change location but they still need access to cloud services. The terminals can be wireless terminals such as smart phones, tablets, laptops, PCs etc. and they can be portable or integrated in vehicles such as trucks, vans, trains etc. [...] The cloud customer could even be a software client in the terminal working in a machine-to-machine (M2M) configuration in the cloud computing network 230 (Melander [0024]). Similarly, Xi teaches of a wearable device with an information processing system that searches for a video based on a user’s voice input and keywords, which is similar to additional art Ng that is found in current rejection. The user in the present embodiment can interact with the wearable device in the form of voice, eliminating the need for operation and is highly efficient. In addition, in this embodiment, by searching for the keywords in the voice request, a relatively accurate video file can be obtained, as discussed in Xi ([0066]).
26. Regarding claim 20, it is rejected under the same reasoning as claim 9 above. Therefore, it is rejected under the same rationale.
27. Regarding claim 21, it is rejected under the same reasoning as claim 10 above. Therefore, it is rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AN-AN N NGUYEN whose telephone number is (571)272-6147. The examiner can normally be reached Monday-Friday 8:00-5:00 ET.
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, AIMEE LI can be reached at (571) 272-4169. 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.
/AN-AN NGOC NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195