DETAILED ACTION
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 .
Status of the Claims
This is a final rejection prepared in response to applicant’s amendment filed on 07/29/2026.
Claims 1, 3, 5, 8-10, 12, 14, 16 and 18 were amended.
Claims 8-13 were withdrawn.
Claims 1-20 are pending.
Election by Original Presentation
Newly amended claims 8-13 are directed to an invention that is independent or distinct from the invention originally claimed for the following reasons:
Claims 1-7 are drawn to a method & claims 14-20 are drawn to a non-transitory computer-readable storage medium classified in G06Q20/3255.
Claims 8-13 are drawn to a system classified in H04L 67/10.
Since applicant has received an action on the merits for the originally presented invention, this invention has been constructively elected by original presentation for prosecution on the merits.
Accordingly, claims 8-13 are withdrawn from consideration as being directed to a non-elected invention. See 37 CFR 1.142(b) and MPEP § 821.03.
To preserve a right to petition, the reply to this action must distinctly and specifically point out
supposed errors in the restriction requirement. Otherwise, the election shall be treated as a final
election without traverse. Traversal must be timely. Failure to timely traverse the requirement will result in the loss of right to petition under 37 CFR 1.144. If claims are subsequently added, applicant
must indicate which of the subsequently added claims are readable upon the elected invention.
Should applicant traverse on the ground that the inventions are not patentably distinct,
applicant should submit evidence or identify such evidence now of record showing the inventions to be
obvious variants or clearly admit on the record that this is the case. In either instance, if the examiner
finds one of the inventions unpatentable over the prior art, the evidence or admission may be used in a
rejection under 35 U.S.C. 103 or pre-AIA 35 U.S.C. 103(a) of the other invention.
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-7 and 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-7 are directed to computer-implemented method (i.e., process). Claims 14-20 are directed to a non-transitory computer-readable storage medium (i.e., manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method comprising:
sending, by an application, a first short message service (SMS) message, the first SMS message requesting a coin object having at least a minimum value and identifying a wallet address of a sender, the coin object being stored on a blockchain;
receiving, by the application, a second SMS message, the second SMS message including an identification of the coin object having the at least the minimum value, a versioned ID of object, and a digest;
receiving, by the application, data input into a user interface of the application that is effective to define at least a recipient wallet address and a type of transaction to occur on the blockchain;
sending, by the application, a third SMS message, the third SMS message including a signature for the sender, and transaction details including at least the wallet address of the sender, the identification of the coin object as a gas input, the recipient wallet address, and the type of transaction; and
receiving, by the application, a fourth SMS message, the fourth SMS message including a transaction digest with proof that the transaction has been recorded on the blockchain.
Claim 1 recites (i.e., sets forth or describes) a method for processing assets transactions. The claim achieves this by sending a first message inquiring about a specific asset, receiving a second message with the information of the asset, providing information to process a transaction, sending a third message with information about the transaction and receiving a fourth message confirming the completion of the transaction. Claims 8 and 14 are significantly similar to claim 1. As such claims 8 and 14 also recite an abstract idea. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” (i.e., fundamental economic practices and commercial or legal interactions) grouping of abstract ideas.
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of an application, a first SMS message, a second SMS message, a third SMS message, a fourth SMS message, a blockchain and a user interface merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 2-7 and 15-20 have also been analyzed for subject matter
eligibility. The claims recite bolded claim elements as abstract ideas and non-bolded claim elements, if
any, as additional elements according to MPEP 2106.04(a). Accordingly, claims 2-7 and 15-20 also fail to recite patent eligible subject matter for the following reasons:
Claims 2 and 15 recite:
content within the SMS messages are exchanged between a blockchain proxy and the application, wherein the blockchain proxy is configured to translate a context with the SMS messages into messages compatible with a blockchain software developer kit.
The non-bolded additional elements of a blockchain proxy, a SMS messages, the application and a blockchain software developer kit fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 3 and 16 recite:
the SMS messages are exchanged with an SMS forwarding service, wherein the SMS forwarding service is configured to be an interface between an SMS network and the IP network, wherein the SMS forwarding service communicates with the application over the SMS network and communicates with the blockchain proxy over an IP network, wherein the SMS forwarding service forwards messages received from the application to the blockchain proxy and forwards messages received from the blockchain proxy to the application.
The non-bolded additional elements of an the SMS messages, SMS forwarding service, an SMS network, an IP network, an application and a blockchain proxy fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 4 and 17 recite:
any of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message are divided over a plurality of SMS transmissions in order to keep the SMS transmissions under a maximum character length.
The non-bolded additional elements of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 5 and 18 recite:
any of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message are encoded to a number of characters less than a maximum character length for an SMS transmission, wherein the application and a blockchain proxy are endowed with instructions to decode the SMS transmission.
The non-bolded additional elements of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message, a blockchain proxy and the application fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 6, 13 and 19 recite:
the application can select from one of several blockchain networks to which to conduct the transaction, and the first SMS message and the second SMS message identify the one of the several blockchain networks.
The non-bolded additional elements of an application, the first SMS message and several blockchain networks fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 7 and 20 recite:
the SMS message could be substituted for FM/AM radio signals, or satellite transmissions.
The non-bolded additional elements of the SMS message fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-2 and 14-15 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Henning (US 20230198785 A1).
Regarding claims 1 and 14, Henning discloses:
sending, by an application, a first short message service (SMS) message, the first SMS message requesting a coin object having at least a minimum value and identifying a wallet address of a sender, the coin object being stored on a blockchain; (¶0047, In embodiments, the computer system 1400, the system 100, or the BSMS system 120 generates a mint graphical user interface (GUI) 300, for example, the user interface shown by FIG. 3, initiable by a mint instruction 308 received at the user device 110.. The mint GUI 300 is configured to generate and transmit SMS messages from the user device 110 to the computer system 1400. ¶0048, The computer system 1400 receives SMS messages or a first SMS message describing at least one of an address where a digital asset is stored, a digital asset name 312, a digital asset description 316, and digital asset metadata from the user device 110... The computer system 1400 causes the NFT 304 to be minted at a blockchain address 320 using the digital asset 304, the digital asset name 312, the digital asset description 316, and the digital asset metadata. The computer system 1400 generates an NFT name, a token identifier, and a collection name of a digital asset collection to which the NFT belongs.)
receiving, by the application, a second SMS message, the second SMS message including an identification of the coin object having the at least the minimum value, a versioned ID of object, and a digest; (¶0050, The computer system 1400 sends, to the user device 110, SMS messages or a second SMS message describing the URL, the NFT name, the token identifier, and the collection name.)
receiving, by the application, data input into a user interface of the application that is effective to define at least a recipient wallet address and a type of transaction to occur on the blockchain; (¶0041, For example, a user device 110 accesses an NFT by entering the following instruction into the BSMS application: TRANSFER BORED-APE #123 TO +1-123-456-7890. The instruction will transfer the NFT identified by “BORED-APE #123” to the recipient whose cell phone number is “+1-123-456-7890.” ¶0058, The view GUI 400 enables a user to enter a collection name and NFT identifier. ¶0062, The user enters a name of a digital asset collection, an NFT identifier, and a recipient identifier. The recipient can be identified with a mobile telephone number, a blockchain address, and so on.)
sending, by the application, a third SMS message, the third SMS message including a signature for the sender, and transaction details including at least the wallet address of the sender, the identification of the coin object as a gas input, the recipient wallet address, and the type of transaction; and (¶0021, receiving a transfer request that identifies the NFT, the sender’s phone number, and the recipient’s blockchain address. A cryptographic operation (e.g., a transfer transaction) is created to transfer the NFT from the sender to the recipient’s blockchain address. A hardware security module (HSM) is requested to sign a hash of the cryptographic operation (e.g., the transfer transaction) with a private key associated with the sender’s phone number, and recording of the operation (e.g., the transfer transaction) in the blockchain is initiated. ¶0026, The request R identifies an input transaction to the cryptographic transfer transaction Tx and can identify a recipient phone number to which (ownership of) the digital asset is to be transferred. In embodiments, the user device 110 sends the request R in an SMS message to the SMS gateway 121. In embodiments, the BSMS system 120 uses the recipient phone number to access a recipient blockchain address maintained by the recipient, generates the cryptographic transfer transaction Tx, and uses a sender phone number to access the sender’s private cryptographic key to sign the cryptographic transfer transaction Tx. For example, the recipient phone number is used to look up the recipient blockchain address. ¶0045, Transferring via phone numbers and wallets. For example, the following instructions each transfer 100 SUKU to the wallet associated with the recipient’s phone number: (a)“TRANSFER 100 SUKU TO +1-123-456-7890.”and (b)“TRANSFER 100 SUKU TO 0x06984cd546f369c6ce5bd9db1cba1af02108b030.” ¶0065, Tokens also have an owner that uses an additional public/private key pair. The owner public key is set as the token owner identity, and when performing actions against tokens, ownership proof is established by providing a signature generated by the owner private key and validated against the public key listed as the owner of the token. ¶0053, In embodiments, responsive to receiving, from the second user device, SMS messages (e.g., a third SMS message) describing a token identifier, a collection name, a recipient blockchain address, and a phone number of the recipient: the computer system 1400 resolves the collection name to a collection blockchain address based on the SMS messages or the third SMS message. The computer system 1400 generates a cryptographic transaction on the blockchain 161 to transfer the NFT from the collection blockchain address to the recipient blockchain address. ¶0062, For example, to transfer an NFT, the NFT-SMS system (system 100) provides a transfer user interface 500 that is initiated by a “transfer” command 508. The user enters a name of a digital asset collection, an NFT identifier, and a recipient identifier. The recipient can be identified with a mobile telephone number, a blockchain address, and so on. ¶0063, In embodiments, the computer system 1400 receives, from the user device 110, an SMS message describing a token identifier of the NFT 304, a collection name of a digital asset collection to which the NFT 304 belongs, a recipient blockchain address of the recipient, and a phone number of the recipient. ¶0086, In step 1112, the computer system 1400 receives, from the user device 110, one or more SMS messages describing a token identifier of the digital assets, such as cryptocurrency or NFT 304, a collection name of a digital asset collection to which the NFT 304 belongs, a recipient blockchain address of the recipient, and a phone number of the recipient.)
receiving, by the application, a fourth SMS message, the fourth SMS message including a transaction digest with proof that the transaction has been recorded on the blockchain. (¶0038, The SMS backend 122 sends the hash of the transaction and a link L to the blockchain browser 150 (e.g., Etherscan) to the SMS gateway 121, which forwards the hash and the link L to the user device 110. The user device 110 uses the link and the transaction hash to access the transaction that is stored on the blockchain 161. To access the transaction, the user device 110 uses the link L and the hash of the transaction to access the blockchain browser 150. The blockchain browser 150 retrieves the transaction associated with the hash from the blockchain 161 and sends it to the user device 110. ¶0043, Notifying sender and receiver about successful transfers between them. See Fig. 5)
Henning further discloses:
one or more processors; and memory (¶0116, The computer system 1400 can include one or more central processing units (“processors”) 1402, main memory 1406, non-volatile memory 1410, network adapters 1412 (e.g., network interface), video displays 1418, input/output devices 1420, control devices 1422 (e.g., keyboard and pointing devices), drive units 1424 including a storage medium 1426, and a signal generation device 1420 that are communicatively connected to a bus 1416.)
a non-transitory computer-readable storage medium, (claim 15, A computer system for digital communication using cryptography, comprising: one or more computer processors; and a non-transitory computer-readable storage medium storing computer instructions)
Further, the limitations “…having the at least the minimum value”, “…including …, a versioned ID of object, and a digest”, “… including a signature for the sender, and transaction details including at least the wallet address of the sender, an identification of the coin object as a gas input, the recipient wallet address, and the type of transaction” and “… including a transaction digest with proof that the transaction has been recorded on the blockchain.” and “the coin object being stored on a blockchain” only describe characteristics of the SMS messages which is non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Furthermore, the limitation “that…” in “…that is effective to define at least a recipient wallet address and a type of transaction to occur on the blockchain;” consists of language disclosing an intended use or result, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Regarding claims 2 and 15, Henning further discloses:
content within the SMS messages are exchanged between a blockchain proxy and the application, wherein the blockchain proxy is configured to translate a context with the SMS messages into messages compatible with a blockchain software developer kit. (¶0059, For example, the SMS backend 122 receives an SMS message with the collection name and NFT identifier and then searches for that token in the collection. The SMS backend 122 is illustrated and described in more detail with reference to FIG. 1. The SMS backend 122 uses various techniques to match the collection name entered by the user with the name of a digital asset collection. For example, if the user inputs “texmecryp” or “textmycrypto,” into an SMS message, the SMS backend 122 resolves the input to “TextMeCrypto.” ¶0062, The user enters a name of a digital asset collection, an NFT identifier, and a recipient identifier. The recipient can be identified with a mobile telephone number, a blockchain address, and so on. The SMS backend 122 can resolve the name to the actual name of the collection or a collection blockchain address. The SMS backend 122 is illustrated and described in more detail with reference to FIG. 1. ¶0087, In step 1116, the computer system 1400 resolves the collection name to a collection blockchain address based on the SMS messages. For example, the collection name is converted to a string of text that uniquely identifies the source or destination of a cryptographic operation (e.g., a transaction) and is used to send and receive funds of digital assets on a blockchain network.)
Further, the claimed limitation “configure to…” in “wherein the blockchain proxy is configured to translate a context with the SMS messages into messages compatible with a blockchain software developer kit” consists of language disclosing an intended use or result, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Henning as applied to claim 2 above, in view of Monzaviyan (WO 2022047582 A1).
Regarding claims 3 and 16, Henning further discloses:
the SMS messages are exchanged with an SMS forwarding service, wherein the SMS forwarding service forwards messages received from the application to the blockchain proxy and forwards messages received from the blockchain proxy to the application. (¶0025, The BSMS system 120 includes an SMS gateway 121, an SMS backend 122, and a salt store 123. ¶0026, In embodiments, the user device 110 sends the request R in an SMS message to the SMS gateway 121.¶0027, In embodiments, the SMS gateway 121 signs the request R using a secret key shared with the SMS backend 122 to generate a signed transaction R.sup.S and sends the signed transaction R.sup.S and a phone number PN of the user device 110 (derived from the SMS message) as a Transport Layer Security (TLS) encrypted HTTPS request E(R.sup.S) and encrypted phone number E(PN) to the SMS backend 122. ¶0038, The SMS backend 122 sends the hash of the transaction and a link L to the blockchain browser 150 (e.g., Etherscan) to the SMS gateway 121, which forwards the hash and the link L to the user device 110.
Henning does not disclose, however Monzaviyan teaches:
wherein the SMS forwarding service is configured to be an interface between an SMS network and an IP network, wherein the SMS forwarding service communicates with the application over the SMS network and communicates with the blockchain proxy over an IP network, (¶0027, As shown, a portion of the remote computing devices 104, which are represented as online users 105, communicate with the server 102 via a network 106 (e.g., the internet) and another portion of the remote computing devices 104, which are represented as offline users 107, communicate with the server 102 via a SMS gateway 109. By way of example only, an app on the remote computing devices 104 could use APIs of the SMS gateway 109 to communicate with the server 102 via SMS messaging. An example SMS gateway service could be provided by Twilio Inc. of San Francisco, California. ¶0028, In some embodiments, the offline users 107 may use remote computing devices 104 that are embodied as a mobile computing device, such as a smartphone or tablet, with a cellular plan and phone number, but without a data plan or are in a location outside of the range of their data plan. Due to not having a data plan or being outside coverage, the offline users 107 are unable to communicate through the network 106. Instead, the offline users 107 communicate with the server 102 via the SMS gateway 109. ¶0039, The app will then send the above content out via the default SMS app on the device 104 to a pre-designated phone number of the SMS gateway 109. The app on the user’s device 104 deducts the sent amount from the current balance, and deletes the OTK key used for that transaction (regardless of the outcome). In the transaction history stored on the device 104, the transaction is noted as an offline transaction sent to the server 102. Upon receiving the SMS message, the SMS gateway 109 triggers a WebHook URL, which sends the content to the SMS message and the sender’s phone number to the URL address of the server 102.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the SMS message transaction system of Henning by incorporating the SMS gateway Monzaviyan’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to facilitate delivery of SMS messages to the intended recipients.
Further, the claimed limitation “configure to…” in “wherein the SMS forwarding service is configured to be an interface between an SMS network and an IP network, wherein the SMS forwarding service communicates with the application over the SMS network and communicates with the blockchain proxy over an IP network” consists of language disclosing an intended use or result, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Claims 4-5 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Henning as applied to claim 1 above, in view of Cili (US 20150256986 A1).
Regarding claims 4 and 17, Henning does not disclose, however Cili teaches:
any of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message are divided over a plurality of SMS transmissions in order to keep the SMS transmissions under a maximum character length. (¶0021, In view of the maximum number of characters allowed to be included in the SMS (based upon the encoding scheme), larger content may be sent using multiple SMS messages that constitute the entire text message. When no mechanism is configured for large text messages, the user may be prevented from entering any further characters into the text message. A mechanism that is used to overcome this drawback is concatenated SMS. For example, with the maximum character limitation, a text message may be divided into three SMS messages that are concatenated. The first message may be a first set of characters that is delivered first; the second message may be a second set of characters immediately following the first set of characters that is delivered second; and the third message may be a third set of characters immediately following the second set of characters that is delivered third. ¶0022, The concatenation process provides a seamless manner in which a large text message that exceeds the maximum number of allowed characters within a SMS message to be divided into a plurality of SMS messages and transmitted from the transmitting station to the receiving station without any intervention required from the users of both stations.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the SMS message transaction system of Henning by incorporating Cili’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to provide a seamless manner in which a large text message that exceeds the maximum number of allowed characters within a SMS message to be divided into a plurality of SMS messages and transmitted from the transmitting station to the receiving station without any intervention required from the users of both station (Cili ¶0022).
Further, the claimed limitation “wherein any of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message are divided over a plurality of SMS transmissions in order to keep the SMS transmissions under a maximum character length.” only describes characteristics of SMS messages which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Regarding claims 5 and 18, Henning does not disclose, however Cili teaches:
any of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message are encoded to a number of characters less than a maximum character length for an SMS transmission, wherein (¶0002, When the text message is transmitted as a SMS message, the text of the message may be encoded using a variety of encoding schemes. In a first example, a 7-bit encoding scheme may be used which includes a defined alphabet including a set of characters as defined by the Global System for Mobile Communications (GSM). The 7-bit encoding scheme allows for a maximum of 160 characters to be included in one text message. In a second example, an 8-bit encoding scheme may be used which includes a defined data alphabet. The 8-bit encoding scheme allows for a maximum of 140 characters to be included in one text message. In a third example, a 16-bit encoding scheme may be used which includes a 2-byte Universal Character Set (UCS-2). The 16-bit encoding scheme allows for a maximum of 70 characters to be included in one text message. ¶0023, In a first example of transmitting concatenated SMS messages, the entire text message may use only the 7-bit encoding scheme. Thus, the text message may be split into 153 7-bit character parts (134 octets) with each part transmitted with a User Data Header (UDH) appended onto the beginning of the payload. The UDH may be used for various purposes and its contents and size varies accordingly. However, a UDH for concatenated SMS messages may include predetermined fields. Field 1 (1 octet) may indicate a length of the UDH (e.g., 05). Field 2 (1 octet) may indicate an Information Element Identifier (e.g., equal to 00 (Concatenated SMS messages, 8-bit reference number)). Field 3 (1 octet) may indicate a length of the header excluding the first two fields (e.g., equal to 03). Field 4 (1 octet) may indicate a concatenated SMS reference number which must be the same for all the parts in the concatenated SMS messages of a text message (e.g., 00-FF). Field 5 (1 octet) may indicate a total number of parts. The value remains constant for every concatenated SMS message that makes up the entire text message. ¶0054, In step 440, the concatenation application 240 provides instructions to the baseband layer that the entire text message is to be encoded using the same encoding scheme. For example, if the text message is less than 70 characters and includes a Unicode character, the entire message is to be encoded using the 16-bit encoding scheme. In another example, if the text message is less than 160 characters and includes only 7-bit characters, the entire message is to be encoded using the 7-bit encoding scheme. Thus, in step 445, the text message is encoded as indicated in the instructions. ¶0055, Returning to step 435, if the concatenation application 240 determines that the text message is long and requires concatenation, the method 400 continues to step 455. For example, if the text message exceeds 160 characters, regardless of the encoding schemes that are to be used, the text message uses concatenation. In another example, if the text message exceeds 70 characters and includes at least one Unicode character, the text message uses concatenation. See claim 5.)
the application and a blockchain proxy are endowed with instructions to decode the SMS transmission. (¶0060, Thus, the messaging application 235 of the receiving station 110 may receive the single SMS message to be decoded using a reverse operation to encode using the respective encoding scheme… ¶0061, Thus, the messaging application 235 of the receiving station 110 may receive these concatenated SMS messages to be decoded using a reverse operation to encode using the respective encoding scheme. In this example, each concatenated SMS message may have been encoded with different encoding schemes. Thus, the messaging application 235 may determine the encoding schemes used to properly decode them. Furthermore, the receiving station 110 may include the concatenation application 240 that may be configured to perform an assembly functionality for the received concatenated SMS messages. In this manner, the concatenated SMS messages may be combined into a single text message for display to the user of the receiving station 110. See claims 8 & 18.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified SMS message transaction system of Henning by incorporating Cili’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to ensure the transmitted message meets the character length requirements of the communication system.
Further, the claimed limitation “wherein any of the first SMS message, the second SMS message, the third SMS message, or the fourth SMS message are divided over a plurality of SMS transmissions in order to keep the SMS transmissions under a maximum character length.” and “wherein the application and a blockchain proxy are endowed with instructions to decode the SMS transmission.” only describes characteristics of the SMS messages, the application and the blockchain proxy which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Claims 6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Henning as applied to claim 1 above, in view of Posner (US 20240362623 A1) in further view of Lee (EP 4088238 B1).
Regarding claims 6 and 19, Henning does not disclose, however Posner teaches:
the application can select from one of several blockchain networks to which to conduct the transaction, and (¶0033, The wallet application is also configurable to determine which network is to be used to implement a transaction, e.g., to transfer funds via a layer 1 or layer 2 network. Selection of the network is usable to address a variety of considerations. ¶0097, A transaction type determination module 614 is then utilized to generate transaction data 616 to initiate the transaction, which also includes functionality to select which network is to be used to perform the transaction, e.g., the blockchain network 102 or the decentralized network 104. Functionality to do so is represented by a decentralized transaction initiation module 618 and a blockchain transaction initiation module 620. The transaction data 616 is then communicated to a transaction server 702 that corresponds to the blockchain network 102 or decentralized network 104 selected by the wallet application 402. ¶0098, An ability to select the network by the wallet application 402 and/or wallet server 404 is made possible due to liquidity that is made available on both networks through use of the unified wallet, which is not possible in conventional techniques.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified SMS message transaction system of Henning by incorporating Posner’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to address a variety of considerations such as cost of performing the transaction (i.e. fees) or time to process the transaction (i.e. slower or faster)(Posner, ¶0098).
The combination of Henning and Posner do not disclose, however Lee teaches:
the first SMS message and the second SMS message identify the one of the several blockchain networks. (¶0057, According to an embodiment, the processor 220 may receive a message including the blockchain address (or account) and identification data for identifying the blockchain network where the blockchain address (or account) exists from an external electronic device (e.g., the second electronic device 202 or the server 208) through the communication module 240 (e.g., the communication module 190 of FIG. 1). For example, the message may include information requesting a remittance to a designated blockchain address (or account). For example, the identification data may be unique data of a designated blockchain network. For example, the identification data may include information about the transaction ID indicating information about a transaction of the blockchain address (or account), which is performed in a designated blockchain network or the latest block number (e.g., the number of the latest block generated) of the blockchain address (or account). For example, the message includes a short message service (SMS) message. ¶0058, According to an embodiment, the processor 220 may identify the blockchain network of the corresponding blockchain address (or account) before transmitting the cryptocurrency to the blockchain address (or account) included in the message. For example, the processor 220 may access at least one blockchain network related to the blockchain address (or account) through the communication module 240. For example, the processor 220 may access the blockchain network included in the message received from the external electronic device. For example, when the network corresponding to the blockchain address (or account) in the message is designated as an Ethereum blockchain network, the processor 220 may access the Ethereum blockchain network. Or, the processor 220 may access at least one blockchain network related to the address of the blockchain address (or account). In this case, the processor 220 may analyze the address of the blockchain address (or account) and access at least one blockchain network using the format of the address. For example, when the address of the blockchain address (or account) is an Ethereum-based address, the processor 220 may access an Ethereum network and at least one blockchain network (e.g., Ethereum Classic, Klaytn, EOS, Pebble) hard forked based on Ethereum. ¶0073, For example, the message may include the blockchain address (or account) to which the remittance is made and identification information for the blockchain network corresponding to the blockchain address (or account). For example, the message may include JSON data. The identification data may be information that may distinguish a specific blockchain network from the others. For example, the identification data may include information about the transaction ID (tx_id) indicating information about a transaction of the blockchain address (or account), which is performed in a specific blockchain network or the latest block number (e.g., the number of the latest block generated) of the specific blockchain network. ¶0128, For example, the message 910 may include a blockchain address (or account) 911, identification data 915, and other information 917. The blockchain address (or account) 911 may include information about the blockchain address. The identification data 915 may include unique data of the blockchain network and may include a transaction ID (tx id) or a block number. The other information 917 may include at least one of the name of the blockchain network, a contract address (e.g., smart contract address) to be used for mutual verification, a custom value required for remittance, and a token. However, the message 910 may not include the other information 917. For example, the message 910 may include JSON data including an "address" and a "tx id". The second electronic device 202 may transmit the generated message 910 to the first electronic device 201.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modified the combination of Henning and Posner by incorporating Lee’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to enable routing an execution of the transaction on the correct blockchain.
Further, the claimed limitation “wherein the application can select from one of several blockchain networks to which to conduct the transaction, and the first SMS message and the second SMS message identify the one of the several blockchain networks…” only describes characteristics of the application and the SMS messages which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Henning as applied to claim 1 above, in view of Muur ("4 Ways to Make On-Chain Transfers Without Internet", 10/04/2023).
Regarding claims 7 and 20, Henning does not disclose, however Muur teaches:
wherein the SMS message could be substituted for FM/AM radio signals, or satellite transmissions. (P.1, #1 Data Broadcasting via Radio: Blockchain transactions can be broadcast via radio waves. By translating transaction data into radio signals, it can be sent and received by anyone with the necessary radio equipment… #6 Ham Radio Transmissions: This old-school communication method has been used to transmit emails and can also be adapted for blockchain transactions, especially over long distances… #7 Satellite Transmissions: Some companies are now launching satellites that can handle blockchain transactions. With the right equipment, you can send/receive transactions directly through these satellites.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the disclosure of Henning by incorporating Muur’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to provide an alternative method to broadcast the information to the blockchain for clients in remote locations that do not have access to internet connection.
Further, the claimed limitation “wherein the SMS message could be substituted for FM/AM radio signals, or satellite transmissions …” is non-functional descriptive material and is not processed or used to carry out any functionality that specifically relies on it.
Response to Arguments
Claim Objections
Claim objections in the previous non-final action dated 07/29/2026 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions in regard to claim rejection 101 in the previous office action dated 07/29/2026. The basis for these assertions are based on the applicant’s argument on pages 9-14.
First, the applicant asserts that the claims do not recite a mental process. The examiner acknowledges this argument and confirms that the previous rejection based on mental processes has been reconsidered and corrected. However, the examiner maintains that the claims remain directed to an abstract idea, specifically directed toward certain methods of organizing human activity (i.e., fundamental economic principles or practices and commercial or legal interactions). Further, the applicant asserts that “the office action did not establish that the claimed communications protocol itself constitutes a fundamental economic principle or commercial interaction. Claims 1 and 14 do not merely recite an agreement, payment obligation, sale, hedging arrangement, insurance arrangement, or other human commercial relationship. Instead, they recite a specific machine-implemented sequence or communicating blockchain-native data through SMS messages. The fact that the resulting blockchain operation may involve a "transaction" does not transform the specific communications and cryptographic operations into organizing human activity.” The examiner finds these assertions unpersuasive and respectfully disagrees. The office did not characterize the claimed communication protocol itself as an abstract idea (i.e. fundamental economic practice or commercial interaction). The recited steps in the claim recite an abstract idea of a process for facilitating a transaction by exchanging information between two entities. This process is performed by sending a first message requesting information about a coin object, receiving a second message including identification of the coin object and other data, receiving data input, sending a third message and receiving a fourth message. The applicant is attempting to conflate the Step 2A, 1st prong test, with the Step 2A, 2nd prong test.
Second, the applicant asserts that the claims integrate any alleged exception into a practical application because the claims require a particular sequence having a particular blockchain-specific content and dependencies. Further, the applicant asserts that the SMS messages are not incidental data gathering or generic post solution reporting and they form the communication mechanism through which the claimed application obtains blockchain state information, submits a signed blockchain operation, and receives proof of blockchain execution. The examiner finds these assertions unpersuasive and respectfully disagrees. The messages facilitate the exchange of information. The fact that the messages contain blockchain specific data (i.e. blockchain address) does not integrate the abstract idea into a practical application. Also, the claimed specific sequence of messages merely describes the order in which the transaction is performed. Therefore, a method for facilitating a transaction between two entities does not provide any specific improvement to the functioning of the computer or technology. The applying of the abstract idea does not improve upon the client device, nor does it improve upon the blockchain. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fails to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework. Additionally, the applicant asserts that the office action overlooks the disclosed technical problem in the specifications. The examiner finds this assertion unpersuasive and respectfully disagrees. The technological solution is not recited in the claims. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Third, the applicant asserts that claims 1 and 14 provide a solution “necessary rooted in computer technology” as the one recites in USPTO example 21 claim 2. The examiner finds this assertion unpersuasive and respectfully disagrees. USPTO example 21 claim 2, recites a specific technological improvement rather than merely specifying the information exchange between the entities during the transaction. On the other hand, claims 1 and 14 recite a process of utilizing SMS messages for requesting information (i.e. coin record), sending information (i.e. signature) and receiving information (i.e. transaction digest). These limitations do not recite any specific improvement upon the computer, blockchain proxy or any other technology. Therefore, the specific claimed sequence and blockchain content do not provide any technological improvement similar to the one recited in USPTO example 21 claim 2.
Fourth, the applicant asserts claims 1 and 14 are patent eligible because they are analogous to those in Ex parte Smith. The examiner finds this assertion unpersuasive and respectfully disagrees. It was determined that Ex parte Smith recited a technological improvement to prior trading systems that solve a hybrid electronic trading environment problem. The fact that the claim messages have dependency and occur in a specific order does not constitute a practical application. The specific claimed order of requesting a coin object, receiving the coin object, sending a signature and receiving a confirmation does not improve upon the computer technology or blockchain. Further, the applicant asserts that the office action does not address the specific sequence and does not evaluate the claim as a whole. The examiner also finds this assertion unpersuasive and respectfully disagrees. The office action addressed the claimed sequence and evaluated the claims as a whole. The mere presence of a specific sequence does not constitute an improvement to the technology. Here, the question is whether the specific sequence integrates the abstract idea into a practical application. However, claims 1 and 14 do not recite such integration.
Finally, the applicant asserts “that the office action provides no factual basis for concluding that this particular ordered combination was well-understood, routine and conventional”. The examiner finds this assertion unpersuasive and respectfully disagrees. The rejection under 35 U.S.C. 101 was not based on the determination that the recited steps are well-understood, routine or conventional. Rather, the claims are directed to an abstract idea and do not recite additional elements that integrate the abstract idea into a practical application. Therefore, whether the claimed steps are well-understood, routine or unconventional does not overcome the rejection. Even assuming, arguendo, that the steps are not routine or conventional, the claim still recites the abstract idea implemented using generic computer components and does not amount to significantly more than the underlining abstract idea.
Claim Rejections – 35 U.S.C. § 102
The applicant presents several assertions in regard to claim rejection 102 in the previous office action dated 07/29/2026.
First, the applicant asserts that Henning does not disclose “the claimed first message” because the message in the reference “does not request a coin object belonging to the sender that has at least a minimum value, and it does not identify a sender wallet address for that request”. The examiner finds this assertion unpersuasive and respectfully disagrees. Henning in ¶0047 &¶0048 discloses a mint process in where the computer system receives a SMS message request describing at least one of an address where the digital asset is stored (i.e. a sender wallet address), a digital asset name (i.e. a coin object), a digital asset description and digital asset metadata from the user device. Further, metadata is information describing the digital asset. Therefore, the digital asset metadata can encompass information related to the value of the digital asset (i.e. minimum value). Additionally, Henning determines the whether an amount of cryptocurrency satisfies a threshold amount before processing a transaction which associates the transaction with a minimum value requirement. Finally, the limitation “…having at least a minimum value…” only describe a characteristic of the coin object which is non-functional descriptive material and this characteristic is not processed or used to carry out any functionality that specifically relies on this particular characteristic.
Second, the applicant asserts that Henning does not disclose “the claimed second SMS message” because it does not “return an identification, versioned identifier, and digest of a qualifying coin object requested in the first SMS message.” The examiner finds this assertion unpersuasive and respectfully disagrees. The first SMS message in the claim only requests the coin object and does not request an identification, versioned identifier or digest. The claim merely requires the message to include “an identification of the coin object having the at least the minimum value, a versioned ID of object, and a digest”. However, although the message is recited as including “an identification of the coin object having the at least the minimum value, a versioned ID of object, and a digest”, the subsequent steps only utilize “an identification of the coin object having the at least the minimum value”. The claim does not recite any steps that utilize “… a versioned ID of object, and a digest”. Therefore, “…a versioned ID of object, and a digest” do not have a functional relationship with the subsequent steps and do not affect how those steps are performed.
Third, the applicant asserts, that Henning does not disclose “the claimed third SMS message” because “the SMS sent from Henning’s user device does not include the sender’s transaction signature and does not identify the coin object returned in a second SMS message as a gas input”. The examiner finds this assertion unpersuasive and respectfully disagrees. The claimed limitation “…including a signature for the sender, and transaction details including at least the wallet address of the sender, the identification of the coin object as a gas input, the recipient wallet address, and the type of transaction;” only describe characteristics of the third SMS message which are non-functional descriptive material and these characteristics are not processed or used to carry out any functionality that specifically relies on these particular characteristics. The claim does not recite any subsequent steps in which these characteristics are being used. Therefore, the recited characteristics do not change how the subsequent steps are performed.
Fourth, the applicant asserts that the characterization of the SMS contents as non-functional is inconsistent with the claims because “the sender and recipient wallet addresses, gas input, transaction type, and cryptographic signature define and authenticate the blockchain operation represented by the third SMS message. Changing those values changes the represented operation or whether it can be validated. The transaction digest in the fourth SMS message is generated as proof of the resulting blockchain record. Because the claims require the recited message data to be used in generating, signing, decoding, and executing the blockchain transaction, rather than merely conveying information, the data limitations are functionally related to the claimed computer processing and are entitled to patentable weight.” The examiner finds this assertion unpersuasive and respectfully disagrees. As mentioned above, the claims do not recite any steps in which these characteristics are used to authenticate the blockchain operation nor do they recite any step that generates the transaction digest utilizing these characteristics as alleged by the applicant. The claim does not recite that these characteristics are subsequently evaluated, compared or used to perform any claimed step. Therefore, the claimed steps can be performed without relying on these characteristics. Accordingly, the recited characteristics are merely descriptive material of the SMS message and do not impart any additional functionality to the claimed invention.
Finally, the applicant asserts that “name resolution is not translation of SMS content into a message compatible with a blockchain software developer kit, an SDK-compatible request, or a translation that enables the proxy to invoke such a kit”. The examiner agrees with the applicant, however Henning was not relied upon its teaching of a translation of the SMS message content into a message compatible with an SDK. Rather, Henning was cited for its teaching of exchanging SMS message content between the application and a blockchain proxy. The claimed limitation “configure to…” in “wherein the blockchain proxy is configured to translate a context with the SMS messages into messages compatible with a blockchain software developer kit” consists of language disclosing an intended use of the blockchain proxy, so it is considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein).
Claim Rejections – 35 U.S.C. § 103
The applicant asserts that “the provided motivation to provide network interoperability, satisfy an SMS character limit, route a transaction to a selected network, or use another communication channel do not explain why a person of ordinary skill would have modified Henning to supply the missing independent-claim limitation.” The examiner finds this assertion unpersuasive and respectfully disagrees. The motivation statements for combining Henning with the secondary references provide a reason identified by the prior art that would have prompted one in ordinary skills in the art to make the proposed combination. Accordingly, the rationale for the proposed combinations is supported by the teaching of the references.
Relevant Prior Art Not Relied Upon
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20150172883 A1 to Cili discloses: Disclosed herein is a technique for preventing words from spanning across message blocks of a short message service (SMS) message. An SMS message is generated at a source wireless device, and an SMS manager, executing on the source wireless device, determines whether any words in the SMS message span across two or more message blocks of the SMS message. When so determined, the SMS manager attempts to shift characters of the SMS message across the message blocks to eliminate any word spanning. When the attempt to shift the characters between message blocks requires at least one additional message block to transmit the complete SMS message, the SMS manager gathers information about the destination wireless device to determine whether it is necessary to carry out the aforementioned shifting prior to sending the message blocks. The SMS manager then transmits the message blocks either unmodified or modified (i.e., shifted).
US 20140149285 A1 to De discloses: Methods and systems for effecting mobile payments. A token for a payment is generated generating at a first mobile phone. The token is transferred between the first mobile phone and a second mobile phone and is encashed at least one of: the first mobile phone and the second mobile phone.
US 20230146338 A1 to Ged discloses: Disclosed is a universal plug-in Distributed Public Keystore (DPK) module provided on a user equipment. The DPK module approves its identifier with a Public Key Manager (PKM) and obtains cryptocurrency from the PKM. The APPs on the user equipment generate and transmit user public keys to the DPK module. The DPK module generated its own user public key as well. After a storage transaction requirement by the DPK module is approved by a blockchain, the DPK module sends obtained user public keys to the blockchain so that the user public keys are stored in the blockchain. The user public keys are never stored outside the blockchain or in a third part server. The stored user public keys are retrieved to the DPK module when necessary, such as when a P2P communication is performed by any of the APPs.
Development of an SMS System Used to Access Bitcoin Wallets to Dlamini discloses: The popularity of Crypto currencies has not gone unnoticed, Bitcoin which is an electronic payment system and Internet money, is a leading crypto currency and continues to grow from being popular amongst the people who have knowledge about this technology, i.e. the developers, investors and tech-savvy enthusiasts and those that don’t. If a person wants to use Bitcoin they need to have a Bitcoin wallet which stores the public and private keys used when sending and receiving bitcoins. Most of these Bitcoin wallets were developed for people who have access to technologies such as smart phones, computers and an Internet connection. This paper presents a simplified Short Message Service (SMS) system that can be used by people who do not have access to these technologies. The system was developed as a prototype and tested on a low-end mobile phone to demonstrate its capabilities. It still needs to be enhanced further to enable anyone to use it, e.g. increase the speed of transactions and SMS responses and the use of better security methods.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
