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 .
DETAILED ACTION
1. The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim Rejections - 35 USC § 103
2. Claims 1-4, 6-14, 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over submitted prior arts Mate et al. (WO 2021/186104 A1) in view of D2 (retrieved from the internet MPEG-I Immersive Audio Encoder Input Format).
As to claim 1, Mate teaches an apparatus for providing a decoded audio representation on the basis of an encoded audio representation included in a bitstream comprising a plurality of packets of different packet types (page 1, lines 8-23 - adaptation of audio content rendering. This may comprise, for example, six degree of freedom (6DOF) rendering of audio, such as MPEG-I audio bitstream content for example, while adhering to content creator instructions, to incorporate dynamic content, the rendering implies the decoding of the audio representation according to the MPPEG-I audio bitstream; page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 2 and page 9, lines 16-18 – the EID 200 together with audio data processed by the audio encoder 202 to generate the bitstream 204) the apparatus comprising:
wherein an audio decoder is configured to spatially render one or more audio signals (page 1, lines 13-15 – Bitstream content is data which has been created by encoding the 6DOF audio scene description, the raw audio signals and the MPEG-H encoded/decoded audio signals; page 11, lines 10-16 - new MHASampleEntry may be defined to indicate 6DoF rendering related metadata for MPEG-H 3D Audio files and the whole description is directed to the 6DoF rendering in AR/VR application based on the MPEG-I Audio / MPEG-H 3D audio which implies the spatial rendering; page 26, lines 22-30 - determining a spatial audio flag value in the dynamic content, and selecting to: when the spatial audio flag value is false, rendered dynamic content communication audio without any further acoustic modelling, or when the spatial audio flag value is true, render dynamic content communication audio with acoustic modelling according to the information in the bitstream; Fig. 1 - auralization);
wherein the audio decoder is configured to receive the plurality of packets of different packet types (page 11, lines 10-16 and page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 1, MPEG-I Audio Bitstream, Common 6DoF Metadata);
wherein the plurality of packets comprising one or more scene configuration packets, wherein the one or more scene configuration packets provide a renderer configuration information (Fig. 1, dynamic updates; page 11, lines 10-16 - the MPEG-H 3D Audio configuration may include 6DOF metadata capable packets which may change at arbitrary positions of the stream; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update);
wherein the plurality of packets comprise one or more scene update packets, wherein the one or more scene update packets define an update of scene metadata for the rendering (Fig. 1, dynamic updates; page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update);
wherein the audio decoder is configured to evaluate whether one or more update conditions are fulfilled and to selectively update one or more scene metadata in dependence on a content of the one or more scene update packets if the one or more update conditions are fulfilled (page 5, line 19 – page 6, line 5; page 17, line 7 – page 19, line 25); and
wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata).
Mate does not explicitly teach the scene update packets define an update of scene metadata for the rendering and a representation of one or more updates conditions.
D2 teaches the features of transmitting metadata updates for spatial audio rendering associated with update conditions (section 1 Introduction, 2nd paragraph).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of D2 into the teachings of Mate and it would have been obvious to update in the same packets for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
As to claim 2, Mate teaches the apparatus according claim 1, wherein the audio decoder is configured to evaluate a temporal condition, which is included in a scene update packet, in order to decide whether one or more scene metadata should be updated in dependence on a content of the one or more scene updated packets (page 17, line 7 – page 19, line 25 – the update message as defined in EIF extended to allow updates via dynamic content in addition to the currently specified updates; the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reached); and D2 teaches in (pages 7-9, 2.3 Scene updates – a timed update (L1) is executed by the renderer once at a fixed predefined time; the update is performed when the specified time is reached).
As to claim 3, Mate teaches the apparatus according claim 2, wherein the temporal condition defines a start time instant or wherein the temporal condition defines a time interval (page 17, lines 7-22 - the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reaches); wherein the audio decoder is configured to effect an update of one or more scene metadata in response to a detection that a current playout time has reached the start time instant or lies after the start time instant, or wherein the audio decoder is configured to effect an update of one or more scene metadata in response to a detection that a current playout time lies within the time interval (page 17, lines 7-22 - the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reached; page 18 and table; claim 4); and D2 teaches in (pages 7-9, 2.3 Scene updates – a timed update (L1) is executed by the renderer once at a fixed predefined time; the update is performed when the specified time is reached).
As to claim 4, Mate teaches the apparatus according claim 1, wherein the audio decoder is configured to evaluate a spatial condition (page 11, lines 10-16 - new MHASampleEntry may be defined to indicate 6DoF rendering related metadata for MPEG-H 3D Audio files and the whole description is directed to the 6DoF rendering in AR/VR application based on the MPEG-I Audio / MPEG-H 3D audio which implies the spatial rendering; page 26, lines 22-30 - determining a spatial audio flag value in the dynamic content, and selecting to: when the spatial audio flag value is false, rendered dynamic content communication audio without any further acoustic modelling, or when the spatial audio flag value is true, render dynamic content communication audio with acoustic modelling according to the information in the bitstream), which is included in a scene update packet, in order to decide whether one or more scene metadata should be updated in dependence on a content of the one or more scene update packets (page 17, line 7 – page 19, line 25 – the update message as defined in EIF extended to allow updates via dynamic content in addition to the currently specified updates; the currently specified updates done based on a predetermined timestamp; the update is performed when the specified time is reached).
As to claim 6, D2 teaches the apparatus according claim 1, wherein the audio decoder is configured to evaluate whether an interactive trigger condition is fulfilled, in order to decide whether one or more scene metadata should be updated in dependence on a content of the one or more scene update packets (pages 6-9 – a triggered update (L2) is manually triggered from an external entity using an OSC message; the update is triggered by its ID or index. Different updates types can be mixed to control an entity. Scene creators are advised not to mix different update type for the same attribute of an entity. If an entities’ attribute is statistically animated it may not be updated with triggered updates).
As to claim 7, Mate and D2 do not explicitly teach the apparatus according claim 1, wherein the audio decoder is configured to evaluate a combination of two or more update conditions and wherein the audio decoder is configured to selectively update one or more scene metadata in dependence on a content of the one or more scene update packets if a combined update condition is fulfilled. However, D2 teaches types of updates can be defined in a EIF file: a timed updated, a conditional update, a triggered update, and a dynamic update (page 7); and different updates types can be mixed to control an entity; however scene creators advised not to mix different update type for the same attribute of an entity which may result in an undesired behavior. If an entities’ attribute statically animated it may not be updated with conditional or triggered updates (page 9). It would have been obvious to update scene metadata in dependence on a content of scene updates packets when a combined updated condition is fulfilled in order to effectively mix the updates without undesired behavior result.
As to claim 8, D2 teaches the apparatus according claim 1, wherein the audio decoder is configured to evaluate both a temporal update condition and a spatial update condition, or wherein the audio decoder is configured to evaluate both a temporal update condition and an interactive update condition (pages 7-9 – a timed update that executed by the renderer once at a fixed predefined time, a triggered update is manually triggered from an external entity and a dynamic update is an update from an external entity that includes the values of the attributes to be updated; the update is performed when the specified time is reaches or the condition changed its state to the logical value expressed, the update is triggered by its ID or index by an external entity; and different updates types can be mixed to control an entity; however scene creators advised not to mix different update type for the same attribute of an entity which may result in an undesired behavior. If an entities’ attribute statically animated it may not be updated with conditional or triggered updates (page 9)).
As to claim 9, Mate teaches the apparatus according claim 1, wherein the audio decoder is configured to evaluate a delay information which is included in the scene update packet (Fig. 6 – shows MPEG-I audio dynamic scene updates for low delay audio). Mate does not explicitly discuss delay an update of one or more scene metadata in dependence on a content of the one or more scene update packets in accordance with the delay information in response to a detection that the one or more update condition are fulfilled. However, Mate teaches
«Update condition="cond:1istenerNearCar” delay =”0.1”> «Modify id=”engine" transition="continuous” duration-"0.05” active-”true” and
<Update condition~”cond:1istenerNearCar” delay =”0.2”> «Modify id=”radio” transition=”continuous” duration=”0.2” active-”true” (page 19). It would have been obvious to detect that the update condition are fulfilled to delay an update in order to render of such content may be adapted to the MPEG-I audio bitstream content to ensure a harmonious merge without introducing any distortion.
As to claim 10, Mate and D2 do not explicitly discuss the apparatus according claim 1, wherein the audio decoder is configured to evaluate a flag within the scene update packet indicating whether a temporal update condition is defined in the scene update packet and/or wherein the audio decoder is configured to evaluate a flag within the scene update packet indication whether a spatial update condition is defined in the scene update packet. However, D2 teaches declaring one or more changes to the audio scene and the update is performed when the specified time is reaches, the condition changed its state to the logical value expressed by fireOn parameter determines whether the update firs when the condition changes from false-to-true or from true-to-false – see Modification Flags - (pages 6-9 section 2.3). It would have been obvious to evaluate a flag within the scene update packet indicating whether a temporal update condition is defined in order to have an updates modifies defined in the EIF file and known to the encoder.
As to claim 11, D2 teaches declaring one or more changes to the audio scene and the update is performed when the specified time is reaches, the condition changed its state to the logical value expressed by fireOn parameter determines whether the update firs when the condition changes from false-to-true or from true-to-false – see Modification Flags - (pages 6-9 section 2.3); and
Mate teaches «Update condition="cond:1istenerNearCar” delay =”0.1”> «Modify id=”engine" transition="continuous” duration-"0.05” active-”true” and
<Update condition~”cond:1istenerNearCar” delay =”0.2”> «Modify id=”radio” transition=”continuous” duration=”0.2” active-”true” (page 19). It would have been obvious to incorporate the delay information defined in the scene update packet into the teachings of D2 for the purpose of evaluating a flag that indicating a delay information in the scene update packet in accordance with the delay information in response to a detection that the one or more update conditions are fulfilled.
As to claim 12, Mate teaches the apparatus according to claim 1 wherein the scene updated packet comprises a representation of a plurality of modifications of one or more parameters of one or more scene objects and/or of one or more scene characteristics (page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates and AR evaluation), wherein the audio decoder is configured to apply the modifications in response to a detection that the one or more update conditions are fulfilled (page 5, line 19 – page 6, line 5; page 17, line 7 – page 19, line 25).
As to claim 13, Mate teaches the apparatus according to claim 1 wherein the scene updated packet comprises a trajectory information and wherein the audio decoder is configured to update a respective scene metadata, to which the trajectory information is associated, using a parameter variation following a trajectory defined by the trajectory information (page 18, lines 6-20) and D2 teaches in (pages 6-9 section 2.3) that timed updates synchronously move three object sources of a vehicle in motion along a trajectory
Update time=”0.2”>
<Modify id=”engine” position=”? .2 1.7 -1.25" />
<Modify id="tire1” position="? . 2 1.7 0.75" />
<Modify id=”tire2” position=”2 , 2 1.7 -0.95” />
<Update time-”0.4”>
<Modify id="engine” position="2 .4 1.7 -1.20” />
<Modify id="tire1” position="? .4 1.7 0.70" />
<Modify id=”tire2" position=”? .4 1.7 -0.95" />.
As to claim 14, Mate and D2 do not explicitly discuss the apparatus according to claim 13, wherein the audio decoder is configured to evaluate an information indicating whether a trajectory based update of scene metadata is used, in order to activate or deactivate the trajectory based update of scene metadata. However, Mate teaches timed updates synchronously move three object sources of a vehicle in motion along a trajectory evaluating update time and modify ID engine positions and The following example turns on the sources of a car when the listener gets close.
<Box id="geo:region1" position=”5 0 -5” size="102 10"
<ListenerProximityCondition id=”cond:listenerNearCar" region=”geo:region1”
<!— Turn on the engine sound 100ms after the listener entered the region. Smoothly activate the source within 50ms (page18, line 6 – page 19, line 15). It would have been obvious to evaluate an information indicating whether a trajectory based update of scene metadata is used, in order to activate or deactivate the trajectory based update of scene metadata.
As to claim 16, Mate teaches the apparatus according to claim 13, wherein the audio decoder is configured to evaluate a supporting point information describing the trajectory (page 18, lines 6-20) and D2 teaches in (pages 6-9 section 2.3) that timed updates synchronously move three object sources of a vehicle in motion along a trajectory, and it would have been obvious to evaluate the supporting point information describing the trajectory in order to update synchronously move along a trajectory effectively.
As to claim 17, Mate teaches an apparatus for providing an encoded audio representation in a bitstream, the bitstream comprising a plurality of packets of different packet types (page 1, lines 8-23 - adaptation of audio content rendering. This may comprise, for example, six degree of freedom (6DOF) rendering of audio, such as MPEG-I audio bitstream content for example, while adhering to content creator instructions, to incorporate dynamic content, the rendering implies the decoding of the audio representation according to the MPPEG-I audio bitstream; Fig. 2 and page 9, lines 16-18 – The EID 200 together with the audio data (audio signals, SOFA files, etc.) may be processed by the audio encoder 202 to generate the bitstream 204; page 11, lines 10-16 and page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 1, MPEG-I Audio Bitstream, Common 6DoF Metadata);
an encoder configured to provide an information for a spatially rendering one or more audio signals (page 11, lines 10-16 - new MHASampleEntry may be defined to indicate 6DoF rendering related metadata for MPEG-H 3D Audio files and the whole description is directed to the 6DoF rendering in AR/VR application based on the MPEG-I Audio / MPEG-H 3D audio which implies the spatial rendering; page 26, lines 22-30 - determining a spatial audio flag value in the dynamic content, and selecting to: when the spatial audio flag value is false, rendered dynamic content communication audio without any further acoustic modelling, or when the spatial audio flag value is true, render dynamic content communication audio with acoustic modelling according to the information in the bitstream; Fig. 2 and page 9, lines 16-18 – the EID 200 together with audio data processed by the audio encoder 202 to generate the bitstream 204);
wherein the encoder is configured to receive the plurality of packets of different packet types (page 11, lines 10-16 and page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 1, MPEG-I Audio Bitstream, Common 6DoF Metadata);
wherein the plurality of packets comprising one or more scene configuration packets providing a renderer configuration information (page 11, lines 10-16 - the MPEG-H 3D Audio configuration may include 6DOF metadata capable packets which may change at arbitrary positions of the stream);
wherein the plurality of packets comprising one or more scene update packets, wherein the one or more scene update packets define an update of scene metadata for the rendering (page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update); and
wherein the content of the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata).
Mate does not explicitly teach the scene update packets define an update of scene metadata for the rendering and a representation of one or more updates conditions.
D2 teaches the features of transmitting metadata updates for spatial audio rendering associated with update conditions (section 1 Introduction, 2nd paragraph).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of D2 into the teachings of Mate and it would have been obvious to update in the same packets for the purpose of providing technical implementation of the transmission of the metadata updates associated with the update conditions.
Claims 18 and 20 are rejected for the same reasons discussed above with respect to claim 1. Furthermore, Mate teaches a non-transitory digital storage medium having stored there on a computer program (page 34, lines 8-11; page 35, lines 29-32; claims 11 and 14).
Claims 19 and 21 are rejected for the same reasons discussed above with respect to claim 17. Furthermore, Mate teaches a non-transitory digital storage medium having stored there on a computer program (page 34, lines 8-11; page 35, lines 29-32; claims 11 and 14).
3. Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over submitted prior arts Mate and D2 (retrieved from the internet MPEG-I Immersive Audio Encoder Input Format) in view of Sen (2014/0086416).
As to claim 5, Mate and D2 do not explicitly discuss the apparatus according to claim 4, wherein the spatial condition defines a geometry element and wherein the audio decoder is configured to effect an update of one or more scene metadata in response to a detection that a current position has reached the geometry element, or in response to a detection that a current position lies within the geometry element.
Sen teaches encoding and decoding process with a scene -based approach, scene-based encoder SE10 produces a description of the SHC that is transmitted (and/or stored) and decoded at the scene-based decoder SD10 to receive the SHC for rendering (e.g., by SH renderer SR10) ([0091]); providing an encoding of spatial audio information into a standardized bit stream and a subsequent decoding that is adaptable and agnostic to the speaker geometry and acoustic conditions at the location of the renderer ([0092]).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Sen into the teachings of Mate and D2 for the purpose of providing the goal of a uniform listening experience regardless of the particular setup that is ultimately used for reproduction.
4. Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over submitted prior arts Mate and D2 (retrieved from the internet MPEG-I Immersive Audio Encoder Input Format) in view of Swaminathan et al. (2021/0006922).
As to claim 15, Mate teaches evaluating a supporting point information describing the trajectory (page 18, lines 6-20) and D2 teaches in (pages 6-9 section 2.3) that timed updates synchronously move three object sources of a vehicle in motion along a trajectory, and it would have been obvious to evaluate the supporting point information describing the trajectory in order to update synchronously move along a trajectory effectively. Mate and D2 do not explicitly discuss the apparatus according to claim 13, wherein the audio decoder is configured to evaluate an interpolation type information included in the scene update packet in order to determine a type of interpolation between two or more support points of the trajectory.
Swaminathan teaches certain individual streams or groups of streams may be enabled for better audio interpolation. The source device 12 may wish to make higher resolution rendering available for a temporary period of time, such as for an advertisement or a teaser for the higher resolution rendering; update duration as an effect of the interpolate attribute; the intermediate updates/interpolation between the update duration are applied as a part of the audio renderer and the different schemes of interpolation can be applied as a personal preference or can be situational ([0130-0136]).
It would have been obvious before the effective filing date of the claimed invention to incorporate the teachings of Swaminathan into the teachings of Mate and D2 for the purpose of enabling certain individual streams or groups of streams for better audio interpolation.
Response to Arguments
5. Applicant’s arguments with respect to claims 1-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argues that D2 does not teach the claimed packet architecture as recited in claim 1 such as “included in a bitstream, the bitstream comprising a plurality of packets of different packet types”, “the plurality of packets comprise one or more scene configuration packets”, “the plurality of packets comprise one or more scene update packets, wherein the one or more scene update packets define an update of scene metadata for the rendering and comprise a representation of one or more update conditions”.
Examiner respectfully submits that Mate teaches included in a bitstream comprising a plurality of packets of different packet types (page 1, lines 8-23 - adaptation of audio content rendering. This may comprise, for example, six degree of freedom (6DOF) rendering of audio, such as MPEG-I audio bitstream content for example, while adhering to content creator instructions, to incorporate dynamic content, the rendering implies the decoding of the audio representation according to the MPPEG-I audio bitstream; page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 2 and page 9, lines 16-18 – the EID 200 together with audio data processed by the audio encoder 202 to generate the bitstream 204); the audio decoder is configured to receive the plurality of packets of different packet types (page 11, lines 10-16 and page 13, lines 17-19 - the renderer may receive dynamic updates via a dynamic ingestion interface or as a new type of MPEG-H Audio Stream (MHAS) packet implies that plurality of packets types; Fig. 1, MPEG-I Audio Bitstream, Common 6DoF Metadata); the plurality of packets comprising one or more scene configuration packets, wherein the one or more scene configuration packets provide a renderer configuration information (Fig. 1, dynamic updates; page 11, lines 10-16 - the MPEG-H 3D Audio configuration may include 6DOF metadata capable packets which may change at arbitrary positions of the stream; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update); the plurality of packets comprise one or more scene update packets, wherein the one or more scene update packets define an update of scene metadata for the rendering (Fig. 1, dynamic updates; page 11, lines 10-16; page 5, line 19 – page 7, lines 24-26 – modification metadata, dynamic scene updates; page 17, line 7 – page 19, line 25 - The currently specified updates may be done based on a predetermined timestamp, condition-based update (e.g., location-based trigger) and explicit user interaction (e.g., turn on the radio); the table bridging pages 17-18 defines the condition as part of the update); evaluate whether one or more update conditions are fulfilled and to selectively update one or more scene metadata in dependence on a content of the one or more scene update packets if the one or more update conditions are fulfilled (page 5, line 19 – page 6, line 5; page 17, line 7 – page 19, line 25); and the one or more scene update packets defines a change of one or more metadata values for the rendering (page 11, line 10-16; page 6, line 19 – page 7, line 26 – modification metadata). And D2 teaches the features of transmitting metadata updates for spatial audio rendering associated with update conditions (section 1 Introduction, 2nd paragraph). The combination of Mate and D2 teaches the claimed invention.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Conclusion
6. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUYNH H NGUYEN whose telephone number is (571)272-7489. The examiner can normally be reached Monday-Thursday 7:30AM-5:30PM.
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, Ahmad Matar can be reached on 571-272-7488. 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.
/QUYNH H NGUYEN/Primary Examiner, Art Unit 2693
Prosecution Insights