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 non-final rejection prepared in response to U.S. Patent Application 19/043,794 filed on
February 3, 2025.
Claims 1-20 are pending.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Claim Objections
Claims 1, 3, 5, 8, 10, 12, 14, 16 and 18 are objected to because of the following informalities:
Claims 1, 8 and 14, the recited “an identification of the coin object…” on line 13 should be amended to “the identification of the coin object…” as “an identification of the coin object…” was previously recited on line 6.
Claims 3, 10 and 16, the recited “an IP network…” on line 4 should be amended to “the IP network…” as “an IP network…” was previously recited on line 3.
Claims 5, 12 and 18, recite the limitation "the any of the first SMS message…" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Appropriate correction is required.
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-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 8-13 are directed to a system (i.e., machine, and manufacture). 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, an 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 information 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) and mental processes 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, 9-13 and 15-20 have also been analyzed for subject matter
eligibility. However, claims 2-7, 9-13 and 15-20 also fail to recite patent eligible subject matter for the
following reasons:
Claims 2, 9 and 15 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
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, 10 and 16 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
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 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, 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, 11 and 17 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
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, 12 and 18 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the 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 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 6, 13 and 19 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
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 following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
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, 8-9 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, 8 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; (¶0057, The user device 110 is illustrated and described in more detail with reference to FIG. 1. The display GUI 400 is initiable by a “display” or “SHOW” instruction 404 received at the user device 110. The display GUI 400 is configured to generate and transmit SMS messages from the user device 110 to the computer system 1400. The computer system 1400 causes the display GUI 400 to display on the display screen. ¶0058, For example, to view the NFT 304, the NFT-SMS system (system 100) provides a view GUI 400 (sometimes referred to as a “display GUI”) that is initiated with a “show” command. The system 100 is illustrated and described in more detail with reference to FIG. 1. The view GUI 400 enables a user to enter a collection name and NFT identifier. Likewise, embodiments of the view GUI 400 can include different and/or additional components or can be arranged in different ways. ¶0059, In embodiments, an SMS message received by the computer system 1400 describes an NFT name, an NFT description, and NFT metadata. The digital asset name 312 (see FIG. 3) can be the same as or reused as the name of the NFT 304. The system 1400 determines that the NFT 304 has been minted by analyzing the SMS message. The computer system 1400 retrieves the NFT 304 from a collection blockchain address. 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. ¶0060, In embodiments, the computer system receives, from a user device (e.g., a second user device), SMS messages (e.g., a third SMS message) describing the token identifier and the collection name. ¶0103, In embodiments, responsive to receiving, from the second user device, SMS messages or a third SMS message describing the NFT name and the collection name, the NFT 304 is located in the digital asset collection based on the third SMS message.)
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; (¶0060, The computer system 1400 retrieves the NFT 304 from the blockchain address using the digital asset metadata, and displays a preview of the NFT 304 and an NFT owner 408 using the display GUI 400. For example, after the collection is identified, the SMS backend 122 calls a smart contract for that collection using the NFT identifier and receives metadata for the NFT 304. The SMS backend 122 uses the metadata to access the asset at the URL of the metadata and provides a preview of the asset, name, owner, etc., via the view GUI 400. ¶0103, In embodiments, responsive to receiving, from the second user device, SMS messages or a third SMS message describing the NFT name and the collection name, the NFT 304 is located in the digital asset collection based on the third SMS message. The NFT 304 is retrieved from the blockchain address using the URL. In embodiments, responsive to receiving, from the second user device, a third SMS message describing the token identifier and the collection name: the computer system 1400 interacts with a smart contract corresponding to the digital asset collection based on the third SMS message. Responsive to interacting with the smart contract, the digital asset metadata is received from the smart contract. The NFT 304 is retrieved from the blockchain address using the digital asset metadata. A preview of the NFT 304 and an NFT owner 408 is displayed using the display GUI 400.)
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, an 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 “… 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 message 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, 9 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). The reference is provided for the purpose of compact prosecution.
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, 10 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, 10 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 modify Henning’s disclosure by incorporating Monzaviyan’s teaching. One of ordinary skills in the art would have been motivated to combine these common elements in order to enable interoperability between different communication networks such as IP and SMS.
Claims 4-5, 11-12 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, 11 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 modify the disclosure 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 avoid interruptions in sending the message such as the user being prevented from entering any further characters into the text message (Cili ¶0021).
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, 12 and 18, Henning does not disclose, however Cili teaches:
the 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 modify the disclosure 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, 13 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, 13 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 modify the disclosure 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 enable routing an execution of the transaction on the correct blockchain.
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 modify 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 modify 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.
Conclusion
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.
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
Prosecution Insights