Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . See 35 U.S.C. § 100 (note).
Art Rejections
Anticipation
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1–13, 16–20, 22 and 23 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by US Patent Application Publication 2017/0230788 (published 10 August 2017) (“Simonides”)1.
Claim 1 is drawn to “a method performed by an accessory device for controlling a hearing device.” The following table illustrates the correspondence between the claimed method and the Simonides reference.
Claim 1
The Simonides Reference
“1. A method performed by an accessory device, the accessory device being configured to communicate with a hearing device,
The Simonides reference describes a mobile device 110, or accessory device, and associated method, to communicate with and control a hearing device 100. Simonides at ¶¶ 9, 10, 31, 36, FIG.1.
“the accessory device comprising an interface, a memory, a display, and a processor, the method comprising:
Mobile device 110 includes a user interface (i.e., input), a memory, a display and a processor. See id. at ¶¶ 48, 49, 51 (describing the use of device 110 to receive user input and store, process and display information).
“determining an environment parameter, wherein the environment parameter is based on position data, and
Simonides similarly describes determining an environment parameter, such as determining the location or type of location of mobile device 110 through GPS data. Id. at ¶¶ 9–14, 38–45, FIG.3. GPS is a type of wireless network that provides position data. (See Spec. at ¶ 24.)
“wherein the environment parameter is indicative of an environment type or a location type;
The processor of device 110 evaluates received GPS coordinates (i.e., position data) to determine the type of environment (i.e., environment parameter) the device is currently located at, such as being at a coffee shop. Id. at ¶ 12. The determination may be made with regard to a specific location (e.g., a specific coffee shop), or a type of location (e.g., a coffee shop in general). Id.
“determining a processing context parameter after the environment parameter is determined;
After determining the location of mobile device 110, the processor of device 110 uses the GPS-based location to select and adjust sound settings, corresponding to the claimed processing context parameter, for hearing device 100. Id. at ¶¶ 12, 45. For example, mobile device 110 sets and either manually or automatically adjusts hearing aid settings based on recommended settings or previously used settings corresponding to the current location identifier (i.e., scene tag), which is determined from the current GPS coordinates (i.e., environment parameter). Id. at ¶¶ 9–14, 41, 42, 45–54, FIGs.4, 5.
“obtaining a plurality of input signals,
The Simonides reference describes recording sound data in a location and adjusting hearing aid sound settings based on the recorded sound data. Id. at ¶¶ 9–13, 38–40, 46, 56.
“wherein the input signals are provisioned by the hearing device; and
Simonides also describes recording the sound data with microphones in either hearing device 100 or mobile device 110. Id. at ¶ 9. More particularly, Simonides describes implementing hearing device 100 as an ear-level device like the one described in the Michael reference, incorporated into Simonides. Id. at ¶¶ 4, 47. The ear-level device includes plural microphones and a Bluetooth module for communication with a mobile device. Michael at col. 4 l. 41 to col. 5 l. 34, FIG.2. Accordingly, Simonides and Michael describe recording sound data with microphones in an ear-level hearing device 100. See Simonides at ¶¶ 36–39; Michael at col. 4 l. 41 to col. 5 l. 34, FIG.2. The sound data would then be transmitted to and received/obtained by mobile device 110 (e.g., using a Bluetooth link) for processing, storing and uploading to a server. See Simonides at ¶¶ 9, 36–39.
“determining a scene tag based on the environment parameter and/or based on at least a part of the plurality of input signals;
Simonides describes receiving GPS coordinates and associating the coordinates with a specific location (e.g., a specific coffee shop) or a location type (e.g., a coffee shop, in general). Id. at ¶ 12. This essentially produces an environment parameter describing the type of environment device 110 is currently located in. Simonides further produces a scene tag from this environment parameter, where the scene tag is a human-readable piece of data that is displayed to the user on a display in order for the user to confirm the current location of device 110. Id. at ¶¶ 9, 41, 42, 47, 51, 52.
“wherein the environment parameter and the scene tag comprise non-audio data and
Simonides describes receiving GPS coordinates and processing the coordinate to determine the type of location that device 110 is currently located in. Id. at ¶¶ 12, 40. For example, device 110 determines that it is located at a coffee shop-type location. Id. Thus, device 100 produces a non-audio environment parameter.
Simonides further produces a human-readable label, or scene tag, that is displayed on a display. Id. at ¶¶ 9, 41, 42, 47, 51. The scene tag is not audio data, but textual/graphical data. Id.
“[the environment parameter and the scene tag] are different from each other2.”
Further, Simonides’s label and environment parameter are closely related, but are substantively different from each other as claimed due to their different purposes and manners of use. The environment parameter is a piece of data used by the machine to make an initial judgment about where the user and his device is located and the type of hearing parameters to use in processing audio. Id. at ¶¶ 12, 40. The label is data used to produce a visual/textual representation of the user’s location in order to facilitate a user confirming the current location. Id. at ¶¶ 41, 42. While both pieces of data carry information about the type of environment the user and device 110 are currently located in, they are used for different purposes (i.e., selecting appropriate hearing programs versus soliciting user feedback) and in different ways (i.e., internal logic versus user interface). See id. at ¶¶ 12, 40–42.
Table 1
For the foregoing reasons, the Simonides and Michael references anticipate all limitations of the claim.
Claim 2 depends on claim 1, and further requires the following:
“wherein the act of determining the processing context parameter comprises:
“determining whether the environment parameter satisfies one or more first criteria, and
“in accordance with the environment parameter satisfying the one or more first criteria, determining the processing context parameter corresponding to the environment parameter.”
Simonides describes determining whether the current location of mobile device 110 is in a location that has been previously visited and is associated with stored settings. See Simonides at ¶¶ 46, 54, FIG.5. If that is the case, mobile device 110 recalls the previous settings and presents the user an option to reuse those settings. See id. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 3 depends on claim 1, and further requires the following:
“wherein the processing context parameter comprises a noise cancellation scheme identifier, and/or a prioritization scheme identifier, and/or one or more output signal indicators indicative of one or more output signals to be transmitted to the hearing device.”
Simonides similarly describes adjusting noise cancellation settings for a particular location, such as choosing frequencies that will be filtered by noise cancellation in a particular location, and using those settings when a user reenters the location. Simonides at ¶¶ 47–49. Simonides also describes adjusting microphone directionality, to prioritize certain locations. Id. at ¶¶ 10, 47, 69. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 4 depends on claim 1, and further requires the following:
“further comprising associating the environment parameter with the scene tag.”
Simonides describes tracking a user’s location through GPS coordinate data collected by mobile device 110. Simonides at ¶¶ 9, 12, 38–42. As a user moves, the location will be updated. Id. The user’s new location is then associated with a label, or scene tag, for the new location. Id. The new location tag is displayed to the user for user confirmation. Id. at ¶¶ 9, 12, 38–42, 51, 52. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 5 depends on claim 1, and further requires the following:
“wherein the scene tag is determined based indirectly on the environment parameter.”
Simonides similarly describes a more generalized scene tag that is not tied to one particular location, but is more representative of a location environment parameter and sound level data and a personal physiological profile, processing context parameters, found in similar locations or shared by similar users. Simonides at ¶ 9, 13, 14. For example, Simonides describes tagging a scene as a coffee shop scene, rather than tagging the scene with a particular business identity. Id. at ¶¶ 12, 57. A narrowed range of possible sound settings are then displayed for a user to select. Id. at ¶ 13. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 6 depends on claim 5, and further requires the following:
“wherein the processing context parameter is determined based on the environment parameter, and
“wherein the scene tag is determined based on the processing context parameter.”
Simonides describes receiving GPS coordinates and associating the coordinates with a specific location (e.g., a specific coffee shop) or a location type (e.g., a coffee shop, in general). Id. at ¶ 12. This essentially produces an environment parameter describing the type of environment device 110 is currently located in. Simonides further produces a scene tag from this environment parameter, where the scene tag is a human-readable piece of data that is displayed to the user on a display in order for the user to confirm the current location of device 110. Id. at ¶¶ 9, 41, 42, 47, 51, 52. When the scene tag represents a general type of location, such as coffee shop or nightclub, the tag is determined based on a processing context since the Simonides reference groups location types by their acoustical similarity. See id. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 7 depends on claim 1, and further requires the following:
“further comprising displaying on the display a user interface object representative of the scene tag.”
Simonides similarly describes displaying a user interface object (e.g., a clickable pop-up notice) to inform the user of the current scene tag (e.g., a current location type). Simonides at ¶¶ 9, 12, 41, 42, 47, 51, 52. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 8 depends on claim 7, and further requires the following:
“wherein the user interface object representative of the scene tag is user-selectable.”
Simonides similarly describes displaying a user interface object (e.g., a clickable pop-up notice) to inform the user of the current scene tag (e.g., a current location type). Simonides at ¶¶ 9, 12, 41, 42, 47, 51, 52. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 9 depends on claim 7, and further requires the following:
“further comprising: detecting a user input selecting the user interface object representative of a scene tag; and
“after the user input is detected, retrieving the processing context parameter corresponding to the scene tag, and transmitting the processing context parameter via the interface of the accessory device to the hearing device.”
Simonides describes displaying a GUI on mobile device 110 so that a user may manually alter the location-based settings. Simonides ¶¶ 47, 48. After selecting, and possibly adjusting, location-based settings on mobile device 110, the settings are transferred to hearing device 100 through a wireless link (e.g., a Bluetooth link). See id. at ¶¶ 10, 36. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 10 depends on claim 7, and further requires the following:
“further comprising displaying on the display of the accessory device another user interface object representative of the processing context parameter.”
Simonides describes tracking a user’s location through GPS data collected by mobile device 110. Simonides at ¶¶ 9, 12, 38–42. As a user moves, the location will be updated. Id. The user’s new location is then tagged with a scene tag for the new location. Id. The new location tag is displayed to the user for user confirmation. Id. at ¶¶ 9, 12, 38–42, 51, 52. When a user confirms the location through a GUI, hearing device 110 retrieves hearing aid settings (either from local memory or a server). Id. at ¶¶ 51–54. Mobile device 110 then transmits the retrieved hearing aid settings to hearing device 100. See id. at ¶¶ 10, 36. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 11 depends on claim 10, and further requires the following:
“further comprising: detecting a user input selecting the other user interface object representative of the processing context parameter; and
“after the user input is detected, transmitting the processing context parameter via the interface of the accessory device to the hearing device.”
Simonides describes tracking a user’s location through GPS data collected by mobile device 110. Simonides at ¶¶ 9, 12, 38–42. As a user moves, the location will be updated. Id. The user’s new location is then tagged with a scene tag for the new location. Id. The new location tag is displayed to the user for user confirmation. Id. at ¶¶ 9, 12, 38–42, 51, 52. When a user confirms the location through a GUI, hearing device 110 retrieves hearing aid settings (either from local memory or a server). Id. at ¶¶ 51–54. Mobile device 110 then transmits the retrieved hearing aid settings to hearing device 100. See id. at ¶¶ 10, 36. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 12 depends on claim 7, and further requires the following:
“further comprising: detecting a user input selecting the user interface object representative of the scene tag, and
“after the user input is detected, transmitting via the interface to the hearing device an updated processing context parameter corresponding to the scene tag.”
Simonides describes displaying location tags to a user through the display of mobile device 110. Simonides at ¶¶ 9, 12, 38–42. A user confirms the tag, which causes mobile device 110 to load locally stored hearing aid settings or to query a server for recommended settings. Id. at ¶¶ 46–54. Mobile device 110 then transmits the settings via a wireless link (e.g., a Bluetooth link) to hearing aid 100. See id. at ¶¶ 10, 36. The settings are updated over time based on user feedback. Id. at ¶ 46. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 13 depends on claim 7, and further requires the following:
“further comprising: detecting a user input selecting the user interface object representative of the scene tag, and
“after the user input is detected, selecting a hearing processing scheme based on an updated processing context parameter corresponding to the scene tag.”
Simonides describes tracking a user’s location through GPS data collected by mobile device 110. Simonides at ¶¶ 9, 12, 38–42. As a user moves, the location will be updated. Id. The user’s new location is then tagged with a scene tag for the new location. Id. The new location tag is displayed to the user for user confirmation. Id. at ¶¶ 9, 12, 38–42, 51, 52. When a user confirms the location through a GUI, hearing device 110 retrieves hearing aid settings (either from local memory or a server). Id. at ¶¶ 51–54. Mobile device 110 then transmits the retrieved hearing aid settings to hearing device 100. See id. at ¶¶ 10, 36. The settings are updated over time based on user feedback. Id. at ¶ 46. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 16 depends on claim 1, and further requires the following:
“wherein the act of determining the processing context parameter comprises determining a hearing processing scheme based on the environment parameter and at least a part of the plurality of input signals.”
The Simonides reference further describes recording sound data in a location and automatically adjusting hearing aid sound settings recommended for a location (or location type) based on the recorded sound data. Simonides at ¶¶ 9–13, 38–40, 46–48, FIG.5. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 17 depends on claim 1, and further requires the following:
“further comprising transmitting the processing context parameter to the hearing device.”
Simonides describes displaying a GUI to a user on the display of mobile device 110 so that a user may choose to use a recommended setting for a location or a previously stored setting for a location. Id. at ¶¶ 51–53. Simonides also describes displaying a GUI on mobile device 110 so that a user may manually alter the location-based settings. Id. at ¶¶ 47, 48. After selecting, and possibly adjusting, location-based settings on mobile device 110, the settings are transferred to hearing device 100 through a wireless link (e.g., a Bluetooth link). See id. at ¶¶ 10, 36. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 18 depends on claim 1, and further requires the following:
“wherein the environment parameter comprises a location-type parameter and/or an environment-type parameter.”
The processor of device 110 evaluates received GPS coordinates (i.e., position data) to determine the type of environment the device is currently located at, such as being at a coffee shop. Simonides at ¶ 12. The determination may be made with regard to a specific location (e.g., a specific coffee shop), or a type of location (e.g., a coffee shop in general). Id. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 19 depends on claim 1, and further requires the following:
“wherein the input signals are wirelessly transmitted from the hearing device to the accessory device while the hearing device is worn by a user.”
Simonides describes displaying a GUI to a user on the display of mobile device 110 so that a user may choose to use a recommended setting for a location or a previously stored setting for a location. Id. at ¶¶ 51–53. Simonides also describes displaying a GUI on mobile device 110 so that a user may manually alter the location-based settings. Id. at ¶¶ 47, 48. After selecting, and possibly adjusting, location-based settings on mobile device 110, the settings are transferred to hearing device 100 through a wireless link (e.g., a Bluetooth link). See id. at ¶¶ 10, 36. For the foregoing reasons, the Simonides reference anticipates all limitations of the claim.
Claim 20 is drawn to “an accessory device.” The following table illustrates the correspondence between the claimed device and the Simonides reference.
Claim 20
The Simonides Reference
“20. An accessory device comprising
The Simonides reference describes a mobile device 110, or accessory device, used to communicate with and control a hearing device 100. Simonides at ¶¶ 9, 10, 31, 36, FIG.1.
“a memory, an interface, a processor, and a display wherein the accessory device is configured to communicate with a hearing device, wherein the accessory device is configured to:
Mobile device 110 includes a user interface (i.e., input), a memory, a display and a processor. See id. at ¶¶ 48, 49, 51 (describing the use of device 110 to receive user input and store, process and display information).
“determine an environment parameter, wherein the environment parameter is based on position data, and
Simonides similarly describes determining an environment parameter, such as determining the coordinates of mobile device 110 through GPS. Id. at ¶¶ 9–14, 38–45, FIG.3. GPS is a type of wireless network that provides position data. (See Spec. at ¶ 24.)
“wherein the environment parameter is indicative of an environment type or a location type;
The processor of device 110 evaluates received GPS coordinates (i.e., position data) to determine the type of environment the device is currently located at, such as being at a coffee shop. Id. at ¶ 12. The determination may be made with regard to a specific location (e.g., a specific coffee shop), or a type of location (e.g., a coffee shop in general). Id.
“determine a processing context parameter after the environment parameter is determined;
After determining the location of mobile device 110, the processor of device 110 uses the GPS-based location to select and adjust sound settings, corresponding to the claimed processing context parameter, for hearing device 100. Id. at ¶¶ 12, 45. For example, mobile device 110 sets and either manually or automatically adjusts hearing aid settings based on recommended settings or previously used settings corresponding to the current location identifier (i.e., scene tag), which is determined from the current GPS coordinates (i.e., environment parameter). Id. at ¶¶ 9–14, 41, 42, 45–54, FIGs.4, 5.
“obtain a plurality of input signals
The Simonides reference describes recording sound data in a location and adjusting hearing aid sound settings based on the recorded sound data. Id. at ¶¶ 9–13, 38–40, 46, 56.
“[the plurality of input signals] that are provisioned by the hearing device; and
Simonides also describes recording the sound data with microphones in either hearing device 100 or mobile device 110. Id. at ¶ 9. More particularly, Simonides describes implementing hearing device 100 as an ear-level device like the one described in the Michael reference, incorporated into Simonides. Id. at ¶¶ 4, 47. The ear-level device includes plural microphones and a Bluetooth module for communication with a mobile device. Michael at col. 4 l. 41 to col. 5 l. 34, FIG.2. Accordingly, Simonides and Michael describe recording sound data with microphones in an ear-level hearing device 100. See Simonides at ¶¶ 36–39; Michael at col. 4 l. 41 to col. 5 l. 34, FIG.2. The sound data would then be transmitted to and received/obtained by mobile device 110 (e.g., using a Bluetooth link) for processing, storing and uploading to a server. See Simonides at ¶¶ 9, 36–39.
“determine a scene tag based on the environment parameter and/or on at least a part of the plurality of input signals;
Simonides describes receiving GPS coordinates and associating the coordinates with a specific location (e.g., a specific coffee shop) or a location type (e.g., a coffee shop, in general). Id. at ¶ 12. This essentially produces an environment parameter describing the type of environment device 110 is currently located in. Simonides further produces a scene tag from this environment parameter, where the scene tag is a human-readable piece of data that is displayed to the user on a display in order for the user to confirm the current location of device 110. Id. at ¶¶ 9, 41, 42, 47, 51, 52.
“wherein the environment parameter and the scene tag comprise non-audio data and
Simonides describes receiving GPS coordinates and processing the coordinate to determine the type of location that device 110 is currently located in. Id. at ¶¶ 12, 40. For example, device 110 determines that it is located at a coffee shop-type location. Id. Thus, device 100 produces a non-audio environment parameter.
Simonides further produces a human-readable label, or scene tag, that is displayed on a display. Id. at ¶¶ 9, 41, 42, 47, 51. The scene tag is not audio data, but textual/graphical data. Id.
“[the environment parameter and the scene tag] are different from each other.”
Further, Simonides’s label and environment parameter are closely related, but are substantively different from each other as claimed due to their different purposes and manners of use. The environment parameter is a piece of data used by the machine to make an initial judgment about where the user and his device is located and the type of hearing parameters to use in processing audio. Id. at ¶¶ 12, 40. The label is data used to produce a visual/textual representation of the user’s location in order to facilitate a user confirming the current location. Id. at ¶¶ 41, 42. While both pieces of data carry information about the type of environment the user and device 110 are currently located in, they are used for different purposes (i.e., selecting appropriate hearing programs versus soliciting user feedback) and in different ways (i.e., internal logic versus user interface). See id. at ¶¶ 12, 40–42.
Table 2
For the foregoing reasons, the Simonides and Michael references anticipate all limitations of the claim.
Claim 22 depends on claim 20, and further requires the following:
“wherein the accessory device is configured to obtain the plurality of input signals that are transmitted from the hearing device while the hearing device worn by a user.”
The Simonides reference describes recording sound data in a location and adjusting hearing aid sound settings based on the recorded sound data. Id. at ¶¶ 9–13, 38–40, 46. Simonides also describes recording the sound data with microphones in either hearing device 100 or mobile device 110. Id. at ¶ 9. More particularly, Simonides describes implementing hearing device 100 as an ear-level device like the one described in the Michael reference, incorporated into Simonides. Id. at ¶¶ 4, 47. The ear-level device includes plural microphones and a Bluetooth module for communication with a mobile device. Michael at col. 4 l. 41 to col. 5 l. 34, FIG.2. Accordingly, Simonides and Michael describe recording sound data with microphones in an ear-level hearing device 100. See Simonides at ¶¶ 38, 39; Michael at col. 4 l. 41 to col. 5 l. 34, FIG.2. The sound data would then be transmitted to and received/obtained by mobile device 110 (e.g., using a Bluetooth link) for processing, storing and uploading to a server. See Simonides at ¶¶ 9, 38, 39. For the foregoing reasons, the Simonides references anticipates all limitations of the claim.
Claim 23 depends on claim 20, and further requires the following:
“A hearing system comprising an accessory device according to claim 20, and the hearing device.”
Simonides similarly describes a system comprising mobile device 110, shown in the anticipation rejection of claim 20 as corresponding to the claimed accessory device, and a hearing device 100. Simonides at ¶ 31, FIG.1. For the foregoing reasons, the Simonides references anticipates all limitations of the claim.
Obviousness
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 14, 15 and 21 are rejected under 35 U.S.C. § 103 as being unpatentable over the combination of Simonides and US Patent Application Publication 2015/0049892 (published 19 February 2015) (“Petersen”).
Claim 14 depends on claim 13, and further requires the following:
“further comprising applying the hearing processing scheme to the plurality of input signals from the hearing device.”
Claim 15 depends on claim 14, and further requires the following:
“wherein the hearing processing scheme is applied to the plurality of input signals to obtain processed input signals, and wherein the method further comprises transmitting the processed input signals via the interface of the accessory device to the hearing device.”
Claims 14 and 15 are treated together. The Simonides reference describes displaying location tags to a user through the display of mobile device 110. Simonides at ¶¶ 9, 12, 38–42. A user confirms the tag, which causes mobile device 110 to load locally stored hearing aid settings or to query a server for recommended settings. Id. at ¶¶ 46–54. Mobile device 110 then transmits the settings via a wireless link (e.g., a Bluetooth link) to hearing aid 100. See id. at ¶¶ 10, 36. Hearing device 100 then processes input signals based on the transferred settings. See id. Accordingly, the Simonides reference does not describe using mobile device 110, corresponding to the claimed accessory device, to perform the claimed acts of applying the hearing processing scheme to the plurality of input signals from the hearing device to obtain processed input signals and transmitting the processed input signals via an interface to a hearing device. Instead, mobile device transmits settings to hearing device 100, which performs the claimed application of a hearing processing scheme to a plurality of input signal to obtain processed input signals. This also obviates the need to transmit processed input signals to hearing device 100.
Though Simonides performs signal processing at hearing device 100 instead of at mobile device 110, one of ordinary skill in the art at the time of the invention would have been aware of other processing arrangements. The Petersen reference, for example, describes receiving signals from a hearing aid at a remote device, processing them there and returning them to the hearing aid. According to Petersen, this enables for more advanced sound processing since a mobile device is not as limited by size and battery requirements as a hearing device (e.g., an ear-worn hearing aid.) Accordingly, it would have been obvious for one of ordinary skill in the art to modify Simonides’s system 150 so that mobile device 110 applies at least some of the location-based sound settings to signals recorded by hearing device 100 and returns the processed signals to hearing device 100 for presentation to a user’s ears. For the foregoing reasons, the combination of the Simonides and the Petersen references makes obvious all limitations of the claims.
Claim 21 depends on claim 20 and further requires the following:
“wherein the accessory device is configured to process the plurality of input signals to obtain processed signals, and wirelessly transmit the processed signals for reception by the hearing device.”
The same concept is addressed in the obviousness rejection of claims 14 and 15, incorporated herein. For the foregoing reasons, the combination of the Simonides and the Petersen references makes obvious all limitations of the claim.
Summary
Claims 1–23 are rejected under at least one of 35 U.S.C. §§ 102 and 103 as being unpatentable in view of the cited prior art. In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 C.F.R. § 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.
Double Patenting
Legal Basis
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).
Non-Statutory Obviousness-Type Double Patenting
Claims 1–23 are rejected on the ground of nonstatutory double patenting as being unpatentable over the claims of US Patent 11,750,987 (the ‘987 Patent). Although the claims at issue are not identical, they are not patentably distinct from each other.
Claims 1–23 are rejected on the ground of nonstatutory double patenting as being unpatentable over the claims of US Patent 12,167,204 (the ‘204 Patent). Although the claims at issue are not identical, they are not patentably distinct from each other.
The following table illustrates the correspondence between claim 1 of this Application and claim 1 of the ‘987 Patent.
This Application
The ‘987 Patent
“1. A method performed by an accessory device, the accessory device being configured to communicate with a hearing device,
“1. A method performed by an accessory device for controlling a hearing device,
[while this claim preamble does not require the device to be configured to communicate with a hearing device, the body of the claim requires that configuration since the accessory device communicates with a hearing device by receiving input signals wirelessly transmitted from the hearing device.]
“the accessory device comprising an interface, a memory, a display, and a processor, the method comprising:
“the accessory device comprising an interface, a memory, a display, and a processor, the method comprising:
“determining an environment parameter, wherein the environment parameter is based on position data, and
“determining an environment parameter, wherein the environment parameter is based on position data wirelessly provided by a network, and
“wherein the environment parameter is indicative of an environment type or a location type;
“wherein the environment parameter is indicative of an environment type or a location type;
“determining a processing context parameter after the environment parameter is determined;
“determining a processing context parameter based on the environment parameter;
“displaying on the display of the accessory device a first user interface object representative of the processing context parameter;
“obtaining a plurality of input signals,
“obtaining a plurality of input signals,
“wherein the input signals are provisioned by the hearing device; and
“wherein the input signals are wirelessly transmitted from the hearing device to the accessory device while the hearing device is at or behind an ear of a user;
“determining a scene tag based on the environment parameter and/or based on at least a part of the plurality of input signals;
“determining a scene tag based on the environment parameter and/or on at least a part of the plurality of input signals; and
“displaying on the display a second user interface object representative of the scene tag, wherein the second user interface object representative of the scene tag is user-selectable;
“wherein the environment parameter and the scene tag comprise non-audio data and are different from each other.”
“wherein the environment parameter and the scene tag comprise non-audio data and are different from each other.
Table 3
The following table illustrates the correspondence between claim 1 of this Application and claim 1 of the ‘204 Patent.
This Application
The ‘204 Patent
“1. A method performed by an accessory device, the accessory device being configured to communicate with a hearing device,
“1. A method performed by an accessory device for controlling a hearing device,
[while this claim preamble does not require the device to be configured to communicate with a hearing device, the body of the claim requires that configuration since the accessory device communicates with a hearing device by receiving input signals wirelessly transmitted from the hearing device.]
“the accessory device comprising an interface, a memory, a display, and a processor, the method comprising:
“the accessory device comprising an interface, a memory, a display, and a processor, the method comprising:
“determining an environment parameter, wherein the environment parameter is based on position data, and
“determining an environment parameter, wherein the environment parameter is based on position data wirelessly provided by a network, and
“wherein the environment parameter is indicative of an environment type or a location type;
“wherein the environment parameter is indicative of an environment type or a location type;
“determining a processing context parameter after the environment parameter is determined;
“determining a processing context parameter after the environment parameter is determined;
“obtaining a plurality of input signals,
“obtaining a plurality of input signals,
“wherein the input signals are provisioned by the hearing device; and
“wherein the input signals are wirelessly transmitted from the hearing device to the accessory device;
“determining a scene tag based on the environment parameter and/or based on at least a part of the plurality of input signals;
“determining a scene tag based on the environment parameter and/or based on at least a part of the plurality of input signals; and
“displaying on the display a user interface object representative of the scene tag;
“wherein the environment parameter and the scene tag comprise non-audio data and are different from each other.”
“wherein the environment parameter and the scene tag comprise non-audio data and are different from each other.”
Table 4
The two tables show that the claims of the patents are in conflict with claim 1 of this Application. While none of the claims are identical, the differences that exist are due to claim 1 of this Application being broader in some aspects than the claims of the patents. Accordingly, if the claims of the patents were available as prior art, they would anticipate claim 1 of this Application.
Comparisons correspondences to those made in the foregoing tables may be made between the claims of the patents and claims 2–23 in this Application. Accordingly, claims 1–23 are rejected for obviousness-type double patenting.
Summary
A timely filed terminal disclaimer in compliance with 37 C.F.R. § 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 C.F.R. § 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 C.F.R. § 1.111(a). For a reply to final Office action, see 37 C.F.R. § 1.113(c). A request for reconsideration while not provided for in 37 C.F.R. § 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.
Response to Applicant’s Arguments
Applicant’s Reply at 6–8 includes comments pertaining to the art rejections presented in the Non-Final Rejection (18 May 2026) and repeated herein. Applicant’s Reply is facially incomplete because it does not address the double patenting rejections. The double patenting rejections will not be held in abeyance. Future responses from Applicant must respond to all grounds of rejection to comply with 37 C.F.R. § 1.111(b). Failure to make a bona fide response to all grounds raised in an Office action may result in holding a reply to be non-responsive. See MPEP § 714.02.
Concerning claim 1, Applicant comments that the Simonides reference does not teach or suggest determining an environment parameter that is based on position data and that is indicative of an environment type or a location type. (Reply at 6–7). Applicant further comments that the Simonides reference does not teach or suggest determining a scene tag based on the environment parameter and/or based on at least a part of the plurality of input signals, where the parameter and scene tag comprise non-audio data and are different from each other. (Id). Applicant notes that the rejection is based on a correspondence between the Simonides GPS coordinates and the claimed environment parameter. (Id.) The rejection, however, is not premised on this mapping. As stated in the rejection:
“Simonides describes receiving GPS coordinates and associating the coordinates with a specific location (e.g., a specific coffee shop) or a location type (e.g., a coffee shop, in general). [Simonides] at ¶ 12. This essentially produces an environment parameter describing the type of environment device 110 is currently located in. Simonides further produces a scene tag from this environment parameter, where the scene tag is a human-readable piece of data that is displayed to the user on a display in order for the user to confirm the current location of device 110. Id. at ¶¶ 9, 41, 42, 47, 51, 52.”
Thus, the rejection maps Simonides GPS coordinates to the claimed position data. The rejection further draws a correspondence between the claimed environment parameter and the type of environment a device is currently located at. In particular, Simonides teaches the use of GPS data to determine the coordinates of a device, and then accesses a database to compare the GPS data to known locations to figure out the location or type of location in which the device is currently located.
Applicant comments
“Since Simonides does not disclose environment parameter determined by an accessory device based on position data, Simonides also cannot disclose or suggest determining a processing context parameter after such environment parameter (which in turn, is determined by an accessory device based on position data) is determined.”
(Reply at 7). Applicant further comments
“because Simonides does not disclose environment parameter that is determined by an accessory device based on position data, Simonides also does not disclose or suggest such environment parameter (determined by an accessory device based on position data) comprising non-audio data and is different from non-audio data of a scene tag.”
(Id.) These comments are contingent on Applicant’s previous comment being true. But as just shown, Applicant’s premise is not true in this case since Simonides describes the determination of a location or location type that corresponds to the claimed environment parameter and that is based on position data, such as GPS data.
Applicant comments that Simonides describes determining that a device is in a coffee shop based on GPS coordinates, but does not disclose determining that a device is in a coffees shop based on an environment parameter that is different from position data. (Reply at 7). Claim 1, however, does not require any such limitation. The claim requires
“determining an environment parameter, wherein the environment parameter is based on position data, and wherein the environment parameter is indicative of an environment type or a location type.”
The plain language only requires determining an environment parameter from position data. The claim then characterizes the environment parameter is being indicative of environment type or location type. Thus, this claim limitation is fulfilled by Simonides teaching the determination of a device being in a coffee shop generally based on GPS coordinates.
Applicant comments that Simonides does not describe the claimed scene tag because Simonides only displays a question as to whether a user has reentered a suggested location. (Reply at 7–8). The rejection shows that Simonides stores processing parameters associated with different locations, or location types, such as a general coffee shop. Thus, when the Simonides system queries a user by displaying a question to the user about whether the user has actually entered a particular location or type of location, the system must determine a scene tag to display to the user. Thus, the environment parameter and scene tag will both comprise non-audio data. They will also be different from each other because they are used in different components of the system and have different purposes. The environment parameter is a system determination of where it thinks the user device is currently located. The scene tag is derived from the environment parameter but is formatted and displayed to the user as a piece of user-perceptible information so the user may confirm whether the environment parameter is correct. This difference is enough to meet the claim language since the plain language of the claim omits any limitations as to how the environment parameter and the scene tag differ from each other.
For the foregoing reasons, Applicant has not persuasively established any error in the Office action. All the rejections will be maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WALTER F BRINEY III whose telephone number is (571)272-7513. The examiner can normally be reached on M-F 8 am-4:30 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, Carolyn Edwards can be reached on 571-270-7136. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Walter F Briney III/
Walter F Briney IIIPrimary ExaminerArt Unit 2655
10/13/2026
1 This rejection further recites US Patent 8,379,871 (patented 19 February 2013) (“Michael”) (incorporated by reference into Simonides at ¶ 4).
2 The claim does not specify how these two entities differ from each other. Further, the Spec at ¶ 35 shows that both the environment parameter and scene tag convey similar information, such as a location type. Thus, the claimed difference must exist at a fundamentally different level, such as purpose and use (i.e., internal logic versus user interface).
