Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. EXAMINER’S NOTE: The claims have been reviewed and considered under the new guidance pursuant to the 2019 Revised Patent Subject Matter Eligibility Guidance (PEG 2019) issued January 7, 2019.
3. This communication is in response to Applicant’s Amendment filed on 07 July 2026. Claims 1, 6, and 11-14 have been amended. Claims 1-14 remain pending.
Response to Arguments
4. Applicant’s arguments, see pages 1-4, filed 07 July 2026, with respect to the rejection(s) of claim(s) 1-3, 5-8, and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Kozakiewicz (WO 2019233951 A1) have been fully considered, but are moot in view of the new grounds of rejection. A new ground(s) of rejection is hereby presented in view of Hayim (Pub No. 2013/0346565).
Claim Rejections - 35 USC § 103
5. 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 (i.e., changing from AIA to pre-AIA ) 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.
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.
6. Claims 1-3, 5-8, and 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Kozakiewicz (WO 2019233951 A1) in view of Hayim (Pub No. 2013/0346565).
Referring to the rejection of claim 1, Kozakiewicz discloses a content generation apparatus comprising: (See pg. 14, lines 23-27, i.e., A user’s portable computing device having a user software application (1a), for allowing the creation of digital content)
a memory storing instructions; (See Kozakiewicz, pg. 14, lines, 28-29, i.e., The software application is able to manage memories including at least one memory of the computer hardware)
and at least one processor that executes the instructions to: (See Kozakiewicz, pg. 15, lines 4-7, i.e., The software application contains instructions that when executed by a hardware processor enable communication with a distributed database server to enable the creation of the content)
generate a video file including video data, audio data, and metadata; (See Kozakiewicz, pg. 2, lines 1-2 and pg. 9, lines 3-11, i.e., digital content being text, image, video, and the inclusion of information about the filing date and the creator)
generate a hash value from the audio data and the metadata; (See Kozakiewicz, pg. 7, lines 15-18, i.e., generating a first hash, HA, from the content and a first signature, SA, from the content)
and transmit the hash value and the video file to a content management apparatus that registers the hash value and the metadata in a block of a blockchain. (See Kozakiewicz, pg. 7, lines 15-20, pg. 10, lines 24-29 and pg. 11, lines 1-4, i.e., transmitting first message containing the content, associated with the first hash value, HA, and the first signature, SA, to the server for registering and storing the creator and/or the content in a distributed database of a blockchain network)
Kozakiewicz fails to explicitly disclose generating a hash value without using the video data.
Hayim discloses a blockchain-based shadow images to facilitate copyright protection of digital content.
Hayim discloses generating a hash value without using the video data. (See Hayim, para. 74-75, i.e., One example for defining anchors on a stream is choosing an anchor to be every position in the stream where the string "abc" appears. Another example for defining anchors is choosing anchors to be every position in the stream where a 9-bit hash of 5 consecutive bytes is zero. A 9-bit CRC was chosen because when a CRC of five byte string is given it is easy to remove the contribution of the first byte in the string and to add a new byte at the end of the string. A 96-bit hash key is computed over the next 100 consecutive bytes. The value of the hash key returned is called "block ID". Skip a certain amount of data after finding an anchor, e.g. it is possible to skip 400 bytes or 500 bytes far from the previous anchor considered, before finding the next anchor. Accordingly, it is appreciated that a packet will hold no more than three clock IDs, and that a block of 64K will hold no more than 128 block IDs)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Kozakiewicz’s software application and computer server for creating digital content and authenticating the digital content modified with Hayim’s method for delivering data streams over communication networks. Motivation for such an implementation would enable skipping 64 bytes of video data without being used for processing the hash value. (See Hayim, para. 74-75)
Referring to the rejection of claims 2, 7 Kozakiewicz in view of Hayim discloses wherein the video file is managed by the content management apparatus in association with a block ID of the block and an authenticity guarantee number, and the video file is provided by the content management apparatus together with the authenticity guarantee number. (See Kozakiewicz, pg. 9, lines 24-25 and pg. 22, lines 1-3, i.e., the second message provided by a third-party user comprise the published digital content and/or the identifier number (IDNp))
Referring to the rejection of claim 3, Kozakiewicz in view of Hayim discloses wherein the at least one processor executes the instructions to further transmit an audio file including the audio data and the metadata to the content management apparatus, and the audio file is managed by the content management apparatus in association with an authenticity guarantee number common to the video file. (See Kozakiewicz, Fig. 2b, i.e., to validate the integrity of the published digital content when the hash values (HA .sub.; Hp) are similar, and on the other hand, to validate the authenticity of the creator of the published digital content when the signature values (HA .sub.; HP) are similar. In certain embodiments, as represented for example in FIG. 2b, the verification of the authentication by comparison of the hash values (HA .sub.; HP) and / or the identification numbers (INDc; IDNp) can be carried out in the form of testing by one or more server algorithms. The blockchain network technology is of the "authorized", "private" and publicly accessible type to, on the one hand, only allow the validly identified and authenticated creator to create and declare digital content, and on the other hand, allow any third-party user to verify the authenticity of the digital content. This configuration protects the falsification of the created digital content and / or the identity of the content creator)
Referring to the rejection of claims 5 and 10, Kozakiewicz in view of Hayim discloses wherein the content generation apparatus is an image pickup apparatus that shoots a subject to generate a video file. (See Kozakiewicz, pg. 24, lines 10-14, i.e., mobile computing device containing a camera is disclosed)
*Although the reference does not explicitly mention the use of the camera for shooting a subject to generate a video file at the time of filing of the current application, using a mobile phone to capture video are common practice for creating a content to be uploaded to a server for storage or sharing data over a network.
Referring to the rejection of claim 6, Kozakiewicz discloses a content management apparatus comprising: (See Kozakiewicz, pg. 14, lines 15-17, figs. 1a, item 2, i.e., computer server that is capable of certifying digital content created by an authenticated creator and verifying the authenticity of this digital content published online)
a memory storing instructions; (See Kozakiewicz, pg. 14, lines, 28-29, i.e., The software application is able to manage memories including at least one memory of the computer hardware)
and at least one processor that executes the instructions to: (See Kozakiewicz, pg. 15, lines 4-7, i.e., The software application contains instructions that when executed by a hardware processor enable communication with a distributed database server to enable the creation of the content)
acquire a video file including video data, audio data, and metadata, and a hash value; (See Kozakiewicz, pg. 2, lines 1-2 and pg. 9, lines 3-11 and pg. 7, lines 15-20, i.e., digital content being text, image, video, and the inclusion of information about the filing date and the creator and a server receiving a first message containing the content, associated with the first hash, HA, and the first signature, SA)
generate a hash value from the audio data and the metadata; (See Kozakiewicz, pg. 7, lines 15-18, i.e., generating a first hash, HA, from the content and a first signature, SA, from the content)
perform processing of, in a case where the acquired hash value and the generated hash value match, (See Kozakiewicz, pg. 18, lines 27-29 and pg. 19, lines 1-3, i.e., hashing the created digital content ensures the integrity of that content. Thus, any modification of the content occurring after performing a hash function, changes the hash value initially assigned by the function. A comparison of similarity between the hash value initially assigned to the content and the value of hash assigned after content modification, can detect and verify any change in digital content and thus provides information on the integrity of digital content. The signature of the digital content created, being specific to the software application of the user and / or the creator, makes it possible to authenticate the identity of a content creator. The server certifies the authentication of the published digital content by comparing the at least similarity between the hash values (HA; Hp) and / or the ID number (IDNp) of the published content and the number of the identifier (IDNc) of the created content. In some embodiments, the server may further compare the similarity between the created (original) content and the published content)
registering in a block of a blockchain an identifier that uniquely identifies the video file, and the hash value; (See Kozakiewicz, pg. 7, lines 15-20, pg. 10, lines 24-29 and pg. 11, lines 1-4, i.e., transmitting first message containing the content, associated with the first hash value, HA, and the first signature, SA, to the server for registering and storing the creator and/or the content in a distributed database of a blockchain network)
and distribute to another apparatus an audio file including the audio data, in association with the identifier. (See Kozakiewicz, pg. 15, lines 21-29, pg. 16, line 4, pg. 23, lines 21-22, i.e., server carrying out the public provision of the digital content to the third party user after verifying the digital content transmitted by the creator)
Kozakiewicz fails to explicitly disclose generating a hash value without using the video data.
Hayim discloses a blockchain-based shadow images to facilitate copyright protection of digital content.
Hayim discloses generating a hash value without using the video data. (See Hayim, para. 74-75, i.e., One example for defining anchors on a stream is choosing an anchor to be every position in the stream where the string "abc" appears. Another example for defining anchors is choosing anchors to be every position in the stream where a 9-bit hash of 5 consecutive bytes is zero. A 9-bit CRC was chosen because when a CRC of five byte string is given it is easy to remove the contribution of the first byte in the string and to add a new byte at the end of the string. A 96-bit hash key is computed over the next 100 consecutive bytes. The value of the hash key returned is called "block ID". Skip a certain amount of data after finding an anchor, e.g. it is possible to skip 400 bytes or 500 bytes far from the previous anchor considered, before finding the next anchor. Accordingly, it is appreciated that a packet will hold no more than three clock IDs, and that a block of 64K will hold no more than 128 block IDs)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Kozakiewicz’s software application and computer server for creating digital content and authenticating the digital content modified with Hayim’s method for delivering data streams over communication networks. Motivation for such an implementation would enable skipping 64 bytes of video data without being used for processing the hash value. (See Hayim, para. 74-75)
Referring to the rejection of claims 8, Kozakiewicz in view of Hayim discloses wherein the identifier is the authenticity guarantee number. (See Kozakiewicz, pg. 9, lines 24-25 and pg. 22, lines 1-3, i.e., the second message provided by a third-party user comprise the published digital content and/or the identifier number (IDNp))
Referring to the rejection of claim 11, Kozakiewicz discloses a control method for a content generation apparatus, the control method comprising: (See pg. 14, lines 23-27, i.e., A user’s portable computing device having a user software application (1a), for allowing the creation of digital content)
generating a video file including video data, audio data, and metadata; (See Kozakiewicz, pg. 2, lines 1-2 and pg. 9, lines 3-11, i.e., digital content being text, image, video, and the inclusion of information about the filing date and the creator)
generating a hash value from the audio data and the metadata; (See Kozakiewicz, pg. 7, lines 15-18, i.e., generating a first hash, HA, from the content and a first signature, SA, from the content)
and transmitting the hash value and the video file to a content management apparatus that registers the hash value and the metadata in a block of a blockchain. (See Kozakiewicz, pg. 7, lines 15-20, pg. 10, lines 24-29 and pg. 11, lines 1-4, i.e., transmitting first message containing the content, associated with the first hash value, HA, and the first signature, SA, to the server for registering and storing the creator and/or the content in a distributed database of a blockchain network)
Kozakiewicz fails to explicitly disclose generating a hash value without using the video data.
Hayim discloses a blockchain-based shadow images to facilitate copyright protection of digital content.
Hayim discloses generating a hash value without using the video data. (See Hayim, para. 74-75, i.e., One example for defining anchors on a stream is choosing an anchor to be every position in the stream where the string "abc" appears. Another example for defining anchors is choosing anchors to be every position in the stream where a 9-bit hash of 5 consecutive bytes is zero. A 9-bit CRC was chosen because when a CRC of five byte string is given it is easy to remove the contribution of the first byte in the string and to add a new byte at the end of the string. A 96-bit hash key is computed over the next 100 consecutive bytes. The value of the hash key returned is called "block ID". Skip a certain amount of data after finding an anchor, e.g. it is possible to skip 400 bytes or 500 bytes far from the previous anchor considered, before finding the next anchor. Accordingly, it is appreciated that a packet will hold no more than three clock IDs, and that a block of 64K will hold no more than 128 block IDs)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Kozakiewicz’s software application and computer server for creating digital content and authenticating the digital content modified with Hayim’s method for delivering data streams over communication networks. Motivation for such an implementation would enable skipping 64 bytes of video data without being used for processing the hash value. (See Hayim, para. 74-75)
Referring to the rejection of claim 12, Kozakiewicz discloses a control method for a content management apparatus comprising: (See Kozakiewicz, pg. 14, lines 15-17, figs. 1a, item 2, i.e., computer server that is capable of certifying digital content created by an authenticated creator and verifying the authenticity of this digital content published online)
acquiring a video file including video data, audio data, and metadata, and a hash value; (See Kozakiewicz, pg. 15, lines 4-7, i.e., The software application contains instructions that when executed by a hardware processor enable communication with a distributed database server to enable the creation of the content)
generating a hash value from the audio data and the metadata; (See Kozakiewicz, pg. 7, lines 15-18, i.e., generating a first hash, HA, from the content and a first signature, SA, from the content)
performing processing of, in a case where the acquired hash value and the generated hash value match, (See Kozakiewicz, pg. 18, lines 27-29 and pg. 19, lines 1-3, i.e., hashing the created digital content ensures the integrity of that content. Thus, any modification of the content occurring after performing a hash function, changes the hash value initially assigned by the function. A comparison of similarity between the hash value initially assigned to the content and the value of hash assigned after content modification, can detect and verify any change in digital content and thus provides information on the integrity of digital content. The signature of the digital content created, being specific to the software application of the user and / or the creator, makes it possible to authenticate the identity of a content creator. The server certifies the authentication of the published digital content by comparing the at least similarity between the hash values (HA; Hp) and / or the ID number (IDNp) of the published content and the number of the identifier (IDNc) of the created content. In some embodiments, the server may further compare the similarity between the created (original) content and the published content)
registering in a block of a blockchain an identifier that uniquely identifies the video file, and the hash value; (See Kozakiewicz, pg. 7, lines 15-20, pg. 10, lines 24-29 and pg. 11, lines 1-4, i.e., transmitting first message containing the content, associated with the first hash value, HA, and the first signature, SA, to the server for registering and storing the creator and/or the content in a distributed database of a blockchain network)
and distributing to another apparatus an audio file including the audio data, in association with the identifier. (See Kozakiewicz, pg. 15, lines 21-29, pg. 16, line 4, pg. 23, lines 21-22, i.e., server carrying out the public provision of the digital content to the third party user after verifying the digital content transmitted by the creator)
Kozakiewicz fails to explicitly disclose generating a hash value without using the video data.
Hayim discloses a blockchain-based shadow images to facilitate copyright protection of digital content.
Hayim discloses generating a hash value without using the video data. (See Hayim, para. 74-75, i.e., One example for defining anchors on a stream is choosing an anchor to be every position in the stream where the string "abc" appears. Another example for defining anchors is choosing anchors to be every position in the stream where a 9-bit hash of 5 consecutive bytes is zero. A 9-bit CRC was chosen because when a CRC of five byte string is given it is easy to remove the contribution of the first byte in the string and to add a new byte at the end of the string. A 96-bit hash key is computed over the next 100 consecutive bytes. The value of the hash key returned is called "block ID". Skip a certain amount of data after finding an anchor, e.g. it is possible to skip 400 bytes or 500 bytes far from the previous anchor considered, before finding the next anchor. Accordingly, it is appreciated that a packet will hold no more than three clock IDs, and that a block of 64K will hold no more than 128 block IDs)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Kozakiewicz’s software application and computer server for creating digital content and authenticating the digital content modified with Hayim’s method for delivering data streams over communication networks. Motivation for such an implementation would enable skipping 64 bytes of video data without being used for processing the hash value. (See Hayim, para. 74-75)
Referring to the rejection of claim 13, Kozakiewicz discloses a non-transitory computer-readable storage medium storing a program for causing a computer to execute a control method for a content generation apparatus, the control method comprising: (See pg. 14, lines 23-27, i.e., A user’s portable computing device having a user software application (1a), for allowing the creation of digital content and pg. 14, lines, 28-29, i.e., The software application is able to manage memories including at least one memory of the computer hardware)
generating a video file including video data, audio data, and metadata; (See Kozakiewicz, pg. 2, lines 1-2 and pg. 9, lines 3-11, i.e., digital content being text, image, video, and the inclusion of information about the filing date and the creator)
generating a hash value from the audio data and the metadata; (See Kozakiewicz, pg. 7, lines 15-18, i.e., generating a first hash, HA, from the content and a first signature, SA, from the content)
and transmitting the hash value and the video file to a content management apparatus that registers the hash value and the metadata in a block of a blockchain. (See Kozakiewicz, pg. 7, lines 15-20, pg. 10, lines 24-29 and pg. 11, lines 1-4, i.e., transmitting first message containing the content, associated with the first hash value, HA, and the first signature, SA, to the server for registering and storing the creator and/or the content in a distributed database of a blockchain network)
Kozakiewicz fails to explicitly disclose generating a hash value without using the video data.
Hayim discloses a blockchain-based shadow images to facilitate copyright protection of digital content.
Hayim discloses generating a hash value without using the video data. (See Hayim, para. 74-75, i.e., One example for defining anchors on a stream is choosing an anchor to be every position in the stream where the string "abc" appears. Another example for defining anchors is choosing anchors to be every position in the stream where a 9-bit hash of 5 consecutive bytes is zero. A 9-bit CRC was chosen because when a CRC of five byte string is given it is easy to remove the contribution of the first byte in the string and to add a new byte at the end of the string. A 96-bit hash key is computed over the next 100 consecutive bytes. The value of the hash key returned is called "block ID". Skip a certain amount of data after finding an anchor, e.g. it is possible to skip 400 bytes or 500 bytes far from the previous anchor considered, before finding the next anchor. Accordingly, it is appreciated that a packet will hold no more than three clock IDs, and that a block of 64K will hold no more than 128 block IDs)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Kozakiewicz’s software application and computer server for creating digital content and authenticating the digital content modified with Hayim’s method for delivering data streams over communication networks. Motivation for such an implementation would enable skipping 64 bytes of video data without being used for processing the hash value. (See Hayim, para. 74-75)
Referring to the rejection of claim 14, Kozakiewicz discloses a non-transitory computer-readable storage medium storing a program for causing a computer to execute a control method for a content management apparatus, the control method comprising: (See Kozakiewicz, pg. 14, lines 15-17, figs. 1a, item 2, i.e., computer server that is capable of certifying digital content created by an authenticated creator and verifying the authenticity of this digital content published online and pg. 14, lines, 28-29, i.e., The software application is able to manage memories including at least one memory of the computer hardware)
acquiring a video file including video data, audio data, and metadata, and a hash value; (See Kozakiewicz, pg. 15, lines 4-7, i.e., The software application contains instructions that when executed by a hardware processor enable communication with a distributed database server to enable the creation of the content)
generating a hash value from the audio data and the metadata; (See Kozakiewicz, pg. 7, lines 15-18, i.e., generating a first hash, HA, from the content and a first signature, SA, from the content)
performing processing of, in a case where the acquired hash value and the generated hash value match, (See Kozakiewicz, pg. 18, lines 27-29 and pg. 19, lines 1-3, i.e., hashing the created digital content ensures the integrity of that content. Thus, any modification of the content occurring after performing a hash function, changes the hash value initially assigned by the function. A comparison of similarity between the hash value initially assigned to the content and the value of hash assigned after content modification, can detect and verify any change in digital content and thus provides information on the integrity of digital content. The signature of the digital content created, being specific to the software application of the user and / or the creator, makes it possible to authenticate the identity of a content creator. The server certifies the authentication of the published digital content by comparing the at least similarity between the hash values (HA; Hp) and / or the ID number (IDNp) of the published content and the number of the identifier (IDNc) of the created content. In some embodiments, the server may further compare the similarity between the created (original) content and the published content)
registering in a block of a blockchain an identifier that uniquely identifies the video file, and the hash value; (See Kozakiewicz, pg. 7, lines 15-20, pg. 10, lines 24-29 and pg. 11, lines 1-4, i.e., transmitting first message containing the content, associated with the first hash value, HA, and the first signature, SA, to the server for registering and storing the creator and/or the content in a distributed database of a blockchain network)
and distributing to another apparatus an audio file including the audio data, in association with the identifier. (See Kozakiewicz, pg. 15, lines 21-29, pg. 16, line 4, pg. 23, lines 21-22, i.e., server carrying out the public provision of the digital content to the third party user after verifying the digital content transmitted by the creator)
Kozakiewicz fails to explicitly disclose generating a hash value without using the video data.
Hayim discloses a blockchain-based shadow images to facilitate copyright protection of digital content.
Hayim discloses generating a hash value without using the video data. (See Hayim, para. 74-75, i.e., One example for defining anchors on a stream is choosing an anchor to be every position in the stream where the string "abc" appears. Another example for defining anchors is choosing anchors to be every position in the stream where a 9-bit hash of 5 consecutive bytes is zero. A 9-bit CRC was chosen because when a CRC of five byte string is given it is easy to remove the contribution of the first byte in the string and to add a new byte at the end of the string. A 96-bit hash key is computed over the next 100 consecutive bytes. The value of the hash key returned is called "block ID". Skip a certain amount of data after finding an anchor, e.g. it is possible to skip 400 bytes or 500 bytes far from the previous anchor considered, before finding the next anchor. Accordingly, it is appreciated that a packet will hold no more than three clock IDs, and that a block of 64K will hold no more than 128 block IDs)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Kozakiewicz’s software application and computer server for creating digital content and authenticating the digital content modified with Hayim’s method for delivering data streams over communication networks. Motivation for such an implementation would enable skipping 64 bytes of video data without being used for processing the hash value. (See Hayim, para. 74-75)
8. Claims 4 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Kozakiewicz (WO 2019233951 A1) in view of Hayim (Pub No. 2013/0346565) and in view of Gaidar et al. (Pub No. 2018/0068091).
Kozakiewicz in view of Hayim discloses the invention as disclosed above, however, Kozakiewicz in view of Hayim fail to explicitly disclose perform trimming processing of removing silence or noise that continues for a certain period of time from the audio data, and the hash value is generated from the audio data subjected to the trimming processing and the metadata.
Gaider et al. discloses a blockchain-based shadow images to facilitate copyright protection of digital content.
Referring to the rejection of claims 4 and 9, Kozakiewicz in view of Gaidar et al. discloses wherein the at least one processor executes the instructions to perform trimming processing of removing silence or noise that continues for a certain period of time from the audio data, and the hash value is generated from the audio data subjected to the trimming processing and the metadata. (See Gaidar et al., para. 53, i.e., for an audio file, they may hash a subset of the audio stream, according to a predetermined set of offsets and lengths and for a video file, they may hash portions of the video and audio tracks)
*Hashing a subset of the audio stream or portions of the audio tracks merely corresponds to a known used feature in the field.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Kozakiewicz and Hayim’s software application and computer server for creating digital content and authenticating the digital content modified with Gaidar et al.’s blockchain-based shadow images to facilitate copyright protection of digital content. Motivation for such an implementation would enable different hashing algorithms to be used for hashing a subset of the audio stream or portions of the audio tracks. (See Gaider et al., para. 53)
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY D FIELDS whose telephone number is (571)272-3871. The examiner can normally be reached IFP M-F 8am-4: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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/COURTNEY D FIELDS/Examiner, Art Unit 2436 September 30, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights