Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This is a reply to the application filed on 3/14/2024, in which, claims 12-25 are pending. Claims 12, 17, and 21 are independent.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
Information Disclosure Statement
The information disclosure statement (IDS) submitted is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings filed on 3/14/2024 are accepted.
Specification
The disclosure filed on 3/14/2024 is accepted.
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.
2. Claims 21-23, 25 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
6. Based upon consideration of all the relevant factors with respect to the claim as a whole, claims 21-23, 25 held to claim software per se, and are therefore rejected as non-statutory subject matter under 35 U.S.C. 101. The rationale for this finding is explained below:
Claim 21 is rejected under 35 U.S.C. 101 as directed to non-statutory subject matter of software, per se. The claim lacks the necessary physical articles or objects to constitute a machine or manufacture within the meaning of 35 U.S.C. 101. In this case, applicant has claimed a "system" in the preamble to the claim without reciting any hardware element in the body of the claim; this implies that Applicants are claiming a system of software, per se, lacking the hardware necessary to realize any of the underlying functionality. Therefore, claims 21-23, 25 are directed to non-statutory subject matter as computer programs, per se.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 12, 13, 15, 21, 22, 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190289019 A1 (hereinafter ‘Ajith’) in view of US 20160071096 A1 (hereinafter ‘Rosca’).
As regards claim 12, Ajith (US 20190289019 A1) discloses: A method of exchanging of digital copy-protected files (DCF) between a first Secure Digital Pocket (SDP) with a first local ledger and a second SDP with a second local ledger (Ajith: ¶24-¶28, ¶40, i.e., data centers each with a local ledger for transferring protected digital assets), the method comprising: making a request, by the second SDP a certain amount of DCF from the first SDP; (Ajith: ¶33, i.e., the request for a digital asset)
However, Ajith does not but in analogous art, Rosca (US 20160071096 A1) teaches: validating, by the first SDP, the request from the second SDP; (Rosca: ¶25, ¶29-¶30, i.e., validating the request for transaction for digital assets such as cryptocurrencies)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Ajith to include mechanism for validating the request for transaction for digital assets such as cryptocurrencies as taught by Rosca with the motivation to provide secure transactions (Rosca: ¶25, ¶29-¶30)
Ajith et al combination further teaches: signing and transferring the DCF by the first SDP to the second SDP; (Ajith: ¶28, ¶31, ¶85, i.e., asset is signed before transferring to the recipient)
validating, by the second SDP, the transferred DCF and updating the second local ledger; (Ajith: ¶285-¶287, i.e., the second data center/recipient validates the digital asset transfer and updates its local blockchain)
sending, by the second SDP, a confirmation of the transferred DCF to the first SDP; (Ajith: Fig. 5, ¶104, ¶285-¶287, i.e., confirming and validating the transfer and updating the local ledger)
validating, by the first SDP, the confirmation and updating, by the first SDP, the first local ledger; (Ajith: Fig. 5, ¶104, ¶285-¶287, i.e., confirming and validating the transfer and updating the local ledger)
synchronizing, by the first SDP with a DCF issuer to offload the transaction history and validate the DCF; (Ajith: ¶24-¶33, i.e., the synchronization of transaction to the issuer node)
receiving, by the first SDP from the DCF issuer, instructions to update the DCF and the first local ledger; and (Ajith: Figs. 5-7, ¶104, ¶248, ¶285-¶287, i.e., updating the sender node and the local ledger)
updating, by the first SDP, the DCF and first local ledger. (Ajith: Figs. 5-7, ¶104, ¶248, ¶285-¶287, i.e., updating the sender node and the local ledger)
Claim 21 recites substantially the same features recited in claim 12 above and is rejected based on the aforementioned rational.
As regards claim 13, Ajith et al combination teaches the method of claim 12, wherein the DCF are configured as Digital Copy-protected Files for Currencies (DCF-C) for use in financial transactions comprising micro-transactions. (Ajith: ¶40)
Claim 22 recites substantially the same features recited in claim 13 above and is rejected based on the aforementioned rational.
As regards claim 15, Ajith et al combination teaches the method of claim 12, wherein an isolated storage memory is configured to implement security measures on stored DCFs within the SDP, including at least one of: digital signatures; periodic validation; (Ajith: Fig. 3) dedicated storage requirements; and mandatory Know Your Customer (KYC) or Know Your Business (KYB) procedures to unlock and use the SE.
Claim 24 recites substantially the same features recited in claim 15 above and is rejected based on the aforementioned rational.
Claim(s) 14, 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ajith in view of Rosca in view of Yang in view of US 20100023927 A1 (hereinafter ‘Yang’).
As regards claim 14, Ajith et al combination teaches the method of claim 13. Ajith et al do not but in analogous art, Yang (US 20100023927 A1) teaches: wherein the Digital Copy-protected Files for Currencies (DCF-C) include a file format with the extension .dcf, and the format includes Header, Cryptographic Section, Value Section, Local Transaction Ledger (Transaction Entries), and Metadata. (Yang: ¶Fig. 1, ¶21, i.e., the digital protected file format with .dcf extension wherein the file format includes, header, encryption, metadata, content type, URI for local address)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Ajith et al to include a .DCF file based digital asset as taught by Yang with the motivation to provide a mechanism for protecting digital assets (Yang: ¶21, ¶23)
Claim 23 recites substantially the same features recited in claim 14 above and is rejected based on the aforementioned rational.
Claim(s) 16, 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ajith in view of Rosca in view of CN 115936695 A (hereinafter ‘Lou’).
As regards claim 16, Ajith et al combination teaches the method of claim 12. However, Ajith et al do not but in analogous art, Lou (CN 115936695 A) teaches: wherein the SDP is accessed on a user device by way of a Secured Digital Pocket (SDP) Application implementing: Trusted Network Identification; scheduled synchronization; notifications; and a manual synchronization option. (Lou: Fig. 19, i.e., page 21, i.e., the virtual digital wallet that includes gateway information (TNI), synchronization, notification)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Ajith et al to include a virtual digital wallet accessible from a user device that includes gateway information (TNI), synchronization, notification as taught by Lou with the motivation to provide a digital payment system (Lou: Fig. 19, i.e., page 21)
Claim 25 recites substantially the same features recited in claim 16 above and is rejected based on the aforementioned rational.
Claim(s) 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ajith in view of KR 102425058 B1 (hereinafter ‘KR’).
As regards claim 17, Ajith discloses: A method of exchanging of digital copy-protected files (DCF) between a Secure Digital Pocket (SDP) with a first ledger and a DCF issuer with a second ledger, the method comprising requesting, by the SDP, synchronization with the DCF issuer; (Ajith: ¶24-¶33, ¶40, i.e., data centers each with a local ledger for transferring protected digital assets and i.e., the synchronization of transaction to the issuer node)
However, Ajith does not but in analogous art, KR (KR 102425058 B1) teaches: receiving, by the SDP, an acceptance of the synchronization request from the DCF issuer; (KR: Fig. 4, pages 4-5, i.e., the acceptance of the synch request by the appropriate node) sending, by the SDP, the last synchronization time and offloading transaction history to the DCF issuer; (KR: Figs. 7-9, pages 6-7, i.e., providing transaction history and time once the representative node accepts the synch request) receiving, by the SDP, confirmation from the DCF issuer of successful offload of the transaction history; (KR: Figs. 7-9, pages 6-7, i.e., the representative node provides update to the new node of the synch update)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Ajith to include providing transaction history and time once the representative node accepts the synch request as taught by KR with the motivation to provide a mechanism for protecting digital assets (KR: Figs. 7-9, pages 6-7)
Ajith et al combination further teaches: receiving, by the SDP, instructions from the DCF issuer to update the first ledger; (Ajith: Figs. 5-7, ¶104, ¶248, ¶285-¶287, i.e., updating the sender node and the local ledger)
applying, by the SDP, the instructions received from the DCF issuer. (Ajith: Figs. 5-7, ¶104, ¶248, ¶285-¶287, i.e., updating the sender node and the local ledger)
As regards claim 18, Ajith et al combination teaches the method of claim 17, wherein the DCF are configured as Digital Copy-protected Files for Currencies (DCF-C) for use in financial transactions comprising micro-transactions. (Ajith: ¶40)
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ajith in view of KR in view of Yang.
As regards claim 19, Ajith et al combination teaches the method of claim 18. Ajith et al do not but in analogous art, Yang (US 20100023927 A1) teaches: wherein the Digital Copy-protected Files for Currencies (DCF-C) include a file format with the extension .dcf, and the format includes Header, Cryptographic Section, Value Section, Local Transaction Ledger (Transaction Entries), and Metadata. (Yang: ¶Fig. 1, ¶21, i.e., the digital protected file format with .dcf extension wherein the file format includes, header, encryption, metadata, content type, URI for local address)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Ajith et al to include a .DCF file based digital asset as taught by Yang with the motivation to provide a mechanism for protecting digital assets (Yang: ¶21, ¶23)
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ajith in view of KR in view of Lou.
As regards claim 20, Ajith et al combination teaches the method of claim 17. However, Ajith et al do not but in analogous art, Lou (CN 115936695 A) teaches: wherein an isolated storage memory is configured to implement security measures on stored DCFs within the SDP, including at least one of: digital signatures; periodic validation; dedicated storage requirements; and mandatory Know Your Customer (KYC) or Know Your Business (KYB) procedures to unlock and use the SE. (Lou: Fig. 19, i.e., page 21, i.e., the virtual digital wallet that includes gateway information (TNI), synchronization, notification)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Ajith et al to include a virtual digital wallet accessible from a user device that includes gateway information (TNI), synchronization, notification as taught by Lou with the motivation to provide a digital payment system (Lou: Fig. 19, i.e., page 21)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED A ZAIDI whose telephone number is (571)270-5995. The examiner can normally be reached Monday-Thursday: 5:30AM-5:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson can be reached at (469) 295-9235. 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.
/SYED A ZAIDI/Primary Examiner, Art Unit 2432