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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because:
Reference character “638” has been used to designate both a wireless interface in Paragraph [96], line 6, and a user interface in Paragraph [98], line 1. Based on Fig. 6, reference character “638” should be used to designate the user interface of the AR wearable device 602, and Paragraph [96], line 6 should be corrected as follows: “wireless interfaces 634, [[638]]603”.
Reference character “638” has been used to describe a user interface of a client device in Paragraph [100] line 1, and a user interface of an AR wearable device in Paragraph [100], line 6. Based on Fig. 6, reference character “638” should be used to designate the user interface of the AR wearable device 602, and Paragraph [100], line 1 should be corrected as follows: “a user interface [[638]]614 of the client device 102”.
Reference character “632” has been used to designate both a field associated with the settings in Paragraph [98], line 2, and a category in Paragraph [105], line 4. Based on Fig. 6, reference character “632” should be used to designate the field associated with the settings, and Paragraph [105] should be corrected as follows: “within a category [[632]]628”
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they do not include the following reference sign(s) mentioned in the description:
reference character “62” in Paragraph [102], line 6. Based on Fig. 6, Paragraph [102], line 6 should be corrected as follows: “setting category module 627”.
reference character “817” in Paragraph [109], line 4, and Paragraph [110], lines 2, 12, and 15. Based on the drawings, Paragraph [109], line 4, should be corrected to recite “RPCs [[817]]617” and Paragraph [110], line 2, 12, and 15 should be corrected to recite “RPC [[817]]617”.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
In Paragraph [101], line 6, “change the settings more easily 630” should read “change the settings 630 more easily”.
In Paragraph [102], lines 2-4, the specification reads “The RPCs 617 include send settings for a category 618, where the settings category module 627 sends settings 610 of a category 608 from the client device 102 to the settings category module 606 of the client device 102.” As written, it states the client device 102 is sending settings to itself, which is inconsistent with Fig. 6. Based on Fig. 6, it appears the settings module 627 is part of the AR wearable device 602, with settings 630 and category 628. RPC 618 is sent from the AR wearable device 602 to the client device 102. Therefore, Paragraph [101], lines 2-4 should read: “The RPCs 617 include send settings for a category 618, where the settings category module 627 sends settings [[610]]630 of a category [[608]]628 from the [[client device 102]]AR wearable device 602 to the settings category module 606 of the client device 102.”
In Paragraph [106], line 5, ““sends a send get.
Appropriate correction is required.
Claim Objections
Claims 1, 3, 7, 14, 16 and 18 are objected to because of the following informalities:
In claim 1, line 5, “the RPC” should be corrected to recite “the first RPC”.
In claim 3, line 2, “the setting values” is unclear whether it is referring to “setting values for a plurality of categories of settings”, as first recited in claim 1, line 6, or “setting values for a category of settings of the plurality of categories for settings” as first recited in claim 1, line 11.
In claim 7, lines 3-4, “and default wearable device settings category” should be corrected to recite “and a default wearable device settings category”.
In claim 14, line 2, “with the client device” should be correct to recite “with the [[client]] wearable device”, as the recited client device of claim 10 would not be associating, using a lower energy communication protocol, with itself.
In claim 16, line 4, “the RPC” should be corrected to recite “the first RPC”.
In claim 18, line 3, “the setting values” is unclear whether it is referring to “setting values for a plurality of categories of settings”, as first recited in claim 16, line 5, or “setting values for a category of settings of the plurality of categories for settings” as first recited in claim 16, line 10.
Appropriate correction is required.
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 5, 11, 14, and 20 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.
The term “a lower energy communication protocol” in claims 5, 14, and 20 is a relative term which renders the claim indefinite. The term “a lower energy communication protocol” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Specifically, it is unclear what would make a particular communication protocol “lower energy” as there is no standard energy communication protocol defined which it must be lower than.
To overcome the above rejections, the Examiner recommends replacing “a lower energy communication protocol” with “an energy-conserving communication protocol”.
Claim 11 recites the limitation "the changed setting value" in lines 4-5. There is insufficient antecedent basis for this limitation in the claim.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-4, 6, 10-13, and 16-19 are rejected on the ground of no statutory double patenting as being unpatentable over claims 7-8 and 12-13 of U.S. Patent No. 12,086,661 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because:
It would have been obvious to one of ordinary skill in the art to have implemented the method performed on an augmented reality (AR) wearable device, where the AR wearable device comprises a first processor, as recited in dependent claim 7 of the reference patent, on the apparatus of a wearable device of claims 1-4 of the instant application, the apparatus of a wearable device comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations recited in the method of reference claim 7.
It would have been obvious to one of ordinary skill in the art to have implemented the method performed on a client device as recited in claims 12-13 of the reference patent, on the apparatus of a client device of claims 10-13 of the instant application, the apparatus of a client device comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations recited in the method of reference claims 12-13.
It would have been obvious to one of ordinary skill in the art to have implemented the method performed on an augmented reality (AR) wearable device, where the AR wearable device comprises a first processor, as recited in dependent claim 7 of the reference patent, as the non-transitory computer-readable storage medium recited in claims 16-19 of the instant application, the non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor of an apparatus of a wearable device, cause the at least one processor to perform operations comprising: the operations of the method recited in reference claim 7.
Further, regarding claim 6 of the instant application, claim 8 of the reference patent recites the first processor of the AR wearable device receiving a third RPC from a client device (see reference claim 7) to set settings, and sending the third RPC to a service manager on a second processor of the AR wearable device to set the settings. It would have been obvious to one of ordinary skill in the art that the first processor of the AR wearable device of the reference patent, would receive other communications from the client device (e.g., the first RPC to provide settings from the client device) in addition to receiving the third RPC to set settings from the client device, and would similarly send the other communications (e.g., the first RPC) to the service manager on the second processor to manage (e.g., retrieve) the settings according to the first RPC.
The claims of the instant application and the claims of the reference patent are compared in Table 1 below, with differences between the claims in bold.
Claims 5, 14, and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 7 and 14 of U.S. Patent No. 12,086,661 B2 in view of Goodine et al. (U.S. Pub. 2020/0112828), hereinafter Goodine.
Regarding claims 5, 14, and 20 of the instant application, claims 7 and 14 of the reference patent recite all of the limitations except “associating, using a lower energy communication protocol, with the client device, and wherein the receiving and the sending are both via the lower energy communication protocol”. However, Goodine teaches associating, using a lower energy communication protocol, with the client device, and wherein the receiving and the sending are both via the lower energy communication protocol ([0148] – “Since wearable computing device 710 is equipped with only a personal area network interface, software programs executed by wearable computing device 710 that desire data communications (e.g., with remote computing device 180) may create data packets using a specialized communications library, also called a companion service library, which allows for initial transmission of data via the personal area network interface to the host computing device 740; the host computing device 740 can receive these data transmissions and, using the companion service library, re-transmit them to the network on behalf of the wearable computing device 710. Likewise, host computing device 740 can receive transmissions from the network for delivery to wearable computing device 710.”; [0158] – “host personal area network service 750 may communicate with a personal area network service 735 of wearable computing device 710 via a general personal area network (e.g., Bluetooth™) or over a low-power personal area network (e.g., Bluetooth™ LE)”; [0209] – “the host computing device may listen for low power personal area network (e.g., Bluetooth LE) advertising packets from the wearable computing device, and establish an outbound low power personal area network connection to the wearable computing device in response.”).
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 claims of the reference patent such that the wearable device and client device associate using a lower energy communication protocol as taught by Goodine. Using a lower energy communication protocol would reduce energy and data usage (see Goodine: [0063]).
Additionally, it would have been obvious to one of ordinary skill in the art to have applied the limitations of the methods of claims 7 and 14 of the reference patent to the apparatuses of claims 5 and 14 of the instant application and to the non-transitory computer-readable storage medium of claim 20 of the instant application.
Claims 9 and 15 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 7 and 12 of U.S. Patent No. 12,086,661 B2 in view of KREITZER et al. (U.S. Pub. 2016/0080888), hereinafter KREITZER.
Regarding claim 9 of the instant application, claim 7 of the reference patent teaches all of the limitations except “sending, to an application server, a request for a suggested value for a setting; and receiving, from the application server, the suggested value for the setting.” However, KREITZER teaches sending, to an application server ([0045] – “the recommendation engine 100 is typically embodied by a cloud-based server”), a request for a suggested value for a setting ([0025] – “The wearable devices 120 can include the wearable devices 14-24 and the like, and the wearable devices 120 can form a PAN 125 with one another and the mobile device 12. Also, the users 110, 112, 115 can each have a mobile device 12. The users 110, 112, 115, via the associated mobile devices 12, have wireless links 130, 132, 135 to a WLAN/WAN 140, such as the Internet, for communication with the recommendation engine 100.”; [0028] – “Alternatively, the functionality associated with interacting with the recommendation engine 100 can be performed directly by the wearable devices 120 (e.g., either wirelessly if available, or when the wearable devices 120 are connected to a device that provides connectivity to the recommendation engine 100).”; [0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0034] – “The application can be configured to coordinate functionality between the wearable devices 120 and the recommendation engine 100. That is, the application can provide information sharing to the recommendation engine 100 from the users 110, 112, 115 and optimal applications and configurations for the wearable devices 120 from the recommendation engine 100. In an exemplary embodiment, the application can be implemented on the mobile device 12 such as a stand-alone application, a web browser plugin, or the like. In another exemplary embodiment, the application can be implemented on one or more of the wearable devices 120. A combination of these approaches is also contemplated.”; [0039] – “The recommendation process 240 includes receiving a request for a recommended configuration of a set of wearable devices for a user (step 242). Here, a specific user is requesting the optimal configuration. This can be done through the application, through a browser plugin, or based on manually inputting the wearable devices 120. […] the request can include the wearable devices 120 associated with the user.”; Claim 4 – “The method of claim 1, further comprising: transmitting a request for application information and configuration information as a function of the first set of wearable devices and the identified first type of user from the application and configuration recommendation engine” (see claim 1: "A method associated with a mobile device and a first set of a plurality of wearable devices”)); and receiving, from the application server ([0045]), the suggested value for the setting ([0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0043] – “The recommendation process 240 includes providing the determined optimal configuration in response to the request (step 248). The recommendation engine 100 can provide the determined optimal configuration over the WAN 140 and through the links 130, 132, 135. The recommendation process 240 includes manually and/or automatically configuring the set of wearable devices 120 with the determined optimal configuration (step 250). Here, the wearable devices 120 are automatically configured based on the determined optimal configuration and/or the determined optimal configuration is presented to the user 110, 112, 115 for manual configuration.”; Claim 4 – “receiving the recommended application information and configuration information from the application and configuration recommendation engine”).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of claim 7 of the reference patent such that the wearable device sends a request for a suggested value of a setting to an application server and receives the suggested value from the application server as taught by KREITZER. Doing so would allow for optimal application settings to be applied on the wearable device, where the optimal settings are determined based on analysis of data of a plurality of users (see KREITZER: [0003], [0020], and [0026]-[0027]).
Regarding claim 15 of the instant application, claim 12 of the reference patent teaches all of the limitations except “receiving, from the wearable device, a request for a suggested value for a setting; and sending, to the wearable device, the suggested value for the setting.” However, KREITZER teaches receiving, from the wearable device, a request for a suggested value for a setting ([0025] – “The wearable devices 120 can include the wearable devices 14-24 and the like, and the wearable devices 120 can form a PAN 125 with one another and the mobile device 12. Also, the users 110, 112, 115 can each have a mobile device 12. The users 110, 112, 115, via the associated mobile devices 12, have wireless links 130, 132, 135 to a WLAN/WAN 140, such as the Internet, for communication with the recommendation engine 100.”; [0028] – “in addition to the recommendation engine 100, a recommendation application can be operated on the mobile device 12 for interacting with the recommendation engine 100 and for performing various functions described herein with the PAN 125. Alternatively, the functionality associated with interacting with the recommendation engine 100 can be performed directly by the wearable devices 120 (e.g., either wirelessly if available, or when the wearable devices 120 are connected to a device that provides connectivity to the recommendation engine 100).”; [0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0034] – “The application can be configured to coordinate functionality between the wearable devices 120 and the recommendation engine 100. That is, the application can provide information sharing to the recommendation engine 100 from the users 110, 112, 115 and optimal applications and configurations for the wearable devices 120 from the recommendation engine 100. In an exemplary embodiment, the application can be implemented on the mobile device 12 such as a stand-alone application, a web browser plugin, or the like. In another exemplary embodiment, the application can be implemented on one or more of the wearable devices 120. A combination of these approaches is also contemplated.”; [0039] – “The recommendation process 240 includes receiving a request for a recommended configuration of a set of wearable devices for a user (step 242). Here, a specific user is requesting the optimal configuration. This can be done through the application, through a browser plugin, or based on manually inputting the wearable devices 120. […] the request can include the wearable devices 120 associated with the user.”; Claim 4 – “The method of claim 1, further comprising: transmitting a request for application information and configuration information as a function of the first set of wearable devices and the identified first type of user from the application and configuration recommendation engine” (see claim 1: "A method associated with a mobile device and a first set of a plurality of wearable devices” In the embodiment disclosed in which mobile device coordinates/provides connectivity between the wearable device and the recommendation engine, a request which originates from the wearable device would be received by the mobile device and passed to the recommendation engine.); and sending, to the wearable device, the suggested value for the setting ([0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0043] – “The recommendation process 240 includes providing the determined optimal configuration in response to the request (step 248). The recommendation engine 100 can provide the determined optimal configuration over the WAN 140 and through the links 130, 132, 135. The recommendation process 240 includes manually and/or automatically configuring the set of wearable devices 120 with the determined optimal configuration (step 250). Here, the wearable devices 120 are automatically configured based on the determined optimal configuration and/or the determined optimal configuration is presented to the user 110, 112, 115 for manual configuration.”; Claim 4 – “receiving the recommended application information and configuration information from the application and configuration recommendation engine”. Again, in the embodiment disclosed in which mobile device coordinates/provides connectivity between the wearable device and the recommendation engine, a response comprising the recommended configuration which originates from the recommendation engine would be received by the mobile device and passed to/implemented on the wearable device.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of claim 12 of the reference application such that the client device receives a request for a suggested value of a setting from the wearable device and sends the suggested value to the wearable device as taught by KREITZER. Incorporating the teachings of KREITZER would allow for optimal application settings to be applied on the wearable device, where the optimal settings are determined based on analysis of data of a plurality of users (see KREITZER: [0003], [0020], and [0026]-[0027]).
Additionally, it would have been obvious to one of ordinary skill in the art to have applied the limitations of the methods of claims 7 and 12 of the reference patent to the apparatuses of claims 9 and 15 of the instant application.
Table 1: Claim comparison of the instant application with U.S. Patent No.12,086,661 B2
Claim
18/810,020 (instant application)
U.S. Patent No. 12,086,661 B2
1
An apparatus of a wearable device, the apparatus comprising:
at least one processor; and
at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations comprising:
receiving, from a client device, a first remote procedure call (RPC), the RPC indicating a request to provide setting names and setting values for a plurality of categories of settings;
retrieving the setting names and the setting values for the plurality of categories of settings;
sending, to the client device, a second RPC, the second RPC indicating the setting names and the setting values for the plurality of categories of settings; and
receiving
from the client device, a
third RPC, the third RPC indicating setting names and setting values for a category of settings of the plurality of categories for settings, wherein the third RPC further indicates that the wearable device is to set settings indicated by the setting names with values indicated by the setting values for the category of settings.
From claim 1: A method performed on an augmented reality (AR) wearable device, the method comprising:
receiving, from a client device, a first remote procedure call (RPC), the RPC indicating a request to provide setting names and setting values for a plurality of categories of settings;
retrieving the setting names and the setting values for the plurality of categories of settings;
sending, to the client device, a second RPC, the second RPC indicating the setting names and the setting values for the plurality of categories of settings;
receiving a changed setting value of the setting values via a user interface of the AR wearable device;
setting an indication associated with the setting value that the setting value has changed;
receiving, a third RPC from the client device, the third RPC indicating a request for all setting values that have changed; and
sending a fourth RPC to the client device, the fourth RPC indicating the changed setting value.
See claim 7: The method of claim 1 further comprising:
receiving, by a first processor of the AR wearable device, from the client device, a third RPC, the third RPC indicating setting names and setting values for a category of settings of the plurality of categories for settings, wherein the third RPC further indicates that the AR wearable device is to set settings indicated by the setting names with values indicated by the setting values for the category of settings.
2
The apparatus of claim 1, wherein the wearable device is one of: an extended reality (XR) wearable device, augmented reality (AR) wearable device, or virtual reality (VR) wearable device.
See claim 1: “A method performed on an augmented reality (AR) wearable device”
3
The apparatus of claim 1, wherein the operations further comprise: receiving a changed setting value of the setting values via a user interface of the wearable device; and setting an indication associated with the setting value that the setting value has changed.
See claim 1: “receiving a changed setting value of the setting values via a user interface of the AR wearable device;
setting an indication associated with the setting value that the setting value has changed;”
4
The apparatus of claim 3, wherein the operations further comprise: receiving, a fourth RPC from the client device, the fourth RPC indicating a request for all setting values that have changed; and sending a fifth RPC to the client device, the fifth RPC indicating the changed setting value.
See claim 1: “receiving, a third RPC from the client device, the third RPC indicating a request for all setting values that have changed; and
sending a fourth RPC to the client device, the fourth RPC indicating the changed setting value.”
5
The apparatus of claim 1, wherein the operations further comprise: associating, using a lower energy communication protocol, with the client device, and
wherein the receiving and the sending are both via the lower energy communication protocol.
See claim 7
6
The apparatus of claim 1, wherein the operations further comprise: receiving, by a first processor of the wearable device, the first RPC; and sending the first RPC to a service manager on a second processor of the wearable device to retrieve the setting names.
From claim 1: “receiving, from a client device, a first remote procedure call (RPC), the RPC indicating a request to provide setting names and setting values for a plurality of categories of settings; retrieving the setting names and the setting values for the plurality of categories of settings”
From claim 7: “receiving, by a first processor of the AR wearable device, a third RPC”
See claim 8: The method of claim 7 further comprising:
sending the third RPC to a service manager on a second processor of the AR wearable device; and
setting, by the service manager, settings indicated by the setting names with values indicated by the setting values for the category of settings.
9
The apparatus of claim 1, wherein the operations further comprise: sending, to an application server, a request for a suggested value for a setting; and receiving, from the application server, the suggested value for the setting.
See claim 7
10
An apparatus of a client device, the apparatus comprising:
at least one processor; and
at least one memory storing instructions that, when executed by the at least one processor cause the at least one processor to perform operations comprising:
sending, to a wearable device, a first remote procedure call (RPC), the first RPC indicating a request to provide setting names and setting values for a category of settings of a plurality of categories of settings;
receiving, from the wearable device, the setting names and the setting values for the category of settings of the plurality of categories of settings;
displaying on a display of the client device the setting names and the setting values for the category of settings; and
responsive to receiving a change to one or more setting values of the setting values, sending a second RPC to the wearable device, the second RPC indicating the change to the one or more setting values.
See claim 12: A method performed on a client device, the method comprising:
sending, to an augmented reality (AR) wearable device, a first remote procedure call (RPC), the first RPC indicating a request to provide setting names and setting values for a category of settings of a plurality of categories of settings;
receiving, from the AR wearable device, the setting names and the setting values for the category of settings of the plurality of categories of settings;
displaying on a display of the client device the setting names and the setting values for the category of settings; and
responsive to receiving a change to one or more setting values of the setting values, sending a second RPC to the AR wearable device, the second RPC indicating the change to the one or more setting values;
sending, a third RPC to the AR wearable device, the third RPC indicating a request for all setting values that have changed; and
receiving a fourth RPC from the AR wearable device, the fourth RPC indicating the changed setting value.
11
The client device of claim 10, wherein the operations further comprise:
sending, a third RPC to the wearable device, the third RPC indicating a request for all setting values that have changed; and
receiving a fourth RPC from the wearable device, the fourth RPC indicating the changed setting value.
See claim 12:
“sending, a third RPC to the AR wearable device, the third RPC indicating a request for all setting values that have changed; and
receiving a fourth RPC from the AR wearable device, the fourth RPC indicating the changed setting value.”
12
The client device of claim 10, wherein the category of settings is a first category of settings and wherein the operations further comprise:
receiving, from the wearable device, a third RPC, the third RPC indicating a request by the wearable device for setting values for a second category of settings of a plurality of categories of settings; and
sending, to the wearable device, a fourth RPC, the fourth RPC indicating the setting values for the second category of settings.
See claim 13: The method of claim 12 wherein the category of settings is a first category of settings and wherein the method further comprises:
receiving, from the AR wearable device, a third RPC, the third RPC indicating a request by the AR wearable device for setting values for a second category of settings of a plurality of categories of settings; and
sending, to the AR wearable device, a fourth RPC, the fourth RPC indicating the setting values for the second category of settings.
13
The client device of claim 10, wherein the wearable device is one of: an extended reality (XR) wearable device, augmented reality (AR) wearable device, or virtual reality (VR) wearable device.
See claim 12: “an augmented reality (AR) wearable device”
14
The client device of claim 10, wherein the operations further comprise: associating, using a lower energy communication protocol, with the client device, and wherein the receiving and the sending are both via the lower energy communication protocol.
See claim 14: The method of claim 12 further comprising: associating, using an energy-conserving communication protocol, with the AR wearable device, and wherein the receiving is via the communication protocol.
15
The client device of claim 10, wherein the operations further comprise: receiving, from the wearable device, a request for a suggested value for a setting; and sending, to the wearable device, the suggested value for the setting.
See claim 12
16
A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor of an apparatus of a wearable device, cause the at least one processor to perform operations comprising:
receiving, from a client device, a first remote procedure call (RPC), the RPC indicating a request to provide setting names and setting values for a plurality of categories of settings;
retrieving the setting names and the setting values for the plurality of categories of settings;
sending, to the client device, a second RPC, the second RPC indicating the setting names and the setting values for the plurality of categories of settings; and
receiving
from the client device, a
third RPC, the third RPC indicating setting names and setting values for a category of settings of the plurality of categories for settings, wherein the third RPC further indicates that the wearable device is to set settings indicated by the setting names with values indicated by the setting values for the category of settings.
From claim 1: A method performed on an augmented reality (AR) wearable device, the method comprising:
receiving, from a client device, a first remote procedure call (RPC), the RPC indicating a request to provide setting names and setting values for a plurality of categories of settings;
retrieving the setting names and the setting values for the plurality of categories of settings;
sending, to the client device, a second RPC, the second RPC indicating the setting names and the setting values for the plurality of categories of settings;
receiving a changed setting value of the setting values via a user interface of the AR wearable device;
setting an indication associated with the setting value that the setting value has changed;
receiving, a third RPC from the client device, the third RPC indicating a request for all setting values that have changed; and
sending a fourth RPC to the client device, the fourth RPC indicating the changed setting value.
See claim 7: The method of claim 1 further comprising:
receiving, by a first processor of the AR wearable device, from the client device, a third RPC, the third RPC indicating setting names and setting values for a category of settings of the plurality of categories for settings, wherein the third RPC further indicates that the AR wearable device is to set settings indicated by the setting names with values indicated by the setting values for the category of settings.
17
The non-transitory computer-readable storage medium of claim 16, wherein the wearable device is one of: an extended reality (XR) wearable device, augmented reality (AR) wearable device, or virtual reality (VR) wearable device.
See claim 1: “A method performed on an augmented reality (AR) wearable device”
18
The non-transitory computer-readable storage medium of claim 16, wherein the operations further comprise: receiving a changed setting value of the setting values via a user interface of the wearable device; and setting an indication associated with the setting value that the setting value has changed.
See claim 1: “receiving a changed setting value of the setting values via a user interface of the AR wearable device;
setting an indication associated with the setting value that the setting value has changed;”
19
The non-transitory computer-readable storage medium of claim 18, wherein the operations further comprise: receiving, a fourth RPC from the client device, the fourth RPC indicating a request for all setting values that have changed; and sending a fifth RPC to the client device, the fifth RPC indicating the changed setting value.
See claim 1: “receiving, a third RPC from the client device, the third RPC indicating a request for all setting values that have changed; and
sending a fourth RPC to the client device, the fourth RPC indicating the changed setting value.”
20
The non-transitory computer-readable storage medium of claim 16, wherein the operations further comprise:
associating, using a lower energy communication protocol, with the client device, and wherein the receiving and the sending are both via the lower energy communication protocol.
See claim 7
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3, 5-6, 10, 12, 14, 16, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Walsh et al. (U.S. Pub. No. 2007/0049198), hereinafter Walsh, in view of Goodine et al. (U.S. Pub. No. 2020/0112828), hereinafter Goodine, and Vlachogiannis et al. (U.S. Pub. No. 2020/0169620), hereinafter Vlachogiannis.
Regarding claim 1, Walsh teaches An apparatus of a wearable device (FIGS. 1 and 3, headset 12), the apparatus comprising:
at least one processor ([0025] – “Headset 12 includes a headset controller 44 such as a microprocessor”); and
at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations ([0025] – “and a memory 42 executing software such as settings server application 43 to implement functionality as described herein.”) comprising:
receiving, from a client device (FIG. 1, client 2; [0015] – “Client 2 is a computing device such as a personal computer and may operate on a variety of hardware and software platforms.”), a first [communication], the [communication] indicating a request to provide setting names and setting values for a plurality of […] settings ([0019] – “Upon a request generated by a user at a client 2, web pages are transferred to the client 2”; [0027] – “Headset hardware 60 executes C++ platform 66 in one example of the invention. Settings server application 43 is a C++ application that manages and controls the resources of headset 12 to receive and process requests associated with headset settings from client devices.”; [0028] – “A user interfaces with a client 2 through a software application to indicate a request to view or change the headset user settings. The request is converted into a data packet using the TCP/IP protocol and is transmitted, over the Internet 10, to the headset 12.”);
retrieving the setting names and the setting values for the plurality of […] settings ([0019] – “Upon a request generated by a user at a client 2, web pages are transferred to the client 2”; [0027] – “settings server application 43 transmits web pages to a browser on a client device which allow the client device user to view and modify current values for user modifiable settings.”; [0030] – “Memory 42 also stores data for use by controller 44, including program data and the current settings of headset 12.”; FIGS. 5A, 5B and [0033] – web pages sent to the client to view current values for settings include names of settings, e.g., “Ring Tone”, and values of the settings, e.g. “Ring Tone A”; [0035] – "At block 104, the headset server transmits user modifiable settings web pages to the client device. In particular, user interface menus can be displayed on a web browser”);
sending, to the client device, a second [communication], the second [communication] indicating the setting names and the setting values for the plurality of […] settings ([0019] – “Upon a request generated by a user at a client 2, web pages are transferred to the client 2”; [0027] – “settings server application 43 transmits web pages to a browser on a client device which allow the client device user to view and modify current values for user modifiable settings.”; [0035] – "At block 104, the headset server transmits user modifiable settings web pages to the client device. In particular, user interface menus can be displayed on a web browser”); and
receiving from the client device, a third [communication], the third [communication] indicating setting names and setting values for […] settings of the plurality of […] settings, wherein the third [communication] further indicates that the wearable device is to set settings indicated by the setting names with values indicated by the setting values for the […] settings ([0035]-[0036] – “At step 106, the user enters one or more new settings using the client device. At step 108, new settings entered by the user are transmitted to the headset server. At step 110, new settings transmitted by the client device are received by the headset server. At step 112, the modified user settings of the headset server are implemented”).
Walsh fails to expressly teach each communication between the wearable and client device is a remote procedure call (RPC) and fails to teach the settings comprising a plurality of categories of settings, wherein the wearable device is to receive and set settings for a category of settings of the plurality of categories for settings.
However, Goodine teaches each communication between the wearable and client device is a remote procedure call (RPC) (FIG. 7, wearable device 710 and host computing device 740; [0148] – “software programs executed by wearable computing device 710 that desire data communications (e.g., with remote computing device 180) may create data packets using a specialized communications library, also called a companion service library, which allows for initial transmission of data via the personal area network interface to the host computing device 740; the host computing device 740 can receive these data transmissions and, using the companion service library, re-transmit them to the network on behalf of the wearable computing device 710. Likewise, host computing device 740 can receive transmissions from the network for delivery to wearable computing device 710.”; [0153]-[0154] – “host routing service 755 may implement a host data communications endpoint by calling functions from the companion service library to handle data routing to or from the host device. As noted above, a corresponding companion service library may also be used by the client data communications endpoint in application 724 or proxy service 726. A data routing service 730 of wearable computing device 710 may also make use of the companion service library. Generally, the companion service library may have related server and client libraries.”; [0156]-[0157] – “The server library may have a set of APIs, functions and callbacks that can be used to provide a server thread to autonomously manage the connection lifecycle and communications between the various applications or proxy servers that implement client data communication endpoints, and the data routing service 730, which integrates with the server library. The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients. The callbacks and callouts allow the data routing service 730 to frame RPC requests and socket data when sending it to the host computing device 740, and de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the companion service library functions. In the case of data routing service 730, the server library API functions may be used to frame or de-frame client RPC calls using a protocol buffer messaging protocol, which can be common to both the wearable computing device 710 and host computing device 740.”; Fig. 18 and [0334]-[0340] – the communications between the host computing device and wearable computing device may be used for configuring/updating settings from the wearable device at the host computing device).
Walsh and Goodine are considered to be analogous art to the claimed invention because they are in the same field of remotely managing settings of a wearable device. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Walsh such that the communications between the wearable device and client device are remote procedure calls as taught by Goodine. Incorporating the libraries which implement remote procedure calls as taught by Goodine would enable abstraction of networking functions needed for communication between the client device and wearable device from the applications executing on the devices and simplify communication (see Goodine: [0155] and [0129]).
The combination of Walsh in view of Goodine fails to expressly teach the settings comprising a plurality of categories of settings, wherein the wearable device is to receive and set settings for a category of settings of the plurality of categories for settings.
However, Vlachogiannis teaches the settings comprising a plurality of categories of settings, wherein the wearable device is to receive and set settings for a category of settings of the plurality of categories for settings ([0025] – “Managed devices 102a and 102b through 102n and administrator devices 104a through 102n can also be referred to as client-side devices […] A client-side device might take on a variety of forms, such as a personal computer (PC), a laptop computer, a mobile phone, a smartphone, a smartwatch, a tablet computer, a wearable computer”; [0031] – “Each managed device, such as managed devices 102a and 102b through 102n can include one or more sets of localized remote settings. […] Each instance of application 110a can have the same set and/or sets of localized remote settings or one to all of the set or sets can be different with respect to different application instances. Sets of localized remote settings can be provided to the managed devices by remote settings service 106.”; [0033] – “A setting may also be referred to as a configuration instruction, which can be defined by one or more key-value pairs. Values can correspond to configurations for an application, and the application can have routines and/or functions that determine how to apply those values to the application based on identifying one or more keys in the setting.”; [0045] – “Remote settings service 106 can be employed for receiving, providing, updating, and/or modifying at least one localized remote setting for at least one application on a managed device at any time.”; [0048] – “one or more remote settings may be provided to a managed device based on receiving a modification to reference remote settings from an administrator”; [0052] – “the administrator can provide any combination of configuration instructions 248 (e.g. values for settings) and settings definitions 250 (e.g. keys for settings) as inputs to remote settings service 206 via administrator interface 242. […] For example, one or more current settings of the reference settings could be presented with options or other means to modify the settings.”; [0060] – “one set of reference remote settings may be for application 110a, and another set of reference remote settings may be for application 110b.”; [0071] – “the information could comprise an application identifier, such as application identifier 364, […] an identifier that can be utilized to identify an application amongst a plurality of applications.”; [0078] – “The encoded payload data can comprise key-value pairs. In some cases, decoding of the encoded payload data includes parsing and/or otherwise analyzing and processing the key-value pairs. The encoded payload data can correspond to an encoded data object. Examples include a JavaScript Object Notification (JSON) encoded object”; [0082] – “Reference remote settings 252 correspond to application 110a, for example, based upon being assigned to application identifier 364 by an administrator.”; [0088]-[0089] – “At block 580, method 500 includes receiving, at a managed device, reference remote settings from a remote settings service, the reference remote settings corresponding to an application on the managed device […] Reference remote settings 252 in network communication 244b can correspond to an encoded data object, such as a JSON encoded object. Furthermore, reference remote settings 252 can correspond to application 110a, which could optionally be indicated by an application identifier being included in network communication 244a. At block 582, method 500 includes applying at least some of the reference remote settings to the application. For example, managed device 102a can apply at least some of the reference remote settings to application 110a.”)
For clarity of the record, the Examiner would like to point to paragraph [20] of the Specification of the instant application which teaches “each application may be its own category 628 or the applications may be grouped into categories 628”. Thus, the different sets of settings, each of which correspond to different applications or versions of an application, as taught by Vlachogiannis are considered analogous to the recited categories of settings.).
Vlachogiannis is considered to be analogous art to the claimed invention because it is in the same field of remotely managing settings of a wearable device. 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 teachings of Walsh in view of Goodine such that the settings are organized into and managed as a plurality of categories settings, and such that settings for a category of the plurality of categories of settings may be received and set as taught by Vlachogiannis. Organizing the remotely configurable settings into different sets (“categories”) corresponding to different applications/instances of an application enables targeting applications on specific devices and/or corresponding to specific users for different settings (see Vlachogiannis: [0013], [0041], and [0072]). Further, incorporating the methods of Vlachogiannis would provide for faster remote management of settings with minimal impact on the operation of the devices (see Vlachogiannis: [0003] and [0020]).
Regarding claim 3, the combination of Walsh in view of Goodine and Vlachogiannis teaches The apparatus of claim 1. Walsh further teaches wherein the operations further comprise: receiving a changed setting value of the setting values via a user interface of the wearable device (user interface 38 on headset 12; [0020] – “The user interface 38 may include a multifunction power, volume, mute, and select button or buttons. Other user interfaces may be included on the headset, such as a link active/end interface 40. The button depressions are detected by a headset controller, which then initiates modifications corresponding to the particular button that was pressed.”; [0024] – “The user interface 38 is used to modify operational settings of the headset for purposes including directly accessing configuration settings, turning the power off and on, adjusting the volume of sound emitted by the headset etc.”; [0025] – “The headset controller 44 receives input from headset user interface 38 via an input decoder”; [0029] – “the controller 44 is connected to the user interface 38. The controller 44 monitors the activity of the headset 12 and detects the occurrence of an action by a user via user interface 38”); and setting an indication associated with the setting value that the setting value has changed ([0020] – “button depressions are detected by a headset controller, which then initiates modifications corresponding to the particular button that was pressed”; [0029] – “The controller 44 monitors the activity of the headset 12 and detects the occurrence of an action by a user via user interface 38 and responsively changes the desired setting.”; [0030] – “Memory 42 also stores data for use by controller 44, including program data and the current settings of headset 12.”).
Regarding claim 5, the combination of Walsh in view of Goodine and Vlachogiannis teaches The apparatus of claim 1. Goodine further teaches wherein the operations further comprise: associating, using a lower energy communication protocol, with the client device, and wherein the receiving and the sending are both via the lower energy communication protocol ([0148] – “Since wearable computing device 710 is equipped with only a personal area network interface, software programs executed by wearable computing device 710 that desire data communications (e.g., with remote computing device 180) may create data packets using a specialized communications library, also called a companion service library, which allows for initial transmission of data via the personal area network interface to the host computing device 740; the host computing device 740 can receive these data transmissions and, using the companion service library, re-transmit them to the network on behalf of the wearable computing device 710. Likewise, host computing device 740 can receive transmissions from the network for delivery to wearable computing device 710.”; [0158] – “host personal area network service 750 may communicate with a personal area network service 735 of wearable computing device 710 via a general personal area network (e.g., Bluetooth™) or over a low-power personal area network (e.g., Bluetooth™ LE)”; [0209] – “the host computing device may listen for low power personal area network (e.g., Bluetooth LE) advertising packets from the wearable computing device, and establish an outbound low power personal area network connection to the wearable computing device in response.”).
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 teachings of Walsh such that the wearable device and client device associate using a lower energy communication protocol as taught by Goodine. Using a lower energy communication protocol would reduce energy and data usage (see Goodine: [0063]).
Regarding claim 6, the combination of Walsh in view of Goodine and Vlachogiannis teaches The apparatus of claim 1. Walsh further teaches wherein the operations further comprise: receiving, by a first processor of the wearable device ([0025] – the controller within the wireless communication module 31, where a controller may be a microprocessor as discussed with respect to headset controller 44), the first [communication] ([0025] – “Headset 12 includes a headset controller 44 such as a microprocessor […] wireless communication module 31 to transmit and receive signals between the headset 12 and a client device […] the wireless communication module 31 may include a controller which controls one or more operations of the headset 12.”; [0019] – “Upon a request generated by a user at a client 2, web pages are transferred to the client 2”; [0027] – “Headset hardware 60 executes C++ platform 66 in one example of the invention. Settings server application 43 is a C++ application that manages and controls the resources of headset 12 to receive and process requests associated with headset settings from client devices.”; [0028] – “A user interfaces with a client 2 through a software application to indicate a request to view or change the headset user settings. The request is converted into a data packet using the TCP/IP protocol and is transmitted, over the Internet 10, to the headset 12.”);
[communication]; and
sending the first [communication] to a service manager on a second processor of the wearable device (FIG. 2; [0025] – headset controller 44; [0025] – “The headset controller 44 further interacts with wireless communication module 31 to transmit and receive signals between the headset 12 and a client device”) to retrieve the setting names ([0027] – “Settings server application 43 is a C++ application that manages and controls the resources of headset 12 to receive and process requests associated with headset settings from client devices. In an example of the invention, settings server application 43 transmits web pages to a browser on a client device which allow the client device user to view and modify current values for user modifiable settings.”; [0030] – “Memory 42 is used to store settings server application 43 and other programs which control the headset 12. The programs stored in the memory 42 are executed by the controller 44. […] Memory 42 also stores data for use by controller 44, including program data and the current settings of headset 12.” A settings server application 43 (i.e., “service manager”), stored in memory 42 and executed by headset controller 44 (i.e., “a second processor”) is used to process requests for current settings and provide web pages (comprising the current settings) to the client device. Memory 42 also stores the current settings for use, i.e., retrieval, by controller 44.).
Goodine further teaches each communication, e.g., the first communication, between the wearable and client device is a remote procedure call (RPC) (FIG. 7, wearable device 710 and host computing device 740; [0148] – “software programs executed by wearable computing device 710 that desire data communications (e.g., with remote computing device 180) may create data packets using a specialized communications library, also called a companion service library, which allows for initial transmission of data via the personal area network interface to the host computing device 740; the host computing device 740 can receive these data transmissions and, using the companion service library, re-transmit them to the network on behalf of the wearable computing device 710. Likewise, host computing device 740 can receive transmissions from the network for delivery to wearable computing device 710.”; [0153]-[0154] – “host routing service 755 may implement a host data communications endpoint by calling functions from the companion service library to handle data routing to or from the host device. As noted above, a corresponding companion service library may also be used by the client data communications endpoint in application 724 or proxy service 726. A data routing service 730 of wearable computing device 710 may also make use of the companion service library. Generally, the companion service library may have related server and client libraries.”; [0156]-[0157] – “The server library may have a set of APIs, functions and callbacks that can be used to provide a server thread to autonomously manage the connection lifecycle and communications between the various applications or proxy servers that implement client data communication endpoints, and the data routing service 730, which integrates with the server library. The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients. The callbacks and callouts allow the data routing service 730 to frame RPC requests and socket data when sending it to the host computing device 740, and de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the companion service library functions. In the case of data routing service 730, the server library API functions may be used to frame or de-frame client RPC calls using a protocol buffer messaging protocol, which can be common to both the wearable computing device 710 and host computing device 740.”; Fig. 18 and [0334]-[0340] – the communications between the host computing device and wearable computing device may be used for configuring/updating settings from the wearable device at the host computing device).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Walsh such that the communications between the wearable device and client device are remote procedure calls as taught by Goodine. Incorporating the libraries which implement remote procedure calls as taught by Goodine would enable abstraction of networking functions needed for communication between the client device and wearable device from the applications executing on the devices and simplify communication (see Goodine: [0155] and [0129]).
Regarding claim 10, Walsh teaches An apparatus of a client device (FIG. 1, client 2; [0015] – “Client 2 is a computing device such as a personal computer and may operate on a variety of hardware and software platforms. For example, client 2 may also be a Bluetooth enabled mobile handset, laptop computer”), […] to perform operations comprising:
sending, to a wearable device (FIGS. 1 and 3, headset 12), a first [communication], the first [communication] indicating a request to provide setting names and setting values for […] settings […] ([0019] – “Upon a request generated by a user at a client 2, web pages are transferred to the client 2”; [0027] – “Headset hardware 60 executes C++ platform 66 in one example of the invention. Settings server application 43 is a C++ application that manages and controls the resources of headset 12 to receive and process requests associated with headset settings from client devices.”; [0028] – “A user interfaces with a client 2 through a software application to indicate a request to view or change the headset user settings. The request is converted into a data packet using the TCP/IP protocol and is transmitted, over the Internet 10, to the headset 12.”);
receiving, from the wearable device, the setting names and the setting values for the […] settings […] ([0019] – “Upon a request generated by a user at a client 2, web pages are transferred to the client 2”; [0027] – “settings server application 43 transmits web pages to a browser on a client device which allow the client device user to view and modify current values for user modifiable settings.”; FIGS. 5A, 5B and [0033] – web pages sent to the client to view current values for settings include names of settings, e.g., “Ring Tone”, and values of the settings, e.g. “Ring Tone A”; [0035] – "At block 104, the headset server transmits user modifiable settings web pages to the client device. In particular, user interface menus can be displayed on a web browser”);
displaying on a display of the client device the setting names and the setting values for the […] settings ([0014] – “a wireless headset includes a server for providing web pages to a client device. The web pages displayed on the client present the user with current values for user modifiable settings and allow the user to change the settings as desired. One advantage of this arrangement is that the human-machine interface required to interact with the headset has now been made available at a client device. The client device provides for a display, thereby enabling a user to view and modify headset settings with increased ease.”; [0019] – “Upon a request generated by a user at a client 2, web pages are transferred to the client 2 through the Internet 10 using HTTP and TCP/IP protocols and displayed with the held of a standard web browser such as Internet Explorer, Mozilla, or other browser.”; FIGS. 5A, 5B and [0033] – web pages sent to the client to view current values for settings include names of settings, e.g., “Ring Tone”, and values of the settings, e.g. “Ring Tone A”; [0035] – “relevant information regarding the settings and operation of the headset can be visually conveyed to the user at a client device. At block 104, the headset server transmits user modifiable settings web pages to the client device. In particular, user interface menus can be displayed on a web browser, allowing a headset user to change headset settings using visual menus”); and
responsive to receiving a change to one or more setting values of the setting values, sending a second [communication] to the wearable device, the second [communication] indicating the change to the one or more setting values ([0033] – “Referring to FIG. 5A, a browser page 50 is shown allowing a user to modify the headset ring tone or download a new ring tone by making an appropriate selection using a radio button. […] Once the user selection is made, an "Update User Settings" button 52 enables the user to transmit the new settings to the headset server. Referring to FIG. 5B, a browser page 54 is shown allowing a user to modify the function of a headset user interface button to either be an increase function or a decrease function. Similarly, other headset settings may be modified using additional browser pages.”; [0035]-[0036] – “At step 106, the user enters one or more new settings using the client device. At step 108, new settings entered by the user are transmitted to the headset server. At step 110, new settings transmitted by the client device are received by the headset server. At step 112, the modified user settings of the headset server are implemented”).
Walsh fails to expressly teach the apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor cause the at least one processor to perform the claimed operations, fails to teach each communication between the wearable and client device is a remote procedure call (RPC), and fails to teach the settings being for a category of settings of a plurality of categories of settings.
However, Goodine teaches the apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor cause the at least one processor to perform operations ([0095] – “Host computing device 440 has a processor 405, which is communicatively coupled to a to a volatile memory 420, a non-volatile memory 425”; [0096] – “host computing device 440 is a mobile computing device, such as a smart phone or tablet device. […] In some embodiments, host computing device 440 may be a non-portable computing device, such as a personal computer”; [0099] – “Processor 405 is coupled, via a computer data bus (not shown), to volatile memory 420 and non-volatile memory 425. Non-volatile memory 425 stores computer programs (e.g., application programs, service programs, drivers, frameworks, etc.) consisting of computer-executable instructions, which may be loaded into volatile memory 420 for execution by processor 405 as needed. It will be understood by those skilled in the art that references herein to a computing device as carrying out a function or acting in a particular way imply that a processor (e.g., processor 405 of computing device 440) is executing instructions (e.g., a software program) stored in a memory”), and teaches each communication between the wearable and client device is a remote procedure call (RPC) (FIG. 7, wearable device 710 and host computing device 740; [0148] – “software programs executed by wearable computing device 710 that desire data communications (e.g., with remote computing device 180) may create data packets using a specialized communications library, also called a companion service library, which allows for initial transmission of data via the personal area network interface to the host computing device 740; the host computing device 740 can receive these data transmissions and, using the companion service library, re-transmit them to the network on behalf of the wearable computing device 710. Likewise, host computing device 740 can receive transmissions from the network for delivery to wearable computing device 710.”; [0153]-[0154] – “host routing service 755 may implement a host data communications endpoint by calling functions from the companion service library to handle data routing to or from the host device. As noted above, a corresponding companion service library may also be used by the client data communications endpoint in application 724 or proxy service 726. A data routing service 730 of wearable computing device 710 may also make use of the companion service library. Generally, the companion service library may have related server and client libraries.”; [0156]-[0157] – “The server library may have a set of APIs, functions and callbacks that can be used to provide a server thread to autonomously manage the connection lifecycle and communications between the various applications or proxy servers that implement client data communication endpoints, and the data routing service 730, which integrates with the server library. The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients. The callbacks and callouts allow the data routing service 730 to frame RPC requests and socket data when sending it to the host computing device 740, and de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the companion service library functions. In the case of data routing service 730, the server library API functions may be used to frame or de-frame client RPC calls using a protocol buffer messaging protocol, which can be common to both the wearable computing device 710 and host computing device 740.”; Fig. 18 and [0334]-[0340] – the communications between the host computing device and wearable computing device may be used for configuring/updating settings from the wearable device at the host computing device).
Walsh and Goodine are considered to be analogous art to the claimed invention because they are in the same field of remotely managing settings of a wearable device. As cited above, Walsh teaches the client device may comprise a personal computer which performs operations comprising communicating with (i.e., sending settings to and receiving settings from) a wearable device and displaying, on a display of the client device, the settings. Goodine similarly teaches the “host computing device” may be a personal computer, comprising a processor and memory storing instructions, which when executed by the processor, cause the host computing device to perform operations, and teaches the operations of the host computing device comprising communicating with (i.e., sending settings to and receiving settings from) a wearable device and displaying, on a display of the host computing device, the settings (see Goodine: [0095]-[0099] and [0334]-[0340]). Since the client device of Walsh and the host computing device of Goodine are each disclosed as a “personal computer” and are used to perform the same functions, one of ordinary skill in the art would recognize a simple substitution could be made such that the client device of Walsh is implemented by the host computing device of Goodine. Further, the structure of a personal computer, as is known in the art and evidenced by the teachings of Goodine, comprises a processor and memory storing instructions executable by the processor to cause the personal computer to perform operations. It would have been obvious to one of ordinary skill in the art to have modified the teachings of Walsh such that the communications between the wearable device and client device are remote procedure calls as taught by Goodine. Incorporating the libraries which implement remote procedure calls as taught by Goodine would enable abstraction of networking functions needed for communication between the client device and wearable device from the applications executing on the devices and simplify communication (see Goodine: [0155] and [0129]).
The combination of Walsh in view of Goodine fails to expressly teach the settings being for a category of settings of a plurality of categories of settings.
However, Vlachogiannis teaches settings for a category of settings of a plurality of categories of settings ([0025] – managed device 102 may be a wearable device; [0031] – “Each managed device, such as managed devices 102a and 102b through 102n can include one or more sets of localized remote settings. […] Each instance of application 110a can have the same set and/or sets of localized remote settings or one to all of the set or sets can be different with respect to different application instances. Sets of localized remote settings can be provided to the managed devices by remote settings service 106.”; [0033] – “A setting may also be referred to as a configuration instruction, which can be defined by one or more key-value pairs. Values can correspond to configurations for an application, and the application can have routines and/or functions that determine how to apply those values to the application based on identifying one or more keys in the setting.”; [0045] – “Remote settings service 106 can be employed for receiving, providing, updating, and/or modifying at least one localized remote setting for at least one application on a managed device at any time.”; [0048] – “one or more remote settings may be provided to a managed device based on receiving a modification to reference remote settings from an administrator”; [0052] – “the administrator can provide any combination of configuration instructions 248 (e.g. values for settings) and settings definitions 250 (e.g. keys for settings) as inputs to remote settings service 206 via administrator interface 242. […] For example, one or more current settings of the reference settings could be presented with options or other means to modify the settings.”; [0060] – “one set of reference remote settings may be for application 110a, and another set of reference remote settings may be for application 110b.”; [0071] – “the information could comprise an application identifier, such as application identifier 364, […] an identifier that can be utilized to identify an application amongst a plurality of applications.”; [0078] – “The encoded payload data can comprise key-value pairs. In some cases, decoding of the encoded payload data includes parsing and/or otherwise analyzing and processing the key-value pairs. The encoded payload data can correspond to an encoded data object. Examples include a JavaScript Object Notification (JSON) encoded object”; [0080] – “remote settings service 206 can receive network communication 344 from managed device 102a. Network communication 344 may have been sent or transmitted by managed device 102a as part of a startup routine from library 120. Network communication 344 can comprise client-side hash value 362, application identifier 364, communication type ID 366, and encoded payload data 368.”; [0082] – “Reference remote settings 252 correspond to application 110a, for example, based upon being assigned to application identifier 364 by an administrator.”; [0088]-[0089] – “At block 580, method 500 includes receiving, at a managed device, reference remote settings from a remote settings service, the reference remote settings corresponding to an application on the managed device […] Reference remote settings 252 in network communication 244b can correspond to an encoded data object, such as a JSON encoded object. Furthermore, reference remote settings 252 can correspond to application 110a, which could optionally be indicated by an application identifier being included in network communication 244a. At block 582, method 500 includes applying at least some of the reference remote settings to the application. For example, managed device 102a can apply at least some of the reference remote settings to application 110a.”)
For clarity of the record, the Examiner would like to point to paragraph [20] of the Specification of the instant application which teaches “each application may be its own category 628 or the applications may be grouped into categories 628”. Thus, the different sets of settings, each of which correspond to different applications or versions of an application, as taught by Vlachogiannis are considered analogous to the recited categories of settings.).
Vlachogiannis is considered to be analogous art to the claimed invention because it is in the same field of remotely managing settings of a wearable device. 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 teachings of Walsh in view of Goodine such that the settings are organized into and managed as a plurality of categories settings as taught by Vlachogiannis. Organizing the remotely configurable settings into different sets (“categories”) corresponding to different applications/instances of an application enables targeting applications on specific devices and/or corresponding to specific users for different settings (see Vlachogiannis: [0013], [0041], and [0072]). Further, incorporating the methods of Vlachogiannis would provide for faster remote management of settings with minimal impact on the operation of the devices (see Vlachogiannis: [0003] and [0020]).
Regarding claim 12, the combination of Walsh in view of Goodine and Vlachogiannis teaches The client device of claim 10. Goodine further teaches a third RPC and a fourth RPC between the client device and the wearable device (FIG. 7, wearable device 710 and host computing device 740; [0148] – “software programs executed by wearable computing device 710 that desire data communications (e.g., with remote computing device 180) may create data packets using a specialized communications library, also called a companion service library, which allows for initial transmission of data via the personal area network interface to the host computing device 740; the host computing device 740 can receive these data transmissions and, using the companion service library, re-transmit them to the network on behalf of the wearable computing device 710. Likewise, host computing device 740 can receive transmissions from the network for delivery to wearable computing device 710.”; [0153]-[0154] – “host routing service 755 may implement a host data communications endpoint by calling functions from the companion service library to handle data routing to or from the host device. As noted above, a corresponding companion service library may also be used by the client data communications endpoint in application 724 or proxy service 726. A data routing service 730 of wearable computing device 710 may also make use of the companion service library. Generally, the companion service library may have related server and client libraries.”; [0156]-[0157] – “The server library may have a set of APIs, functions and callbacks that can be used to provide a server thread to autonomously manage the connection lifecycle and communications between the various applications or proxy servers that implement client data communication endpoints, and the data routing service 730, which integrates with the server library. The API of the server library facilitates client remote procedure call (RPC) calls for TCP socket operations, as requested by the clients. The callbacks and callouts allow the data routing service 730 to frame RPC requests and socket data when sending it to the host computing device 740, and de-frame command responses and socket data coming from the host computing device 740 before returning it to the client application via the companion service library functions. In the case of data routing service 730, the server library API functions may be used to frame or de-frame client RPC calls using a protocol buffer messaging protocol, which can be common to both the wearable computing device 710 and host computing device 740.”; Fig. 18 and [0334]-[0340] – the communications between the host computing device and wearable computing device may be used for configuring/updating settings from the wearable device at the host computing device).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Walsh such that the communications between the wearable device and client device are remote procedure calls as taught by Goodine. Incorporating the libraries which implement remote procedure calls as taught by Goodine would enable abstraction of networking functions needed for communication between the client device and wearable device from the applications executing on the devices and simplify communication (see Goodine: [0155] and [0129]).
Vlachogiannis further teaches wherein the category of settings is a first category of settings ([0031] – “Each managed device, such as managed devices 102a and 102b through 102n can include one or more sets of localized remote settings.”; [0056] – “which reference remote settings and/or sets of reference remote settings are to be provided to an application and/or a managed device”; [0060] – “one set of reference remote settings may be for application 110a, and another set of reference remote settings may be for application 110b.”; [0071] – “An application identifier can correspond to an identifier that can be utilized to identify an application amongst a plurality of applications.”) and wherein the operations further comprise: receiving, from the wearable device ([0025] – a managed device may be a wearable computer), a third [communication], the third [communication] indicating a request by the wearable device for setting values for a second category of settings of a plurality of categories of settings ([0031], [0056], [0071] – there may be multiple (i.e., a “first” and “second”) applications/sets of settings corresponding to each application (i.e., “categories of settings”) on a managed (“wearable”) device, where the sets of settings are managed by a remote settings service; [0029] – remote settings service and administrator devices (used by an administrator, i.e., a client/user of the device) may be the same device (the “client device”); [0046] – “A request from a managed device can be made at any time and can be made by an application, such as application 110a, which may employ library 120 to make the request. Requests can follow any of a variety of protocols. In some instances, requests and responses to requests are made in accordance with HyperText Transfer Protocol (HTTP). For example, a request can be an HTTP POST request. As such, the request could comprise a uniform resource locator (URL) that includes header and payload data”; [0070]-[0071] – “As many different reference remote settings may be available to reference settings manager 236, information may be provided to reference settings manager 236 […] at least some of this information may be provided by the managed device, such as in the network communication that corresponds to the request. […] the information could comprise an application identifier, such as application identifier 364, such that the server-side hash value is utilized in the comparison based on the application identifier (e.g., the settings that correspond to the server-side hash value can be identified using the application identifier). As such, the aforementioned indexing could be by application identifiers . An application identifier can correspond to an identifier that can be utilized to identify an application amongst a plurality of applications.”); and sending, to the wearable device ([0025]), a fourth [communication], the fourth [communication] indicating the setting values for the second category of settings ([0046] – “remote settings service 106 can provide remote settings to a managed device responsive to a request from the managed device.”; [0077] – “sending of at least some reference remote settings to the managed device in a response to the request.”; [0084] – “sending at least some reference remote settings to the managed device, the at least some reference remote settings corresponding to an application on the managed device.”; [0033] – “the setting could include one or more key-value pairs”).
For clarity of the record, the Examiner would like to point to paragraph [20] of the Specification of the instant application which teaches “each application may be its own category 628 or the applications may be grouped into categories 628”. Thus, the different sets of settings, each of which correspond to different applications or versions of an application, as taught by Vlachogiannis are considered analogous to the recited categories of settings.).
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 teachings of Walsh in view of Goodine such that the settings are organized into and managed as a plurality of categories settings and incorporate the remote settings service from which the wearable device can request and receive settings of a category of settings as taught by Vlachogiannis. Organizing the remotely configurable settings into different sets (“categories”) corresponding to different applications/instances of an application enables targeting applications on specific devices and/or corresponding to specific users for different settings (see Vlachogiannis: [0013], [0041], and [0072]). Further, incorporating the methods of Vlachogiannis would provide for faster remote management of settings with minimal impact on the operation of the devices (see Vlachogiannis: [0003] and [0020]).
Regarding claim 14, the combination of Walsh in view of Goodine and Vlachogiannis teaches The client device of claim 10. Goodine further teaches wherein the operations further comprise: associating, using a lower energy communication protocol, with the client device, and wherein the receiving and the sending are both via the lower energy communication protocol ([0148] – “Since wearable computing device 710 is equipped with only a personal area network interface, software programs executed by wearable computing device 710 that desire data communications (e.g., with remote computing device 180) may create data packets using a specialized communications library, also called a companion service library, which allows for initial transmission of data via the personal area network interface to the host computing device 740; the host computing device 740 can receive these data transmissions and, using the companion service library, re-transmit them to the network on behalf of the wearable computing device 710. Likewise, host computing device 740 can receive transmissions from the network for delivery to wearable computing device 710.”; [0158] – “host personal area network service 750 may communicate with a personal area network service 735 of wearable computing device 710 via a general personal area network (e.g., Bluetooth™) or over a low-power personal area network (e.g., Bluetooth™ LE)”; [0209] – “the host computing device may listen for low power personal area network (e.g., Bluetooth LE) advertising packets from the wearable computing device, and establish an outbound low power personal area network connection to the wearable computing device in response.”).
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 teachings of Walsh such that the wearable device and client device associate using a lower energy communication protocol as taught by Goodine. Using a lower energy communication protocol would reduce energy and data usage (see Goodine: [0063]).
Regarding claim 16, Walsh teaches A non-transitory computer-readable storage medium storing instructions that, when executed by at least one processor of an apparatus of a wearable device, cause the at least one processor to perform operations ([0012] – “The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital video discs)”; [0025] – “Headset 12 includes a headset controller 44 such as a microprocessor and a memory 42 executing software”; [0030] – “Memory 42 is used to store settings server application 43 and other programs which control the headset 12. The programs stored in the memory 42 are executed by the controller 44. Methods that are carried out by programs stored in the memory 44 are described below with reference to FIGS. 6A and 6B. The memory 42 is a form of computer readable media.” Claim 10 – “A computer readable storage medium storing instructions that when executed by a computer cause the computer to perform a method for modifying headset settings”) comprising: the active functions performed by the apparatus of a wearable device of claim 1.
Accordingly, claim 16 is rejected as being unpatentable over Walsh in view of Goodine and Vlachogiannis for the same reasons presented with respect to claim 1.
Regarding claim 18, the combination of Walsh in view Goodine and Vlachogiannis teaches The non-transitory computer-readable storage medium of claim 16. Claim 18 recites substantially the same additional limitations as claim 3. Accordingly, claim 18 is rejected as being unpatentable over Walsh in view Goodine and Vlachogiannis for the same reasons presented with respect to claim 3.
Regarding claim 20, the combination of Walsh in view Goodine and Vlachogiannis teaches The non-transitory computer-readable storage medium of claim 16. Claim 20 recites substantially the same additional limitations as claim 5. Accordingly, claim 20 is rejected as being unpatentable over Walsh in view Goodine and Vlachogiannis for the same reasons presented with respect to claim 5.
Claims 2, 13 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Walsh in view of Goodine and Vlachogiannis as applied to claims 1, 10 and 16 above, and further in view of Munoz et al. (U.S. Pub. No. 2021/0006921), hereinafter Munoz.
Regarding claim 2, the combination of Walsh in view of Goodine and Vlachogiannis teaches The apparatus of claim 1, but fails to expressly teach wherein the wearable device is one of: an extended reality (XR) wearable device, augmented reality (AR) wearable device, or virtual reality (VR) wearable device.
However, Munoz teaches wherein the wearable device is one of: an extended reality (XR) wearable device, augmented reality (AR) wearable device, or virtual reality (VR) wearable device ([0195] – “the wearable device 602 may represent an XR device (e.g., such as the VR device(s) 204 described herein, an AR headset, an MR headset, or any other type of XR headset). Augmented Reality “AR” may refer to computer rendered image or data that is overlaid over the real world where the user is actually located. Mixed Reality “MR” may refer to computer rendered image or data that is world locked to a particular location in the real world, or may refer to a variant on VR in which part computer rendered 3D elements and part photographed real elements are combined into an immersive experience that simulates the user's physical presence in the environment. Extended Reality “XR” may represent a catchall term for VR, AR, and MR.”).
Munoz is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of changing settings of a wearable device. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the wearable device taught by Walsh in view of Goodine and Vlachogiannis such that it is one of an XR, AR or VR wearable device as taught by Munoz. Using an extended, augmented or virtual reality wearable device would provide the benefit of allowing a user wearing the device to have an immersive or enhanced user experience, such as an immersive experience in playing a video game or in experiencing a live stream of a concert of sporting event (see Munoz: [0003] and [0104]).
Regarding claim 13, the combination of Walsh in view of Goodine and Vlachogiannis teaches The client device of claim 10. Claim 13 recites substantially the same additional limitations as claim 2. Accordingly, claim 13 is rejected as being unpatentable over Walsh in view Goodine and Vlachogiannis, and further in view of Munoz for the same reasons presented with respect to claim 2.
Regarding claim 17, the combination of Walsh in view Goodine and Vlachogiannis teaches The non-transitory computer-readable storage medium of claim 16. Claim 17 recites substantially the same additional limitations as claim 2. Accordingly, claim 17 is rejected as being unpatentable over Walsh in view Goodine and Vlachogiannis, and further in view of Munoz for the same reasons presented with respect to claim 2.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Walsh in view of Goodine and Vlachogiannis as applied to claim 1 above, and further in view of and further in view of Ballard et al. (U.S. Pub. No. 2015/0156803), hereinafter Ballard, and Roh et al. (U.S. Pub. No. 2020/0401213), hereinafter Roh.
Regarding claim 7, the combination of Walsh in view of Goodine and Vlachogiannis teaches The apparatus of claim 1, but fails to expressly teach wherein the plurality of categories of settings comprise: a camera service settings category, a lenses application settings category, an account service settings category, Boot Windows to Audit Mode (OOBE) service settings category, and default wearable device settings category.
However, Ballard teaches wherein the plurality of categories of settings comprise: a camera service settings category ([0120] and [0321] – the user can change settings associated with a camera on the AR device), a lenses application settings category ([0119], [0147] and [0158] – transparency or opaqueness of a rendered display on the lens is selectable by a user, i.e., a user can select settings of how computer-generated content (an “application”) appears on the lenses), an account service settings category ([0335]-[0336] – the user can set preferences for what profile information is public and is shared with others), […], and default wearable device settings category ([0112], [0140], and [0340] - discloses several settings that may be set to a default setting of the wearable AR device if the user does not configure the settings).
Ballard is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor in configuring settings for a wearable device. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the plurality of categories of settings from the wearable device taught by Walsh in view of Goodine and Vlachogiannis to include categories for the various types of settings taught by Ballard. Doing so would provide the advantages of allowing a user to control other devices (e.g., a camera) from the wearable device, to control how content is displayed on lenses of the wearable device (e.g., how transparent content is to allow a user to see their surroundings as well), to control what information is shared with other users and what content is secure from being accessed by unauthorized users, and would allow the wearable device to operate according to default settings when a user has not manually selected them (see Ballard: [0063]-[0065], [0144], [0147], [0321], and [0340]).
The combination of Walsh in view of Goodine, Vlachogiannis, and Ballard fails to expressly teach a Boot Windows to Audit Mode (OOBE) service settings category.
However, Roh teaches a Boot Windows to Audit Mode (OOBE) service settings category (Fig. 7, [0113] – electronic device displays an OOBE UI to allow the user to enter initial settings information).
Roh is considered to be analogous art because it is reasonably pertinent to configuring settings for a wearable augmented reality device since it discloses a method for configuring a user interface in a VR headset. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the plurality of categories of settings from the wearable device taught by Walsh in view of Goodine, Vlachogiannis, and Ballard to include a category comprising the OOBE settings taught by Roh. Including a category for OOBE settings would provide the advantage of allowing the user to configure pieces of initial information or initial settings needed for the electronic device to operate (see Roh: [0113]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Walsh in view of Goodine, Vlachogiannis, Ballard and Roh as applied to claim 7 above, and further in view of and further in view of Albadawi et al. (U.S. Pub. No. 2017/0294174), hereinafter Albadawi, Pinchon et al. (U.S. Patent No. 11,294,475), hereinafter Pinchon, and Jung et al. (U.S. Patent No. 11,093,199), hereinafter Jung.
Regarding claim 8, the combination of Walsh in view of Goodine, Vlachogiannis, Ballard, and Roh teaches The apparatus of claim 7, but fails to expressly teach wherein the default wearable device settings category comprises a display brightness setting, an input mode selection, and a timeout period selection.
However, Albadawi teaches wherein the default wearable device settings category comprises a display brightness setting (Abstract – “Computing devices and methods for controlling light output of a display are disclosed. In one example, a default brightness setting is set to an indoor light output level. […] the default brightness setting is updated to correspond to an outdoor light output level that is greater than the indoor light output level.”).
Albadawi is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor in configuring settings for a wearable device. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the default wearable device settings category taught by Walsh in view of Goodine, Vlachogiannis, Ballard, and Roh to include a display brightness setting as taught by Albadawi. Including the default wearable device display brightness setting taught by Albadawi would enable the display brightness to be configured to an appropriate level for use in one of a plurality of different lighting conditions, and may also allow energy to be conserved (see Albadawi: [0010]-[0015]).
The combination of Walsh in view of Goodine, Vlachogiannis, Ballard, Roh, and Albadawi fails to expressly teach an input mode selection, and a timeout period selection.
However, Pinchon teaches an input mode selection (Fig. 5 and Col. 4, lines 28-33 – shows a flow chart for the selection of an input mode in an artificial reality headset; Col. 12, lines 13-16 – eye gaze may be a default input mode).
Pinchon is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor in configuring settings of a wearable device. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the default settings category taught by Walsh in view of Goodine, Vlachogiannis, Ballard, Roh, and Albadawi to include an input mode selection as taught by Pinchon. Doing so would allow the user of wearable device to select an input mode in an artificial reality environment which provides the user with greater control over interactions with virtual objects (see Pinchon: Col. 4, lines 28-33).
The combination of Walsh in view of Goodine, Vlachogiannis, Ballard, Roh, Albadawi, and Pinchon fails to expressly teach a timeout period selection.
However, Jung teaches a timeout period selection (Fig. 8, Col. 1, lines 41-47 – setting a timeout for a display reduces battery consumption of an electronic device; Col. 19, lines 50-55 – the timeout period may be a predetermined time).
Jung is considered to be analogous art because it is reasonably pertinent to the problem faced by the inventor of configuring settings of wearable electronic devices (see Jung: Col. 8, lines 20-25). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the default settings category taught by Walsh in view of Goodine, Vlachogiannis, Ballard, Roh, Albadawi and Pinchon to include a timeout period selection as taught by Jung. Incorporating a setting for a timeout period would provide the benefit of reducing battery consumption of the wearable device (see Jung: Col. 1, lines 41-47).
Claims 9 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Walsh in view of Goodine and Vlachogiannis as applied to claims 1 and 10 above, and further in view of and further in view of KREITZER et al. (U.S. Pub. No. 2016/0080888), hereinafter KREITZER.
Regarding claim 9, the combination of Walsh in view of Goodine and Vlachogiannis teaches The apparatus of claim 1, but fails to expressly teach wherein the operations further comprise: sending, to an application server, a request for a suggested value for a setting; and receiving, from the application server, the suggested value for the setting.
However, KREITZER teaches sending, to an application server ([0045] – “the recommendation engine 100 is typically embodied by a cloud-based server”), a request for a suggested value for a setting ([0025] – “The wearable devices 120 can include the wearable devices 14-24 and the like, and the wearable devices 120 can form a PAN 125 with one another and the mobile device 12. Also, the users 110, 112, 115 can each have a mobile device 12. The users 110, 112, 115, via the associated mobile devices 12, have wireless links 130, 132, 135 to a WLAN/WAN 140, such as the Internet, for communication with the recommendation engine 100.”; [0028] – “Alternatively, the functionality associated with interacting with the recommendation engine 100 can be performed directly by the wearable devices 120 (e.g., either wirelessly if available, or when the wearable devices 120 are connected to a device that provides connectivity to the recommendation engine 100).”; [0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0034] – “The application can be configured to coordinate functionality between the wearable devices 120 and the recommendation engine 100. That is, the application can provide information sharing to the recommendation engine 100 from the users 110, 112, 115 and optimal applications and configurations for the wearable devices 120 from the recommendation engine 100. In an exemplary embodiment, the application can be implemented on the mobile device 12 such as a stand-alone application, a web browser plugin, or the like. In another exemplary embodiment, the application can be implemented on one or more of the wearable devices 120. A combination of these approaches is also contemplated.”; [0039] – “The recommendation process 240 includes receiving a request for a recommended configuration of a set of wearable devices for a user (step 242). Here, a specific user is requesting the optimal configuration. This can be done through the application, through a browser plugin, or based on manually inputting the wearable devices 120. […] the request can include the wearable devices 120 associated with the user.”; Claim 4 – “The method of claim 1, further comprising: transmitting a request for application information and configuration information as a function of the first set of wearable devices and the identified first type of user from the application and configuration recommendation engine” (see claim 1: "A method associated with a mobile device and a first set of a plurality of wearable devices”)); and receiving, from the application server ([0045]), the suggested value for the setting ([0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0043] – “The recommendation process 240 includes providing the determined optimal configuration in response to the request (step 248). The recommendation engine 100 can provide the determined optimal configuration over the WAN 140 and through the links 130, 132, 135. The recommendation process 240 includes manually and/or automatically configuring the set of wearable devices 120 with the determined optimal configuration (step 250). Here, the wearable devices 120 are automatically configured based on the determined optimal configuration and/or the determined optimal configuration is presented to the user 110, 112, 115 for manual configuration.”; Claim 4 – “receiving the recommended application information and configuration information from the application and configuration recommendation engine”).
KREITZER is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of configuring settings of a wearable device. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Walsh in view of Goodine and Vlachogiannis such that the wearable device sends a request for a suggested value of a setting to an application server and receives the suggested value from the application server as taught by KREITZER. Doing so would allow for optimal application settings to be applied on the wearable device, where the optimal settings are determined based on analysis of data of a plurality of users (see KREITZER: [0003], [0020], and [0026]-[0027]).
Regarding claim 15, the combination of Walsh in view of Goodine and Vlachogiannis teaches The client device of claim 10, but fails to teach wherein the operations further comprise: receiving, from the wearable device, a request for a suggested value for a setting; and sending, to the wearable device, the suggested value for the setting.
However, KREITZER teaches receiving, from the wearable device, a request for a suggested value for a setting ([0025] – “The wearable devices 120 can include the wearable devices 14-24 and the like, and the wearable devices 120 can form a PAN 125 with one another and the mobile device 12. Also, the users 110, 112, 115 can each have a mobile device 12. The users 110, 112, 115, via the associated mobile devices 12, have wireless links 130, 132, 135 to a WLAN/WAN 140, such as the Internet, for communication with the recommendation engine 100.”; [0028] – “in addition to the recommendation engine 100, a recommendation application can be operated on the mobile device 12 for interacting with the recommendation engine 100 and for performing various functions described herein with the PAN 125. Alternatively, the functionality associated with interacting with the recommendation engine 100 can be performed directly by the wearable devices 120 (e.g., either wirelessly if available, or when the wearable devices 120 are connected to a device that provides connectivity to the recommendation engine 100).”; [0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0034] – “The application can be configured to coordinate functionality between the wearable devices 120 and the recommendation engine 100. That is, the application can provide information sharing to the recommendation engine 100 from the users 110, 112, 115 and optimal applications and configurations for the wearable devices 120 from the recommendation engine 100. In an exemplary embodiment, the application can be implemented on the mobile device 12 such as a stand-alone application, a web browser plugin, or the like. In another exemplary embodiment, the application can be implemented on one or more of the wearable devices 120. A combination of these approaches is also contemplated.”; [0039] – “The recommendation process 240 includes receiving a request for a recommended configuration of a set of wearable devices for a user (step 242). Here, a specific user is requesting the optimal configuration. This can be done through the application, through a browser plugin, or based on manually inputting the wearable devices 120. […] the request can include the wearable devices 120 associated with the user.”; Claim 4 – “The method of claim 1, further comprising: transmitting a request for application information and configuration information as a function of the first set of wearable devices and the identified first type of user from the application and configuration recommendation engine” (see claim 1: "A method associated with a mobile device and a first set of a plurality of wearable devices” In the embodiment disclosed in which mobile device coordinates/provides connectivity between the wearable device and the recommendation engine, a request which originates from the wearable device would be received by the mobile device and passed to the recommendation engine.); and sending, to the wearable device, the suggested value for the setting ([0033] – “The configuration information can include, without limitation, which types of wearable devices are used, device settings, user customizable settings in the applications, etc.”; [0043] – “The recommendation process 240 includes providing the determined optimal configuration in response to the request (step 248). The recommendation engine 100 can provide the determined optimal configuration over the WAN 140 and through the links 130, 132, 135. The recommendation process 240 includes manually and/or automatically configuring the set of wearable devices 120 with the determined optimal configuration (step 250). Here, the wearable devices 120 are automatically configured based on the determined optimal configuration and/or the determined optimal configuration is presented to the user 110, 112, 115 for manual configuration.”; Claim 4 – “receiving the recommended application information and configuration information from the application and configuration recommendation engine”. Again, in the embodiment disclosed in which mobile device coordinates/provides connectivity between the wearable device and the recommendation engine, a response comprising the recommended configuration which originates from the recommendation engine would be received by the mobile device and passed to/implemented on the wearable device.).
KREITZER is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of configuring settings of a wearable device. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Walsh in view of Goodine and Vlachogiannis such that the client device receives a request for a suggested value of a setting from the wearable device and sends the suggested value to the wearable device as taught by KREITZER. Incorporating the teachings of KREITZER would allow for optimal application settings to be applied on the wearable device, where the optimal settings are determined based on analysis of data of a plurality of users (see KREITZER: [0003], [0020], and [0026]-[0027]).
Allowable Subject Matter
Claims 4, 11, and 19 would be allowable if rewritten to overcome the non-statutory double patenting rejections and any rejections under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Walsh et al. (U.S. Pub. No. 2007/0049198) teaches an interaction between a headset (i.e., “wearable device”) and a client, where a client requests current settings from the headset, a user modifies the settings through a user interface at the client, and the client sends the new settings to the headset (see FIGS. 6A-6B, [0019], [0027]-[0028] and [0034]-[0036]). Walsh further teaches a user interface of the headset through which a user can change settings (see [0024]). However, Walsh fails to teach the wearable device receiving a fourth RPC from the client device indicating a request for all setting values that have changed and the wearable device sending a fifth RPC indicating a changed setting value to the client device.
Goodine et al. (U.S. Pub. No. 2020/0112828) teaches an interaction between a wearable computing device and a host computing device (i.e., “client device”), where the host computing device requests settings from the wearable computing device, user input is received at the host computing device to update the settings, and the updated settings are sent to the wearable device (see FIG. 18 and [0334]-[0341]). However, Goodine further teaches communications between the host computing device and wearable computing device may be in the form of remote procedure calls (RPCs) (see FIG. 7, wearable device 710 and host computing device 740, [0148], [0153]-[0154] and [0156]-[0157]). Goodine fails to teach the wearable device receiving a request from the client device for all setting values that have changed and the wearable device sending a changed setting value, or indication thereof, to the client device.
Vlachogiannis et al. (U.S. Pub. No. 2020/0169620) teaches a managed device (e.g., a wearable device – see [0025]) sends a request to a remote settings service for remote settings of an application, where the remote settings may have been changed by an administrator and saved in the remote settings service as reference remote settings, where the request includes localized remote settings for the application that are already local to the managed device, and the remote settings service compares the localized remote settings to the reference remote settings and sends some or all of the reference remote settings if there is a difference (see [0014]-[0015], [0045]-[0046], [0048], [0069] and [0071]). However, Vlachogiannis fails to teach a wearable device receiving a fourth RPC from a client device indicating a request for all setting values that have changed and the wearable device sending a fifth RPC indicating a changed setting value to the client device.
Park et al. (U.S. Pub. No. 2015/0358201) teaches a wearable electronic device and a main electronic device may each synchronize its configuration setting value when the configuration setting values are different, e.g., when the wearable electronic device has a different configuration setting value from the main electronic device, it can synchronize its configuration setting value of the main electronic device. When a user manipulation is inputted to change a configuration setting, the wearable electronic device may transmit a signal to the main electronic device to change the configuration setting value at the main electronic device (see FIG. 2, [0042]-[0048]). However, Park fails to teach the wearable device receiving a fourth RPC from a client device indicating a request for all setting values that have changed and the wearable device sending a fifth RPC indicating a changed setting value to the client device.
There was no prior art found that teaches “receiving, a fourth RPC from the client device, the fourth RPC indicating a request for all setting values that have changed; and sending a fifth RPC to the client device, the fifth RPC indicating the changed setting value”. Therefore, this interaction between an AR wearable device and a client device, as applied to the wearable device, is considered to be allowable over the prior art in both claims 4 and 19.
Claim 11 recites similar limitations applied to a client device (“sending, a third RPC to the wearable device, the third RPC indicating a request for all setting values that have changed; and receiving a fourth RPC from the wearable device, the fourth RPC indicating the changed setting value”), and is allowed for the same reasons presented with respect to claims 4 and 19.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Park et al. (U.S. Pub. No. 2018/0218710) teaches an electronic device, such as a VR wearable device, may comprise a processor which comprises both an application processor, which processes functions that control the operations of the electronic device, and a separate communication processor, e.g., in a communication module (see [0049] and [0088]).
Graeb et al. (U.S. Patent No. 10,572,231) teaches grouping components that include of specify settings of a gameplay AR application, where such a grouping simplifies the view of an editor interface and simplifies the development process (see Col. 2, lines 1-16).
USMAN et al. (U.S. Pub. No. 2022/0401827) teaches a user device can provide a user with a plurality of pre-set device settings for a virtual reality headset, where the pre-set device settings include different experience modes that include individualized settings for one or more of volume settings, vibration settings, and display settings (see [0032] and [0038]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights