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
This communication is a Final Office Action in response to communications received on 10/27/25.
Claims 6, 14 are cancelled.
Claims 1,9,17-18 are amended.
Claims 21-22 are added
Therefore, Claims 1-5, 7-13, 15-22 are pending and have been addressed below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-5, 7-13, 15-22 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Step 1: Identifying Statutory Categories
In the instant case, claims 1-5, 7-8, 21 are directed to a system, claims 9-13, 15-16, 17, 18-20, 22 are directed to a method. Thus, the claims fall within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A: Prong 1 Identifying a Judicial Exception
Under Step 2A, prong 1, Claims 1-5, 7-13, 15-22 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 9, 17 and 18 recite methods for validating store information including generating metadata related to the recording or transcript; computing a hash of at least the recording or transcript, or metadata; wherein the hash is indexed by at least a portion of the metadata; using the at least a portion of the metadata, retrieving the hash; retrieving the hash, re-computing the hash of the recording or transcript; comparing the retrieved hash to the re-computed hash or the hash retrieved; if the retrieved hash matches the re-computed hash or the hash retrieved, generating a first output comprising an indication that the recording or transcript is validated; and if the retrieved hash does not match the re-computed hash or the hash retrieved, generating a second output comprising an indication that the recording or transcript is not validated (Claims 1, 9, 17, 18); performing steps to transform the piece of electronic evidence into a transformed piece of electronic evidence(Claim 17)
These limitations as drafted, are a process that, under its broadest reasonable interpretation, covers methods of organizing human activity (including commercial interactions such as business relations, managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) including interaction between person and computer), but for the recitation of generic computer components. That is, other than reciting the structural elements (such as a processor and a memory, hash function, blockchain, computer (Claims 1, 9, 17, 18)), the claims are directed to validating stored information related to a contact session/electronic evidence/data structure. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation of organizing human activity but for the recitation of generic computer components, the claim recites an abstract idea.
Step 2A Prong 2 - This judicial exception is not integrated into a practical application because the claim merely describes how to generally “apply” the concept of receiving data, analyzing it, and providing validation. In particular, the claims only recites the additional elements – a processor and a memory, hash function, blockchain, computer. The additional elements are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). Simply implementing the abstract idea on generic components is not a practical application of the abstract idea. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
In addition, limitations reciting data gathering such as “receiving a recording or transcript; receiving metadata (Claims 1, 9); receiving the piece of electronic evidence/data structure; receiving data (Claim 17, 18) “ are insignificant pre-solution activity that merely gather data and, therefore, do not integrate the exception into a practical application for that additional reason. See In re Bilski, 545 F.3d 943, 963 (Fed. Cir. 2008) (en bane), aff’d on other grounds, 561 U.S. 593 (2010) (characterizing data gathering steps as insignificant extra-solution activity); see also CyberSource, 654 F.3d at 1371-72 (noting that even if some physical steps are required to obtain information from a database (e.g., entering a query via a keyboard, clicking a mouse), such data-gathering steps cannot alone confer patentability); GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015) (presenting offers and gathering statistics amounted to mere data gathering). Accord Guidance, 84 Fed. Reg. at 55 (citing MPEP § 2106.05(g)). Also, the limitations reciting “storing the recording, transcript, metadata in memory; storing the hash in different memory (Claims 1, 9); storing the evidence..; storing the hash.. (Claims 17, 18)” are merely a post-solution step of storing data—a nominal addition to the claim that does not meaningfully limit the claim. Therefore, these steps are insignificant extra-solution activity. See MPEP 2106.05(g).
The claims are directed to an abstract idea. When considered in combination, the claims do not amount to improvements to the functioning of a computer, or to any other technology or technical field, as discussed in MPEP 2106.05(a), applying the judicial exception with, or by use of, a particular machine, as discussed in MPEP 2106.05(b), effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP 2106.05(c), or applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception, as discussed in MPEP 2106.05(e). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they does not impose any meaningful limits on practicing the abstract idea. Therefore, the claims are directed to an abstract idea.
Step 2B: Considering Additional Elements
The claimed invention is directed to an abstract idea without significantly more. The claim does not include additional elements that are sufficient to amount significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the claims describe how to generally “apply” to; provide validation for stored information. The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The independent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea. The claims are not patent eligible. The dependent claim(s) when analyzed as a whole are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea. The dependent claims are not significantly more because they are part of the identified judicial exception. See MPEP 2106.05(g). The claims are not patent eligible. With respect to a processor and a memory, hash function, blockchain, computer these limitations are described in Applicant’s own specification as generic and conventional elements. See Applicants specification, Paragraph [0110] details “ processor circuit 1050 may be implemented in the contact verification system 200, or other devices or workstations (e.g., third-party workstations, network routers, etc.), or on a cloud processor or other remote processing unit. The processor circuit 1050 may include a processor 1060, a memory 1064, and a communication module 1068. These elements may be in direct or indirect communication with each other, for example via one or more buses., [0111]general purpose computing devices.” These are basic computer elements applied merely to carry out data processing such as, discussed above, receiving, analyzing, transmitting and displaying data. As discussed in Step 2A, Prong Two above, the recitations of “receiving steps” and “storing steps” amount to receiving or storing/transmitting data over a network and are well understood, routine, conventional activity. See MPEP 2106.05(d), subsection II. Furthermore, the use of such generic computers to receive or transmit data over a network has been identified as a well understood, routine and conventional activity by the courts. See Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AVAuto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93, OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result-a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); Also see MPEP 2106.05(d) discussing elements that the courts have recognized as well-understood, routine and conventional activities in particular fields. Lastly, the additional elements provides only a result-oriented solution which lacks details as to how the computer performs the claimed abstract idea. Therefore, the additional elements amount to mere instructions to apply the exception. See MPEP 2106.05(f). Further the limitation of a hash function/blockchain are recited at high level of generality and is similar to Sachs (US2021/0294920) disclosing hash function ([0041], blockchain[0013]).
Furthermore, these steps/components are not explicitly recited and therefore must be construed at the highest level of generality and amount to mere instructions to implement the abstract idea on a computer. Therefore, the claimed invention does not demonstrate a technologically rooted solution to a computer-centric problem or recite an improvement to another technology or technical field, an improvement to the function of any computer itself, applying the exception with, or by use of, a particular machine, effect a transformation or reduction of a particular article to a different state or thing, add a specific limitation other than what is well-understood, routine and conventional in the field, add unconventional steps that confine the claim to a particular useful application, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment such as computing. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. Taking the additional claimed elements individually and in combination, the computer components at each step of the process perform purely generic computer functions. Viewed as a whole, the claims do not purport to improve the functioning of the computer itself, or to improve any other technology or technical field. Use of an unspecified, generic computer does not transform an abstract idea into a patent-eligible invention. Thus, the claims do not amount to significantly more than the abstract idea itself.
Dependent claims 2-5, 7-8, 9-13, 15-16, and 19-22 add additional limitations, but these only serve to further limit the abstract idea, and hence are nonetheless directed towards fundamentally the same abstract idea as Independent claims.
Claims 2-3,5-6 10-11, 13-14, 19-22 recites the recording includes at least one of a voice recording of the contact session or a recording of screen activity of the contact session; wherein the transcript includes a recording of at least one of a text interaction, a text translation of a voice interaction, or a text translation of computer screen activity; the metadata includes at least one of a date, a time, a unique contact identifier, a phone number, a contact center agent identifier, an email address, a social media identifier, or a contact duration; wherein the first output comprises an indication that the recording or transcript is validated, and the second output comprises an indication that the recording or transcript is not validated; wherein the electronic data structure comprises a recording or transcript of a customer interaction or a piece of electronic evidence; data comprises metadata or processing steps. These limitations further limit the abstract idea of independent claim by further defining data included in recording/evidence. The claims do not provide any new additional elements beyond abstract idea. Therefore, whether analyzed individually or as an ordered combination, they fail to integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claims4 and 12 recites the hash function comprises a one-way hash function. This limitations further limit the abstract idea of independent claim by further defining type of hash function at high level of generality. The claims do not provide any new additional elements beyond abstract idea. Therefore, whether analyzed individually or as an ordered combination, they fail to integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Claims 7-9, 15-16 recites wherein the blockchain is a public blockchain, a smart contract includes at least a portion of the method, and the method further comprises: paying a usage fee for the public blockchain; and charging a customer for the usage fee; wherein the blockchain is a private blockchain, a smart contract includes at least a portion of the method, and the method further comprises: charging a customer a usage fee for the private blockchain. These limitations merely adds the words apply it (or an equivalent) with the judicial exception , or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea as discussed in MPEP 2106.05(f). The claims do not provide any new additional elements beyond abstract idea. Therefore, whether analyzed individually or as an ordered combination, they fail to integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Therefore, the dependent claims do not integrate into a practical application. As such, the additional elements individually or in combination do not integrate the exception into a practical application, but rather, the recitation of any additional element amounts to merely reciting the words “apply it” (or equivalent) with the judicial exception, or merely includes instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (See MPEP 2106.05(f)). The dependent claims also do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are merely used to apply the abstract idea to a technological environment. These limitations do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of the abstract idea to a particular technological environment. See MPEP 2106.05d. Thus, the claims do not add significantly more to an abstract idea. The claims are ineligible. Therefore, since there are no limitations in the claim that transform the exception into a patent eligible application such that the claim amounts to significantly more than the exception itself, the claims are rejected under 35 USC 101 as being directed to non-statutory subject matter. See (Alice Corporation Pty. Ltd. v. CLS Bank International, et al.).
Claim Rejections - 35 USC § 103
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 9-13, 17-22 are rejected under 35 U.S.C. 103 as being unpatentable over Adibi (US 2021/0135856 A1) in view of Sachs (US 2021/0294920A1), further in view of Ogawa (US 2022/0189589A1)
Regarding Claims 1, 9, Adibi discloses the system adapted to automatically validate stored information related to a contact session ([0003] A cloud-based contact center solution is also further enhanced by the incorporation and utilization of blockchain technology to store contact data and secure the data using asymmetric cryptography for additional security, signature authentication, and so forth.), the system comprising:
Adibi discloses a processor and a non-transitory computer readable medium ([0052] The blockchain provider system(s) 304 may individually include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor) operably coupled thereto, the computer readable medium comprising a plurality of instructions stored in association therewith that are accessible to, and executable by, the processor, to perform blockchain application operations ([0004] a contact center to store data related to a consumer in a blockchain.) which comprise in real time ([0029] Real-time communication services include Internet Protocol (IP) telephony, call control, instant messaging (IM)/chat, presence information, real-time video and data sharing): via a private branch exchange ([0023] a customer calling on telephone handset may connect through the PSTN and terminate on a private branch exchange (PBX))
Adibi discloses receiving an electronic recording or transcript of a contact session (Fig 4 #410-430 create a record of communication with customer, [0030] Recording applications may be used to capture and play back audio and screen interactions between customers and agents. Recording systems should capture everything that happens during interactions and what agents do on their desktops. [0034] collection of historical interaction recordings, [00076] FIG. 4, at 410 a contact center receives an incoming communication from a consumer, and at 420 the contact center concludes the communication in order to create a record of the communication at 430, encrypt the record using asymmetric cryptography at 440, and update the blockchain with the record of communication at block 450 [0034]The database of potential intents and the keywords corresponding to the intents may be automatically mined from a collection of historical interaction recordings, in which a customer may provide a statement of the issue, and in which the intent is explicitly encoded by an agent.);
Adibi discloses receiving or generating metadata related to the recording or transcript ([0034] The intent inference module of the application 200 automatically infers the customer's 110 intent from the text of the user input using artificial intelligence or machine learning techniques. These artificial intelligence techniques may include, for example, identifying one or more keywords from the user input and searching a database of potential intents (e.g., call reasons) (metadata) corresponding to the given keywords. The database of potential intents and the keywords corresponding to the intents may be automatically mined from a collection of historical interaction recordings, [0038] metadata regarding the conversation is displayed to the customer 110 and/or agent 120 in the UI throughout the interaction. Information );
Adibi discloses storing the recording, transcript, and metadata in a memory ([0076] a contact center to store data in a blockchain corresponding to an incoming communication from a consumer. In FIG. 4, at 410 a contact center receives an incoming communication from a consumer, and at 420 the contact center concludes the communication in order to create a record of the communication at 430);
Adibi discloses with a hash function, computing a hash of at least the recording, transcript, or metadata ([0042] using several concepts from cryptography such as digital signatures and hash functions. To create a blockchain block, a checksum is calculated over a defined block of data using special hash functions that are designed to return a value of a defined length (the hash value or “message digest”, [0045] In blockchain, blocks hold batches of valid transactions that are hashed and encoded into a defined structure such as a Merkle tree. Each block in the blockchain includes the cryptographic hash of the prior block in the blockchain, logically linking both blocks to form part of a larger chain of blocks, [0076]encrypt the record using asymmetric cryptography at 440, and update the blockchain with the record of communication at block 450., [0113] one or more data fields may be used to calculate a hash value.);
Adibi discloses via a blockchain network comprising a validator nodes ([0107] Blocks may be appended to a blockchain by an appropriate node after it completes the block and the block is validated. In embodiments of the invention, a blockchain may be distributed, and a copy of the blockchain may be maintained at each node in a verification network. Any node within the verification network may subsequently use the blockchain to verify transactions.): storing the hash in a blockchain different from the memory, wherein the hash is indexed within the blockchain by at least a portion of the metadata (Fig 4 # 450 update blockchain with communication record, [0107] A blockchain may include a number of blocks of interaction records. Each block in the blockchain can contain also include a timestamp and a link to a previous block. For example, each block may include or be appended to a hash of the previous block. );
Adibi does not specifically teach using the at least a portion of the metadata, retrieving the hash from the blockchain; retrieving the hash from the memory or, with the hash function, re-computing the hash of the recording, transcript, or metadata; comparing the retrieved hash to the re-computed hash or the hash retrieved from the memory; if the retrieved hash matches the re-computed hash or the hash retrieved from the memory, generating a first output comprising an indication that the recording or transcript is validated; and if the retrieved hash does not match the re-computed hash or the hash retrieved from the memory, generating a second output comprising an indication that the recording or transcript is not validated. Adibi, however teaches one or more data fields may be used to calculate a hash value. A private key may be utilized by a cryptographic algorithm to sign the hash value such that another electronic device may utilize a public key to verify the signature and the verified values may be compared to the unencrypted data transfer request/response message payload to determine validity and integrity of the data transfer request/response message.([0113])
Sachs teaches using the at least a portion of the metadata, retrieving the hash from the blockchain ([0076] If a user knows the evidence identifier and/or a hash code computed from an evidence data file, the user can search the blockchain 12 for the evidence identifier and/or the hash code.); retrieving the hash from the memory or, with the hash function, re-computing the hash of the recording, transcript, or metadata ([0062]-[0063] a hash code computed from the transformed evidence data (recomputed hash) file 10, [0064] data indicative of the transformation operation 9, and [0065] a timestamp indicating the time at which the transformation operation 9 was performed.); comparing the retrieved hash to the re-computed hash or the hash retrieved from the memory; if the retrieved hash matches the re-computed hash or the hash retrieved from the memory, generating a first output ([0076] If the blockchain 12 includes a block with the identifier and the hash code then data in the blockchain confirms for certain that the evidence data file corresponds to an evidence data file which has been processed by the system 1 and that the evidence data file can be traced back (match/compare) to an original evidence data file that was input into the system 1. The user can therefore trust the evidence data file as being authentic, [0077] The processor 2 identifies the item of evidence based on the evidence identifier and transmits the evidence data file or a transformed evidence data file corresponding to the item of evidence to the client computing device 7. The client computing device 7 is configured to display the evidence on the screen 8., [0079] the system 1 is configured to display an authenticity indicator to a user on the display screen 8 simultaneously with an image of the requested evidence, [0080] The authenticity indicator provides a confirmation to the user that the evidence displayed on the display screen 8 is authentic since the evidence is verified as being authentic by the data in the blockchain 12, [0081] the authenticity indicator displayed on the display screen 8 is truly reflective of the data on the blockchain and hence that no tampering has occurred prior to displaying the authenticity indicator on the display screen) comprising an indication that the recording or transcript is validated ([0079] the system 1 is configured to display an authenticity indicator to a user on the display screen 8 simultaneously with an image of the requested evidence, [0080] The authenticity indicator provides a confirmation to the user that the evidence displayed on the display screen 8 is authentic since the evidence is verified as being authentic by the data in the blockchain 12, [0081] the authenticity indicator displayed on the display screen 8 is truly reflective of the data on the blockchain and hence that no tampering has occurred prior to displaying the authenticity indicator on the display screen 8.); and if the retrieved hash does not match the re-computed hash or the hash retrieved from the memory, generating a second output ([0076] any tampering to the evidence data file would change the hash code of the evidence data file such that the hash code no longer matches a hash code in the blockchain 12., [0077] The processor 2 identifies the item of evidence based on the evidence identifier and transmits the evidence data file or a transformed evidence data file corresponding to the item of evidence to the client computing device 7.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included using the at least a portion of the metadata, retrieving the hash from the blockchain; retrieving the hash from the memory or, with the hash function, re-computing the hash of the recording, transcript, or metadata; comparing the retrieved hash to the re-computed hash or the hash retrieved from the memory; if the retrieved hash matches the re-computed hash or the hash retrieved from the memory, generating a first output comprising an indication that the recording or transcript is validated; and if the retrieved hash does not match the re-computed hash or the hash retrieved from the memory, generating a second output, as disclosed by Sachs in the system disclosed by Adibi, for the motivation of providing a method of matching hash code to trace back to an original evidence data file, therefore trusting the evidence data file as being authentic since any tampering to the evidence data file would change the hash code of the evidence data file such that the hash code no longer matches a hash code in the blockchain 12. ([0076] Sachs)
Adibi/Sachs does not specifically teach the second output comprising an indication that the recording or transcript is not validated.
Ogawa teaches the second output comprising an indication that the recording or transcript is not validated. ([0092] if there is highly reliable data of the examinee that has been forged or tampered with, the transaction management system 2 judges that it is not highly reliable data of the examinee that has been set by the examinee himself/herself via the examinee terminal 4, and/or that the desired conditions regarding the transactions of reliable data are not met, and does not transact the highly reliable data., [0312] If the hashed data 21 output from the examinee terminal 4 has been tampered with, for example, based on the hash data of the acquired data 20b acquired immediately before and the latest acquired data 20c, no new hash data corresponding to the latest acquired data 20c will be generated., [0331] when acquired data 20 is replaced with tampered data in the middle of acquiring the acquired data 20, the value of the original acquired data for generating the hash data will be different. Since different hash data is generated in the examinee terminal 4, by comparing these data, the examinee terminal 4, the transaction management system 2, or the highly reliable data storage system 7 can identify tampered or tampered hash data.(not validated))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the second output comprising an indication that the recording or transcript is not validated, as disclosed by Ogawa in the system disclosed by Adibi/Sachs, for the motivation of providing a method of identifying if data has been tampered by comparing the hash data ([0031] Ogawa)
Regarding Claims 2 and 10, Adibi as modified by Sachs/Ogawa teaches the system of claim 1 and method of claim 9,
Adibi teaches wherein the recording includes at least one of a voice recording of the contact session or a recording of computer screen activity of the contact session. ([0030] Recording applications may be used to capture and play back audio and screen interactions between customers and agents. Recording systems should capture everything that happens during interactions and what agents do on their desktops. Surveying tools may provide the ability to create and deploy post-interaction customer feedback surveys in voice and digital channels, [0034] The database of potential intents and the keywords corresponding to the intents may be automatically mined from a collection of historical interaction recordings, in which a customer may provide a statement of the issue, and in which the intent is explicitly encoded by an agent.)
Regarding Claims 3 and 11, Adibi as modified by Sachs/Ogawa teaches the system of claim 1 and method of claim 9,
Adibi teaches wherein the transcript includes a recording of at least one of a text interaction, a text translation of a voice interaction, or a text translation of computer screen activity. ([0030] Recording applications may be used to capture and play back audio and screen interactions between customers and agents. Recording systems should capture everything that happens during interactions and what agents do on their desktops, [0033] The user input may be provided as free speech or text (e.g., unstructured, natural language input). This information may be used by the application 200 for routing the customer 110 to an agent 120, to automated resources in the contact center 150, as well as gathering information from other sources to be provided to the agent 120. In operation, the application 200 may parse the natural language user input using a natural language processing module from the system 200 to infer the customer's intent using an intent inference module in order to classify the intent, [0107] A blockchain may include a number of blocks of interaction records. Each block in the blockchain can contain also include a timestamp and a link to a previous block. For example, each block may include or be appended to a hash of the previous block. )
Regarding Claims 4 and 12, Adibi as modified by Sachs/Ogawa teaches the system of claim 1 and method of claim 9,
Adibi teaches the hash function. ([0042] cryptography such as digital signatures and hash functions. To create a blockchain block, a checksum is calculated over a defined block of data using special hash functions that are designed to return a value of a defined length (the hash value or “message digest”) which is not dependent on the length of the input (i.e., the defined block of data) but which does provide the same output when provided with the same input.). However, Adibi/Sachs do not specifically teach a one-way hash function
Sachs teaches a hash function ([0041] The hash code is computed from the evidence data file by processing the evidence data file with a hashing algorithm. In some embodiments, the hashing algorithm is selected from a group including, but not limited to, MD5, SHA-1, SHA-2, SHA-224, SHA-256 (type of one-way hash), SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA-3, SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128 or SHAKE256. [0054] The block which is stored in the blockchain represents the evidence identifier and the hash code computed from the original evidence data file and the content of the original evidence data file is not derivable from this information. (one-way))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included a one-way hash function, as disclosed by Sachs in the system disclosed by Adibi, for the motivation of providing a method of matching hash code to trace back to an original evidence data file, therefore trusting the evidence data file as being authentic since any tampering to the evidence data file would change the hash code of the evidence data file such that the hash code no longer matches a hash code in the blockchain 12. file and the content of the original evidence data file is not derivable from hash information ([0041], [0076] Sachs)
Regarding Claims 5 and 13, Adibi as modified by Sachs/Ogawa teaches the system of claim 1 and method of claim 9,
Adibi teaches wherein the metadata includes at least one of a date, a time, a unique contact identifier, a phone number, a contact center agent identifier, an email address, a social media identifier, or a contact duration. ([0038] once an interaction, such as through a phone call, has been initiated with the agent 120, metadata regarding the conversation is displayed to the customer 110 and/or agent 120 in the UI throughout the interaction. Information, such as call metadata, may be presented to the customer 110 through the UI 205 on the customer's 110 mobile device 105. Examples of such information might include, but not be limited to, the provider, department call reason, agent name, and a photo of the agent. [0107]A blockchain may include a number of blocks of interaction records. Each block in the blockchain can contain also include a timestamp (metadata) and a link to a previous block. For example, each block may include or be appended to a hash of the previous block., [0020] extract data about the customer interaction such as the caller's telephone number (often known as the automatic number identification (ANI) number), or the customer's internet protocol (IP) address, or email address, and communicate with other contact center components in processing the interaction. )
Regarding Claims 17 and 18, Adibi discloses the computer-implemented method adapted to automatically validate a chain of custody related to electronic evidence/data structure ([0003] A cloud-based contact center solution is also further enhanced by the incorporation and utilization of blockchain technology to store contact data and secure the data using asymmetric cryptography for additional security, signature authentication, and so forth.), the system comprising, in real time with an evidence-handling computer comprising a processor and a non-transitory computer readable medium operatively coupled thereto: via a network ([0004] a contact center to store data related to a consumer in a blockchain, [0029] Real-time communication services include Internet Protocol (IP) telephony, call control, instant messaging (IM)/chat, presence information, real-time video and data sharing, Fig. 6 #1002 processing unit)
Adibi discloses receiving the piece of electronic evidence/data structure (Fig 4 #410-430 create a record of communication with customer, [0030] Recording applications may be used to capture and play back audio and screen interactions between customers and agents. Recording systems should capture everything that happens during interactions and what agents do on their desktops. (electronic evidence/data structure) [0034] collection of historical interaction recordings, [00076] FIG. 4, at 410 a contact center receives an incoming communication from a consumer, and at 420 the contact center concludes the communication in order to create a record of the communication at 430, encrypt the record using asymmetric cryptography at 440, and update the blockchain with the record of communication at block 450 [0034]The database of potential intents and the keywords corresponding to the intents may be automatically mined from a collection of historical interaction recordings, in which a customer may provide a statement of the issue, and in which the intent is explicitly encoded by an agent.);
Adibi discloses receiving or generating metadata related to the electronic evidence/data structure ([0034] The intent inference module of the application 200 automatically infers the customer's 110 intent from the text of the user input using artificial intelligence or machine learning techniques. These artificial intelligence techniques may include, for example, identifying one or more keywords from the user input and searching a database of potential intents (e.g., call reasons) (metadata) corresponding to the given keywords. The database of potential intents and the keywords corresponding to the intents may be automatically mined from a collection of historical interaction recordings, [0038] metadata regarding the conversation is displayed to the customer 110 and/or agent 120 in the UI throughout the interaction. Information );
Adibi discloses storing the recording, transcript, and metadata in a memory ([0076] a contact center to store data in a blockchain corresponding to an incoming communication from a consumer. In FIG. 4, at 410 a contact center receives an incoming communication from a consumer, and at 420 the contact center concludes the communication in order to create a record of the communication at 430);
Adibi discloses with a hash function, computing a hash of at least the recording, transcript, or metadata ([0042] using several concepts from cryptography such as digital signatures and hash functions. To create a blockchain block, a checksum is calculated over a defined block of data using special hash functions that are designed to return a value of a defined length (the hash value or “message digest”, [0045] In blockchain, blocks hold batches of valid transactions that are hashed and encoded into a defined structure such as a Merkle tree. Each block in the blockchain includes the cryptographic hash of the prior block in the blockchain, logically linking both blocks to form part of a larger chain of blocks, [0076]encrypt the record using asymmetric cryptography at 440, and update the blockchain with the record of communication at block 450., [0113] one or more data fields may be used to calculate a hash value.);
Adibi discloses via a blockchain network comprising a validator nodes ([0107] Blocks may be appended to a blockchain by an appropriate node after it completes the block and the block is validated. In embodiments of the invention, a blockchain may be distributed, and a copy of the blockchain may be maintained at each node in a verification network. Any node within the verification network may subsequently use the blockchain to verify transactions.): storing the hash in a blockchain different from the memory, wherein the hash is indexed within the blockchain by at least a portion of the metadata (Fig 4 # 450 update blockchain with communication record, [0107] A blockchain may include a number of blocks of interaction records. Each block in the blockchain can contain also include a timestamp and a link to a previous block. For example, each block may include or be appended to a hash of the previous block. );
Adibi does not specifically teach electronic evidence; performing steps to transform the piece of electronic evidence into a transformed piece of electronic evidence; storing the piece of electronic evidence, the steps, the transformed piece of electronic evidence and he metadata in a memory; using the at least a portion of the metadata, retrieving the hash from the blockchain; retrieving the hash from the memory or, with the hash function, re-computing the hash of the electronic evidence/data structure, or metadata; comparing the retrieved hash to the re-computed hash or the hash retrieved from the memory; if the retrieved hash matches the re-computed hash or the hash retrieved from the memory, generating a first output comprising an indication that the recording or transcript is validated; and if the retrieved hash does not match the re-computed hash or the hash retrieved from the memory, generating a second output comprising an indication that the recording or transcript is not validated. Adibi, however teaches one or more data fields may be used to calculate a hash value. A private key may be utilized by a cryptographic algorithm to sign the hash value such that another electronic device may utilize a public key to verify the signature and the verified values may be compared to the unencrypted data transfer request/response message payload to determine validity and integrity of the data transfer request/response message.([0113])
Sachs teaches electronic evidence (Abstract lines 1-3 receiving an evidence data file (5), the evidence data file (5) being identified by: an evidence identifier, and a hash code computed from the evidence data file (5); generating a block (11) for the blockchain); performing steps to transform the piece of electronic evidence into a transformed piece of electronic evidence ([0013] performing a transformation operation on the evidence data file to produce a transformed evidence data file; generating the block for the blockchain by further combining data indicative of: the transformation operation, and a timestamp indicating the time at which the transformation operation was performed, [0015] each transformation operation comprises converting an evidence data file document into a Portable Document Format (PDF) file.); storing the piece of electronic evidence, the steps, the transformed piece of electronic evidence and he metadata in a memory ([0013] generating the block for the blockchain by further combining data indicative of: the transformation operation, and a timestamp indicating the time at which the transformation operation was performed [0014] performing a plurality of transformation operations on the evidence data file to produce the transformed evidence data file.); using the at least a portion of the metadata, retrieving the hash from the blockchain ([0076] If a user knows the evidence identifier and/or a hash code computed from an evidence data file, the user can search the blockchain 12 for the evidence identifier and/or the hash code.); retrieving the hash from the memory or, with the hash function, re-computing the hash of the electronic evidence/data structure, or metadata ([0062]-[0063] a hash code computed from the transformed evidence data (recomputed hash) file 10, [0064] data indicative of the transformation operation 9, and [0065] a timestamp indicating the time at which the transformation operation 9 was performed.); comparing the retrieved hash to the re-computed hash or the hash retrieved from the memory; if the retrieved hash matches the re-computed hash or the hash retrieved from the memory, generating a first output ([0076] If the blockchain 12 includes a block with the identifier and the hash code then data in the blockchain confirms for certain that the evidence data file corresponds to an evidence data file which has been processed by the system 1 and that the evidence data file can be traced back (match/compare) to an original evidence data file that was input into the system 1. The user can therefore trust the evidence data file as being authentic, [0077] The processor 2 identifies the item of evidence based on the evidence identifier and transmits the evidence data file or a transformed evidence data file corresponding to the item of evidence to the client computing device 7. The client computing device 7 is configured to display the evidence on the screen 8., [0079] the system 1 is configured to display an authenticity indicator to a user on the display screen 8 simultaneously with an image of the requested evidence, [0080] The authenticity indicator provides a confirmation to the user that the evidence displayed on the display screen 8 is authentic since the evidence is verified as being authentic by the data in the blockchain 12, [0081] the authenticity indicator displayed on the display screen 8 is truly reflective of the data on the blockchain and hence that no tampering has occurred prior to displaying the authenticity indicator on the display screen 8.) comprising an indication that the recording or transcript is validated ([0079] the system 1 is configured to display an authenticity indicator to a user on the display screen 8 simultaneously with an image of the requested evidence, [0080] The authenticity indicator provides a confirmation to the user that the evidence displayed on the display screen 8 is authentic since the evidence is verified as being authentic by the data in the blockchain 12, [0081] the authenticity indicator displayed on the display screen 8 is truly reflective of the data on the blockchain and hence that no tampering has occurred prior to displaying the authenticity indicator on the display screen 8.); and if the retrieved hash does not match the re-computed hash or the hash retrieved from the memory, generating a second output ([0076] any tampering to the evidence data file would change the hash code of the evidence data file such that the hash code no longer matches a hash code in the blockchain 12., [0077] The processor 2 identifies the item of evidence based on the evidence identifier and transmits the evidence data file or a transformed evidence data file corresponding to the item of evidence to the client computing device 7.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included electronic evidence; performing steps to transform the piece of electronic evidence into a transformed piece of electronic evidence; storing the piece of electronic evidence, the steps, the transformed piece of electronic evidence and he metadata in a memory; using the at least a portion of the metadata, retrieving the hash from the blockchain; retrieving the hash from the memory or, with the hash function, re-computing the hash of the electronic evidence/data structure, or metadata; comparing the retrieved hash to the re-computed hash or the hash retrieved from the memory; if the retrieved hash matches the re-computed hash or the hash retrieved from the memory, generating a first output generating a first output comprising an indication that the recording or transcript is validated; and if the retrieved hash does not match the re-computed hash or the hash retrieved from the memory, generating a second output, as disclosed by Sachs in the system disclosed by Adibi, for the motivation of providing a method of matching hash code to trace back to an original evidence data file, therefore trusting the evidence data file as being authentic since any tampering to the evidence data file would change the hash code of the evidence data file such that the hash code no longer matches a hash code in the blockchain 12. ([0076] Sachs)
Adibi/Sachs does not specifically teach the second output comprising an indication that the recording or transcript is not validated.
Ogawa teaches the second output comprising an indication that the recording or transcript is not validated. ([0092] if there is highly reliable data of the examinee that has been forged or tampered with, the transaction management system 2 judges that it is not highly reliable data of the examinee that has been set by the examinee himself/herself via the examinee terminal 4, and/or that the desired conditions regarding the transactions of reliable data are not met, and does not transact the highly reliable data., [0312] If the hashed data 21 output from the examinee terminal 4 has been tampered with, for example, based on the hash data of the acquired data 20b acquired immediately before and the latest acquired data 20c, no new hash data corresponding to the latest acquired data 20c will be generated., [0331] when acquired data 20 is replaced with tampered data in the middle of acquiring the acquired data 20, the value of the original acquired data for generating the hash data will be different. Since different hash data is generated in the examinee terminal 4, by comparing these data, the examinee terminal 4, the transaction management system 2, or the highly reliable data storage system 7 can identify tampered or tampered hash data.(not validated))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the second output comprising an indication that the recording or transcript is not validated, as disclosed by Ogawa in the system disclosed by Adibi/Sachs, for the motivation of providing a method of identifying if data has been tampered by comparing the hash data ([0031] Ogawa)
Regarding Claim 19, Adibi as modified by Sachs/Ogawa teaches the computer-implemented method of claim 18,
Adibi teaches wherein the electronic data structure comprises a recording or transcript of a customer interaction or a piece of electronic evidence.( [00076] FIG. 4, at 410 a contact center receives an incoming communication from a consumer, and at 420 the contact center concludes the communication in order to create a record of the communication at 430, encrypt the record using asymmetric cryptography at 440, and update the blockchain with the record of communication at block 450).
Further, Sachs teaches a piece of electronic evidence (Abstract managing digital evidence using a blockchain. Receiving an evidence data file (5), the evidence data file (5) being identified by: an evidence identifier, and a hash code computed from the evidence data file (5); generating a block (11) for the blockchain)
Regarding Claim 20, Adibi as modified by Sachs/Ogawa teaches the computer-implemented method of claim 18,
Adibi teaches wherein the data comprises metadata or processing steps ([0034] The intent inference module of the application 200 automatically infers the customer's 110 intent from the text of the user input using artificial intelligence or machine learning techniques. These artificial intelligence techniques may include, for example, identifying one or more keywords from the user input and searching a database of potential intents (e.g., call reasons) (metadata) corresponding to the given keywords. The database of potential intents and the keywords corresponding to the intents may be automatically mined from a collection of historical interaction recordings, [0038] metadata regarding the conversation is displayed to the customer 110 and/or agent 120 in the UI throughout the interaction. Information.
Regarding claims 21-22, (New) Adibi as modified by Sachs/Ogawa teaches the system of claim 1 and method of claim 9,
Abidi teaches wherein a contact center computer comprises the processor (Fig 6 # 1002 processing unit, [0052] The blockchain provider system(s) 304 may individually include a processor and a computer readable medium coupled to the processor, the computer readable medium comprising code, executable by the processor)
Claims 7-8, 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Adibi (US 2021/0135856 A1) in view of Sachs (US 2021/0294920A1) further in view of Ogawa (US 2022/0189589A1) as applied to claims 1 and 9, further in view of Jayachandran et al. (US 2018/0137507A1)
Regarding Claims 7 and 15. Adibi as modified by Sachs/Ogawa teaches the system of claim 1 and method of claim 9,
Adibi teaches wherein the blockchain is a public blockchain ([0042] Blockchain is a method of storing a list of entries which cannot be changed easily after they are created by using several concepts from cryptography such as digital signatures and hash functions., [0043], blockchain is typically implemented as a decentralized, distributed, and public digital ledger used to record transactions across many computers where the records associated with the blockchain cannot be surreptitiously altered retroactively (that is, after the records are committed), a smart contract includes at least some of the operations ([0049] blockchain can also be used for “smart contracts” that can be partially or fully executed and/or enforced without human interaction, with one of the main objectives for smart contract being an automated escrow. ), and
Adibi/Sachs do not specifically teach the operations further comprise: paying a usage fee for the public blockchain; and charging a customer for the usage fee.
Jayachandran teaches paying a usage fee for the public blockchain; and charging a customer for the usage fee. ([0017] A seller(s) is an entity which has a copy of the desired digital content and will transfer it to a buyer in various situations (for example, a fee is paid). A buyer(s) is an entity interested in acquiring data (for example, digital content) by paying the necessary fees., [0018] A service fee (usage fee) can be charged for providing a validation and recommendation service on the blockchain. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included paying a usage fee for the public blockchain; and charging a customer for the usage fee, as disclosed by Jayachandran in the system disclosed by Adibi/Sachs, for the motivation of providing a validation and recommendation service on the blockchain for a service fee and enabling verifiability and non-reputability of digital asset exchange in distributed settings using the blockchain for recording protocol operations.([0018] Jayachandran)
Regarding Claims 8 and 16, Adibi as modified by Sachs/Ogawa teaches the system of claim 1 and method of claim 9,
Adibi teaches wherein the blockchain is a private blockchain ([0048] By distributing data across a peer-to-peer network, blockchain eliminates a number of risks that would otherwise stem from the data being held centrally. Blockchain may also utilize additional security such as a private key acts as a password giving its owner access to the digital assets of that particular block), a smart contract includes at least some of the operations ([0049] blockchain can also be used for “smart contracts” that can be partially or fully executed and/or enforced without human interaction, with one of the main objectives for smart contract being an automated escrow), and
Sachs also teaches wherein the blockchain is a private blockchain ([0045] the blockchain system 6 is configured such that part of the data in the blockchain is accessible to the public and another part of the data in the blockchain is private and only accessible by authorised users.)
Adibi/Sachs do not teach charging a customer a usage fee for the private blockchain.
Jayachandran teaches charging a customer a usage fee for the private blockchain ([0017] A seller(s) is an entity which has a copy of the desired digital content and will transfer it to a buyer in various situations (for example, a fee is paid). A buyer(s) is an entity interested in acquiring data (for example, digital content) by paying the necessary fees., [0018] A service fee (usage fee) can be charged for providing a validation and recommendation service on the blockchain. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included charging a customer a usage fee for the private blockchain, as disclosed by Jayachandran in the system disclosed by Adibi/Sachs, for the motivation of providing a validation and recommendation service on the blockchain for a service fee and enabling verifiability and non-reputability of digital asset exchange in distributed settings using the blockchain for recording protocol operations.([0018] Jayachandran)
Response to Arguments
Applicant's arguments filed 10/27/25 have been fully considered but they are not persuasive.
Regarding 101 rejection, applicant states claims are eligible udder step 2A and integrate exception into practical application because it reflects improvements to the functioning of the computer itself. Examiner has considered all arguments and respectfully disagrees. The judicial exception is not integrated into a practical application because the claim merely describes how to generally “apply” the concept of receiving data, analyzing it, and providing validation. In particular, the claims only recites the additional elements – a processor and a memory, hash function, blockchain, computer. The additional elements are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). Simply implementing the abstract idea on generic components is not a practical application of the abstract idea. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Applicant’s arguments with respect to claim(s) 103 rejection 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 states cited art does not teach amended claim. New limitations have been considered in rejection above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen (US 11,546,143) discloses the user information is encrypted by a group key and access duration is based on a change to the group key. The group key comprises a public/private key pair, and the access duration is implemented by an authorization group of nodes having the group key. The group key corresponds to either a valid group key at or near the start of the access duration, that enables decryption of a message in the record of authorization that includes the user information.
McLean (US2020/0244464) discloses a one-way hash function ([0032] create a fixed size authentication token, all of the blockchain data is passed to a one-way hash algorithm (e.g., the SHA256 one-way hash algorithm). The one-way hash algorithm may take an arbitrary size length data and produce a unique 32-byte hash of the data.); wherein the first output comprises an indication that the recording or transcript is validated ([0014] A block may contain the data of one or more records or transactions. [0054] At 212, the blockchain authentication program 110a, 110b determines if the blockchain hash is validated. The blockchain may validate the blockchain hash using the received verifier packet. The blockchain identification program 110a, 110b may determine if the blockchain hash is validated by comparing the hash in the verifier packet with the hash on the blockchain server (i.e., the original hash created at 206, [0056] If the blockchain authentication program 110a, 110b determines that the blockchain hash is valid at 212, then a confirmation packet is transmitted to the verifier at 214. A matching hash comparison between the verifier packet hash and the blockchain hash and any other authentication restriction confirmations may provide validity., [0058]) the second output comprises an indication that the recording or transcript is not validated.([0059] If the blockchain authentication program 110a, 110b determines that the blockchain hash is not valid at 212, then the validation process fails at 218. The blockchain server may perform a hash comparison to validate the user and verifier data and the compared hashes may not match between the verifier packet and the blockchain server. The result of hashes that do not match once compared may fail the validation process Upon an unsuccessful hash comparison or other data restriction failures, the blockchain server may add the verifier packet and the unsuccessful validation result to the blockchain. The blockchain server may reply to the verifier with a confirmation packet that provides data regarding an unsuccessful authentication or verification.)
Wilson (US 2020/0267163) disclose [0084] A record may include information enabling trusted timestamping validation, for example a copy of a signed hash, such as encrypted hash value 111.
NPL, Validity of forensic evidence using hash function, 2020 discusses program compares the newly computed hash value with the hash value that was computed during the preservation phase 9) Reports the output to the Investigator as any one of the following, a) Data is not tampered b) Data has been tampered
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 SANGEETA BAHL whose telephone number is (571)270-7779. The examiner can normally be reached 7:30 - 4PM.
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, Jessica Lemieux can be reached at 571-270-3445. 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.
/SANGEETA BAHL/Primary Examiner, Art Unit 3626